Bacne T Integration Ref

Download as pdf or txt
Download as pdf or txt
You are on page 1of 220
At a glance
Powered by AI
The document provides information about integrating BACnet capabilities into Niagara systems. It covers topics such as supported BACnet objects, shadow objects, polling, and troubleshooting.

The purpose of the document is to serve as a reference for integrating BACnet capabilities into Niagara systems.

The document covers topics such as supported BACnet objects, shadow objects, polling, troubleshooting, and more.

Technical Publications

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

Tridium, Inc. 3951 Westerre Parkway Suite 350 Richmond, Virginia 23233 USA http://www.tridium.com Phone 804.747.4771 Fax 804.747.5204

Copyright Notice: The software described herein is furnished under a license agreement and may be used only in accordance with the terms of the agreement. Copyright 2004 Tridium, Inc. All rights reserved. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior written consent from Tridium, Inc., 3951 Westerre Parkway, Suite 350, Richmond, Virginia 23233. The confidential information contained in this document is provided solely for use by Tridium employees, licensees, and system owners; and is not to be released to, or reproduced for, anyone else; neither is it to be used for reproduction of this Control System or any of its components. All rights to revise designs described herein are reserved. While every effort has been made to assure the accuracy of this document, Tridium shall not be held responsible for damages, including consequential damages, arising from the application of the information given herein. The information in this document is subject to change without notice. The release described in this document may be protected by one of more U.S. patents, foreign patents, or pending applications. Trademark Notices: BACnet and ASHRAE are registered trademarks of American Society of Heating, Refrigerating and Air-Conditioning Engineers. Microsoft and Windows are registered trademarks, and Windows 95, Windows NT, Windows 2000, Windows XP Professional, and Internet Explorer are trademarks of Microsoft Corporation. Java and other Java-based names are trademarks of Sun Microsystems Inc. and refer to Sun's family of Java-branded technologies. Communicator and Navigator are registered trademarks of Netscape Communications Corporation. Echelon, LON, LonMark, LonTalk, and LonWorks are registered trademarks of Echelon Corporation. Tridium, Niagara, the Niagara Framework, Vykon, Java Desktop Environment, WorkPlace Pro, Web Supervisor, JACE-4, JACE-5, JACE-NP, and JACE-NX are trademarks of Tridium Inc. All other product names and services mentioned in this publication that are known to be trademarks, registered trademarks, or service marks have been appropriately capitalized and are the property of their respective owners. BACnet Integration Reference Copyright 2004, Tridium, Inc. All rights reserved.

C O N T E N T S

About This Document Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisite Knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Important Information Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commonly Used Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ix ix x x xi xi xii xiv xiv

CHAPTER

Getting Started Supported BACnet Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Support (Shadow Objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exposing Objects (Server Support) . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Alarming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Link Layer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COV (Change Of Value) Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . BBMD Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Integrations vs. Other Integrations . . . . . . . . . . . . . . . . . . . . . . . . Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing and Configuring the BACnet Service . . . . . . . . . . . . . . . . . . . . . Licensing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing BACnet Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding the BACnetService in a JACE station . . . . . . . . . . . . . . . . . . Configuring Essential Station Properties . . . . . . . . . . . . . . . . . . . . . . Verifying Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WhoIs Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning a BACnet Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Station Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Important General Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-1 1-1 1-2 1-3 1-4 1-4 1-5 1-6 1-6 1-7 1-7 1-7 1-8 1-8 1-9 1-10 1-11 1-13 1-15 1-15 1-19 1-20

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

iii

Contents

CHAPTER

Using the BACnet Utility Opening the BACnetUtility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Action Buttons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status Line History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Network Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . whoIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . whoHas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . learnNetwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Device Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . learnDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . getAlarmSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manually Adding BACnet Shadow Objects . . . . . . . . . . . . . . . . . . . . . . . Adding a Device Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a Child Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-1 2-1 2-2 2-2 2-3 2-3 2-5 2-6 2-9 2-9 2-13 2-14 2-15 2-16

CHAPTER

BACnet Client Operation About BACnet Shadow Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Property Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About Lite BACnet Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About Writable Input Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Integration Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet objects (children) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetAnalogValuePriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryOutput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetBinaryValuePriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnetMultistateValuePriority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1 3-1 3-2 3-3 3-3 3-5 3-5 3-15 3-26 3-30 3-33 3-35 3-38 3-40 3-43 3-45 3-48 3-51 3-54 3-56

iv

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

Contents

CHAPTER

BACnet Server Operation Device Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Name Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Allowing BACnet Write Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using BACnet Log Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Log Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding BACnet Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Log Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collection Time Differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1 4-1 4-2 4-3 4-7 4-8 4-9 4-9 4-10 4-11 4-11

CHAPTER

Configuring BACnet Alarming Generating BACnet Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring for BACnet Alarm Generation . . . . . . . . . . . . . . . . . . . . . BACnetRecipient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiving BACnet Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring for BACnet Alarm Reception. . . . . . . . . . . . . . . . . . . . . .

5-1 5-1 5-2 5-3 5-5 5-7 5-8 5-8

CHAPTER

Configuring BACnetService Properties BACnetService Property Sheet Overview. . . . . . . . . . . . . . . . . . . . . . . . . . General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BACnet Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About the Poll Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Poll Scheduler Properties . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Device Status/Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Device Status Monitor Properties . . . . . . . . . . . . . . . . . . . Configuring BACnet/IP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BACnet/Ethernet Properties . . . . . . . . . . . . . . . . . . . . . . . . . Commands to the BACnet Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-1 6-2 6-3 6-3 6-4 6-7 6-9 6-9 6-12 6-15 6-16 6-18 6-18 6-20 6-22 6-22

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

Contents

Using Debug Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard BACnet Debug Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debug Option Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adjunct Configuration: bacnet.properties File. . . . . . . . . . . . . . . . . . . . . . Editing bacnet.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-24 6-24 6-25 6-28 6-29

APPENDIX

Troubleshooting
Go/No-Go Communications Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . Objects Not Polling Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Color and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debug and Standard Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Troubleshooting Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A-1 A-1 A-2 A-2 A-6 A-7

APPENDIX

BACnet PICS
BACnet Protocol Implementation Conformance Statement . . . . . . . .

B-1 B-1

APPENDIX

BACnet PC Notes
Installing the BACnet Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Over Ethernet Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . Using setAdapter.exe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manually Editing driver.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . Edit drivers.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C-1 C-1 C-2 C-2 C-3 C-5

APPENDIX

Niagara bacnetx Modules


About bacnetx Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ndio (bacxNdio) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the bacxNdio Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . notifier (bacxNotifier) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the bacxNotifier Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NotifierBinaryValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D-1 D-1 D-2 D-2 D-3 D-3 D-4

APPENDIX

Internetworks and BACnet/IP


BACnet Network Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internetwork = BACnet Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internetwork Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet Router Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BACnet/IP and BBMDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E-1 E-1 E-2 E-2 E-3 E-3

vi

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

Contents

About BBMDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Niagara BBMD Configuration Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . Example Internetwork Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

E-3 E-5 E-7

APPENDIX

Niagara MS/TP Support


Niagara MS/TP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS/TP Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Station Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring for BACnet MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prepare the JACE Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure Essential MS/TP Link-Layer Properties . . . . . . . . . . . . . . . Engineering Considerations for MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . Token Passing and Related Operation . . . . . . . . . . . . . . . . . . . . . . . . MS/TP Network Configuration Guidelines . . . . . . . . . . . . . . . . . . . . Recommended MS/TP Learn Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with Slave Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

F-1 F-1 F-2 F-3 F-3 F-3 F-7 F-13 F-13 F-14 F-17 F-18

INDEX

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

vii

Contents

viii

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

P R E F A C E

About This Document


This document is intended to help you use the BACnet service for a Niagara station. Included are getting started procedures, station engineering considerations, reference information on integration objects, and troubleshooting tips. This preface includes the following sections:
Note

Intended Audience Prerequisite Knowledge Document Summary Formatting Conventions Commonly Used Terms Related Documentation Document Updates

The Niagara BACnet Supervisor Reference is very similar to this document, and contains all equivalent information. If you have a BACnet Supervisor job, you may simply refer to the Niagara BACnet Supervisor Reference instead of this manual.

Intended Audience
The following people should use this document: Vykon systems integrators and installers responsible for initial setup and ongoing configuration of JACE controllers that are part of a BACnet integration. Vykon application programmers.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

ix

Preface Prerequisite Knowledge

About This Document

Prerequisite Knowledge
Readers of this document should know or have experience with the following: Basic Niagara concepts, such as stations, nodes, objects, properties and links. Niagaras Java Desktop Environment (JDE, formerly called WorkPlace Pro), including the necessary tasks to provide system control and user interface. Ideally, you should be Niagara-certified, that is, have successfully passed Tridiums formal Niagara Technical Certification Program. Familiarity with the specific foreign BACnet devices included in the Niagara integration, which vary by vendor in levels of BACnet conformance. Access to the native programming tools of the foreign BACnet devices is typically necessary to verify integration methods.

Document Summary
This document contains six chapters and six appendixes, summarized below. Chapter 1, Getting Started,Provides an overview of the Niagara BACnet implementation. Procedures cover installation, start up, initial checkout of BACnet communications, and learning external BACnet devices. Chapter 2, Using the BACnet Utility,Provides an explanation of the BACnetUtility View provided by the BACnet service, and procedures to use its various commands. Also covered is how to manually add BACnet shadow objects. Chapter 3, BACnet Client Operation,Provides detailed information on each of the BACnet shadow object types. Included are the device object and lite objects. Chapter 4, BACnet Server Operation,Explains the configuration required to expose standard Niagara objects as BACnet objects, including allowing write access. Information on special BACnet log objects is also provided. Chapter 5, Configuring BACnet Alarming,Provides an explanation of how BACnet alarming is performed by the BACnet service. Procedures for configuration and testing are provided. Chapter 6, Configuring BACnetService Properties.Provides explanations and procedures to configure various BACnet service properties that affect polling, device status, various link-layer options, as well as debug operations. Appendix A, Troubleshooting,Provides troubleshooting information specific to the BACnet service. Appendix B, BACnet PICS,The PICS (Protocol Implementation Conformance Statement) for the BACnet Supervisor and also JACE controllers, 2.3.4 and later. Appendix C, BACnet PC Notes,Provides configuration details for running the Niagara BACnet service on a PC platform. Appendix D, Niagara bacnetx Modules,Information on BACnet extension modules, used for exposing Ndio objects or for integrating Notifier panels.

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Preface

About This Document Formatting Conventions

Appendix E, Internetworks and BACnet/IP,Explains how multiple BACnet networks are combined to form an internetwork, and related issues and rules. Also covers BBMD operation (specific to a BACnet/IP network). Appendix F, Niagara MS/TP Support,Explains the MS/TP support provided by JACE-4/5 controllers, a specially-licensed option. An Index provides alphabetical reference to important topics in this manual.

Formatting Conventions
This document uses the following text-formatting conventions: Bold text indicates an important keyword, a keyboard key name, or an interface object name. For example, the ENTER key, or the File menu. CAPITAL letters are used for acronyms, such as WPP (WorkPlace Pro). They are also used to identify keyboard keys in instructions. For example, Press ENTER. or Press CTRL+C. Italic text is used for emphasis. It is also used to refer to the titles of other publications and document filenames. For example, The Microsoft Manual of Style or Niagara Web Solutions Guide. Italic text is also used for non-literal text that represents a variable. For example, station_name or DONOFF_n. Quotation marks are used to refer to the names of sections within the current document. For example, see Paragraph Styles for additional information. <Text between brackets> is used as a placeholder for user-supplied values. For example, <password>. <Text between brackets> is also used to indicate a variable in contexts where italic text is not appropriate or is not easily discernible from other text. For example, D:\niagara\<release number>\stations.

Important Information Indicators


In addition to text formatting, this document uses important information indicators, as listed below: Notes typically contain significant details related to the topic in the nearby text. They alert you to important information that might otherwise be overlooked.

Note

Caution

Cautions remind you to be careful. There is a chance that you could perform an action that cannot be undone, might produce unexpected results, or might cause lost data. Cautions typically explain why the action is potentially problematic.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

xi

Preface Commonly Used Terms

About This Document

Tip

Means a best practice or other helpful instruction. Tips typically contain recommendations that will help you use the product more effectively.

Timesaver

Means a shortcut. Timesavers typically tell you a quicker or shorter way to perform a task. They might include keyboard combinations or buttons that can be used instead of menu selections to perform the same action.

Commonly Used Terms


Throughout this document, references are made to acronyms and terms encountered with a BACnet integration. This section provides definitions for these terms and is intended to ensure their consistent use.
ASHRAE BACnet

American Society of Heating, Refrigerating and Air-Conditioning Engineers. Building Automation Controls network. An ASHRAE-developed open communications protocol designed for the HVAC controls industry, where data is modeled using a common set of objects and a standard set of services. Operation mode for a BACnet system or device, where it makes use of a BACnet device for some particular purpose via a service request instance. Operation mode for a BACnet system or device, where it provides a service to a requesting client. Refers to either/both the Niagara BACnetService, which runs in a JACE station, or the nearly identical Niagara BACnetWSService, an option for a Web Supervisor. BACnet/IP Broadcast Management Device. A device that receives and redistributes broadcast-type BACnet messages (Who-Is, I-Am, etc.) to other BACnet/IP devices on its own subnet, and sends broadcast-type messages to BBMDs on other subnets. By having one BBMD on each subnet, a BACnet/IP network can span subnets (between IP routers, which otherwise typically block broadcast-type messages). Starting in Niagara r2.3.4, the BACnet service (if configured for BACnet IP) supports operation as a BBMD.

BACnet client

BACnet server

BACnet service (Niagara) BBMD

BACnet/Ethernet or B/Eth BACnet/IP or B/IP

Native BACnet over Ethernet, one of the original BACnet link-layer types, and the first BACnet protocol supported in Niagara. BACnet over Ethernet IP, sometimes called BACnet/TCP or BACnet TCP/IP. Introduced in Annex J of the BACnet standard, it has become the most popular BACnet link-layer protocol (except in lowest-cost devices, where MS/TP is used). Niagara support for the BACnet/IP protocol was extended in r2.3.4 and later with many new features, including capability of BBMD operation.

BACnet MS/TP

The BACnet link-layer protocol used for lower-cost devices. See MS/TP.

xii

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Preface

About This Document Commonly Used Terms

child object

In general Niagara terms, any object contained in another objects Workspace. Specific to BACnet shadow objects, a child object refers to any of the full or lite shadow objects contained under a BACnetDevice (parent) object. The shadow objects represent BACnet control objects in the parent device. Change-of-Value. In general Niagara terms, any object representing an external device. Specific to a BACnet integration, a BACnetDevice object is a container (parent) object that shadows a particular external BACnet device (specifically, its Device object). The BACnetDevice may contain other child shadow objects. External to a Niagara host, the station appears as a BACnet device with a BACnet Device object. This Device object has the stations name, and uses Config properties in the BACnet service.

COV device object, Device object

foreign device

A BACnet/IP term for a BACnet device that exists on an IP subnet without a BBMD, where the device can register with a BBMD on another (remote) subnet as a foreign device to explicitly receive BACnet broadcast messages. (In no way does it imply any reduced functionality.) A Niagara term for a (child) BACnet shadow object that has both BACnet required and optional properties (for that object type). Full objects are intended for use when external BACnet devices are implemented with objects having both required and optional properties. See also Lite object. A term used in learnDevice or learnNetwork that narrows the scope of shadow objects created for a device, by range(s) of instance numbers. Two or more BACnet networks connected by a BACnet router. Java Desktop Environment. The graphical engineering tool for creating Niagara station databases (formerly WorkPlace Pro). A Niagara term for a (child) BACnet shadow object that has only BACnet required object properties (for that object type), and none of the BACnet optional properties. Lite objects are useful when external BACnet devices are implemented with objects having only required properties. See also full object. Master Slave / Token Passing. A BACnet link-layer type for lower cost devices that are networked using RS-485 multidrop networks. Niagara r2.3.4 and later provides direct support for MS/TP networks with JACE-4/5 series controllers. A BACnet method to identify a particular object within a device, using a combination of its object type and a unique instance number. In general Niagara terms, any object in the station database that represents some externally-programmed device or data point (object, value, data store, etc.). Specific to a BACnet integration, there are two specific classes of shadow objects: a device object (BACnetDevice) and the various child objects.

full object

instance limits

internetwork JDE

Lite object

MS/TP

object identifier, (object ID) shadow object

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

xiii

Preface Related Documentation

About This Document

Related Documentation
For additional information related to Niagara and BACnet, please refer to the following other Niagara Technical Publications: Niagara BACnet Supervisor Reference, r2.3.5 Niagara Standard Programming Reference, r2.3.5 For general BACnet information, the definitive BACnet reference is the comprehensive ASHRAE specification developed and maintained by the ASHRAE Standing Standard Project Committee (SSPC) 135, entitled: BACnet, A Data Communication Protocol for Building Automation and Control Networks. Visit the official BACnet website, www.bacnet.org, for information on obtaining a copy of this specification, and for other BACnet-related information.

Document Updates
Updates to this document are listed below.
Table 1 Updates to the BACnet Integration Reference, Niagara Release 2.3.5.

Date
04/12/04

Update
Initial document published for Niagara Release 2.3.5. For information on changes made in the tridiumx/bacnet module, please refer to the Niagara 2.3.5 Release Notes document.

xiv

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

CHAPTER

Getting Started
Of the many integrations provided by the Niagara Framework, BACnet is the most tightly-coupled. In fact, the standard Niagara object set builds from the collection of BACnet objects, including most BACnet object properties and definitions. Core object functionality such as status flags, priority arrays and levels, event notification, and so on, have direct BACnet heritage. This chapter provides the following main topics:

Supported BACnet Features BACnet Integrations vs. Other Integrations Installing and Configuring the BACnet Service Verifying Communications Learning a BACnet Network Station Engineering Considerations Important General Facts

Supported BACnet Features


Niagara support for various BACnet features are described in the following sections:

Client Support (Shadow Objects) Exposing Objects (Server Support) BACnet Alarming Data Link Layer Support COV (Change Of Value) Subscriptions BBMD Functionality Time Synchronization

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

11

Chapter 1 Supported BACnet Features

Getting Started

Client Support (Shadow Objects)


Operating primarily as a BACnet client, the JACE station requests object data from other devices using BACnet services ReadProperty (and if remotely supported) ReadPropertyMultiple. For most BACnet object types, the continuously requested properties are Present_Value and Status_Flags. This data from other BACnet devices is continuously updated in either of two ways: COV (Change Of Value) Subscriptions (if the device supports SubscribeCOV) A communications polling routine

In the station, BACnet client information is represented by BACnet shadow objects. These objects exist at the BACnet device (parent) level and at the control object (child) level. The collection of a stations BACnet shadow objects define the data items for COV subscriptions/polling. BACnet shadow objects provide various right-click commands, and can be linked into other logic in the station database for control, data archiving, and presentation on web-accessible graphics. All properties of a shadowed BACnet object are available for upload, review, and if so enabled in the target (server) device, most are modifiable from the Niagara property sheet. BACnet services WriteProperty and WritePropertyMultiple (if supported) are used. Using the JDE, a BACnet Utility provides methods to automatically learn (and create) BACnet shadow objects. An option is provided to create lite versions of objects, which include only BACnet-required properties, or standard objects, which include all required properties plus BACnet-defined optional properties. Shadow objects of both types (standard or lite) are available for the following types of BACnet objects in remote devices:

AnalogInput1 AnalogOutput AnalogValue AnalogValue (priority)

BinaryInput1 BinaryOutput BinaryValue BinaryValue (priority)

MultistateInput1 MultistateOutput MultistateValue MultistateValue (priority)

1.

Special writable versions of input shadow objects are also available. Writable versions allow the present value to be set by a (Niagara) input value, providing that it is out_of_service. Use of these objects is expected to be rare.

The JDEs BACnet Utility also provides client support at the network-level for BACnet services Who-I and Who-Has, and at the device-level for the BACnet service GetAlarmSummary. For more information, refer to Chapter 2, Using the BACnet Utility, and Chapter 3, BACnet Client Operation.

12

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started Supported BACnet Features

Exposing Objects (Server Support)


The station running on the JACE appears to the BACnet network as a BACnet Device object, using the stations name. Its numerical object ID is assigned as a config property in its BACnet service, along with other Device-type properties. Because many standard Niagara objects are closely modeled after BACnet objects, other station data can be easily exported to BACnet. Specifically, for any Niagara station is running the BACnet service, there are currently 8 types of standard Niagara objects that can be exposed directly as BACnet objects. A single property in each object, foreignAddress, activates this feature. When making this data available, the Niagara station operates as a BACnet server. The standard Niagara objects that provide external BACnet server visibility are:

AnalogInput (AI) AnalogOutput (AO) BinaryInput (BI) BinaryOutput (BO)

Calendar Schedule MultistateInput (MSI) MultistateOutput (MSO)

Exposing Niagara Logs

By using special server objects available in the tridiumx\bacnet jar in the Local Library, you can also expose Niagara logs as BACnet Trend_Log objects. For any log you wish to expose to BACnet, you use one of these log objects instead of the standard Niagara equivalent (which they otherwise closely resemble). Server log objects include:

BACnetAnalogLog BACnetBinaryLog BACnetIntegerLog BACnetMultistateLog BACnetStringLog

For more information, refer to Using BACnet Log Objects, page 4-8.

Server Support for BACnet Services

The Niagara station also provides server support to client requests for various BACnet application services, including:

ReadProperty ReadPropertyMultiple Who-Has Who-Is

WriteProperty WritePropertyMultiple I-Have I-Am

For more information, refer to Chapter 4, BACnet Server Operation.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

13

Chapter 1 Supported BACnet Features

Getting Started

BACnet Alarming
The JACE station supports BACnet alarming, both as a client and server. The station can route Niagara alarms to BACnet recipients, using special notification objects. These alarms appear as BACnet alarms to the targeted BACnet devices (which can also provide alarm acknowledgement). A JACE station can also receive incoming BACnet alarms, convert them to the Niagara alarm format, and route them through a Niagara system as any other alarm (including the numerous recipient options). These BACnet alarms appear in the JDE Alarm Console (and remote Vykon Alarm Service clients), and can be acknowledged like native alarms. Device objects shadowing BACnet devices also provide a Get Alarm Summary command, which returns a list of objects currently in alarm. The station can also be configured to continuously ping shadowed BACnet devices. This confirms communication status and generates Niagara device down alarms when offline status is detected. For more information, refer to Chapter 5, Configuring BACnet Alarming.

Data Link Layer Support


The JACE station can be configured to use link-layer types BACnet/IP (BACnet over TCP/IP over Ethernet) or BACnet/Ethernet, or both simultaneously. If a JACE-41 or JACE-5, additional simultaneous MS/TP (master-slave/token-passing) support is also available, with up to four separate RS-485 MS/TP networks. Unique BACnet network numbers are used for each of the link-layer tabs enabled in the JACE station. BACnet/IP is becoming more typical and is often used for newer installations. If BACnet/IP is enabled, the JACE station is configurable as either a BACnet Foreign Device or as a BBMD (BACnet/IP Broadcast Management Device) host, either of which allows BACnet/IP operation though IP routers. For more information, see BACnet/IP Considerations, page 1-11.

BACnet Router Operation

If the JACE station is configured to have more than one link-layer tab enabled, say BACnet/IP and BACnet/Ethernet, or BACnet/IP and BACnet-MS/TP, it automatically operates as a BACnet router between the different BACnet networks. Router operation is independent of other station operation (no particular station configuration is required). Upon startup, the station broadcasts the BACnet I-Am-Router-To-Network message to inform other BACnet routers that may exist on the internetwork.

Remote BACnet Router Detection

The property sheet for the Niagara BACnet service provides a router table listing any other identified BACnet routers. Typically, routers are automatically detected and stored as a result of various Who-Is and I-Am BACnet broadcast messages. In addition, you can manually enter known BACnet routers.
1. MS/TP support for JACE-NX and -NP platforms to be available at some future date.

14

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started Supported BACnet Features

COV (Change Of Value) Subscriptions


The JACE station can receive COV (change of value) updates from BACnet objects, via client-side support for the BACnet SubscribeCOV service. This mechanism results in quicker data updates for shadow objects than polling requests, as well as more efficient network utilization. Essentially, a BACnet shadow (client) object enabled for COV registers a subscription in the remote device, whereby it is sent data updates (notifications) upon changes in Present_Value and/or Status_Flags. For any binary or multistate-type object, this means each value change. For any analog-type object, the value change must be equal or greater than the objects COV_increment value.

COV Configuration Overview

Niagara support for SubscribeCOV is available for any remote BACnet (server) device that supports itand for as many objects that the device allows subscribed to a single client. For any BACnet device that does not support the SubscribeCOV service, polling request/response messages are used to get all data values. In the Niagara station, each BACnetDevice object has a useCOV property. If the device was learned by Niagara, and it supports SubscribeCOV, its useCOV property is initially set to True. You can then select specific child objects to useCOV, such that COV updates are used instead of polling. If, for some reason COV subscriptions are unsuccessful, polling is automatically substituted. Starting in r2.3.5, a progressive backoff scheme was implemented for COV re-subscription attempts. This provides automatic re-usage of SubscribeCOV for object updates, in cases where fallback polling of objects temporarily occurred. At the device-level, a maxCOVSubscriptions property limits the number of attempted COV subscriptions, with a default value of 50 objects. Depending on the capabilities of the target device, you may wish to adjust this up or down. A useConfirmedCOV property is also available, plus a status value showing the number of currently COV-subscribed (or confirmed-COV-subscribed) objects.

Notes

Niagara support for SubscribeCOV is client-side only. This means that Niagara objects exposed as BACnet do not generate COV notifications. However, most Niagara stations operate primarily as BACnet clients, and so server-side support for Read Property Multiple is typically used. Often, a device may state support for SubcribeCOV, but then in operation limit the number of actual COV subscriptions to only a few objects. Adjust the device property maxCOVSubscriptions within this value, and select objects carefully before enabling useCOV. Polling is automatically used for any COV-enabled shadow object that has met with unsuccessful attempts at COV subscription. This may occur for a variety of reasons, one of which is the device has run out of subscriptions. For any BACnet device that supports Confirmed COV Notification, you can choose this at the device-level (useConfirmedCOV) instead of just useCOV. It applies to all client (child) objects enabled for useCOV. However, note that this service requires extra messaging by both the station and the remote device.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

15

Chapter 1 Supported BACnet Features

Getting Started

Note

The similar (but different) BACnet SubscribeCOVProperty service is not currently supported in Niagara. In that service, the subscriber can specify a particular property, for example, High_Limit. However, because Niagara always requests Present_Value and Status_Flags, the overhead of this service would outweigh any benefits.

COV, Polling, and Poll On Demand


Shadow objects under a device supporting SubscribeCOV are still added to the stations BACnet polling queue, as a means of tracking subscriptions. However, polling messages (requests) are not sent for these objects. When shadow objects are in PollOnDemand containers, those that are inactive (not viewed or in the view cache) are dynamically removed from the BACnet poll queue, as before. They are unsubscribed from the BACnet device at that point. When activated, they are resubscribed and added back to the queue.

BBMD Functionality
If using BACnet/IP, the JACE station can be configured to operate as a BBMD (BACnet Broadcast Management Device). In this way, the JACE can provide support for BACnet broadcast messages to its local IP subnet. Included is the ability to register other BACnet devices as BACnet foreign devices, and to review the broadcast distribution table common to all BBMDs on the same BACnet/IP network. If no other BACnet devices exist on the same IP subnet as the JACE, its station can be configured instead to register as a foreign device with a BBMD on another IP subnet. If a BBMD already exists on the JACEs local IP subnet, the station can be simply left at the default configuration (neither a BBMD or a foreign device). Broadcast message operation relies on the existing device.

Time Synchronization
The JACE station can be configured to accept time-synchronization messages from a designated BACnet time-synchronization master. Either regular or UTC (universal time coordinated) messages, or both, can be accepted. UTC synch messages allow synchronization across time zones. This configuration is done on the BACnetServices property sheet, General, Engineering tab. Use of this feature requires configuration of the BACnet time master device, specifically, to name the JACE station as a time-synchronization recipient. This configuration is a local matter to that remote BACnet device.

16

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started BACnet Integrations vs. Other Integrations

BACnet Integrations vs. Other Integrations


A BACnet integration has both differences and similarities to other Niagara integrations (LonWorks, Modbus, proprietary types such as Andover Infinity, etc.).

Differences

A BACnet integration is not required to be organized under a specific container in a Niagara station (for example, lonTrunk, AcInfinityNetwork, so forth). The only requirement is that client shadow objects reside under their appropriate parent (device) shadow object. These (BACnet) device objects can be located as needed in the station database. By convention, however, you may wish to group client BACnetDevices together into containers by BACnet network, especially when multiple networks exist (BACnet internetwork). Note that on the server side, standard Niagara objects can be exposed as BACnet objects while located anywhere in the station database.

A remote BACnet device may be a BACnet workstation, typically a PC running an operator interface implemented with the BACnet protocol. In this scenario, a stations BACnet server operations may used more than client operationsfor example, to export information originating in another Niagara integration (LonWorks, Modbus, or other proprietary). The BACnet application service Who-Has, provided by the BACnetUtility View of the Niagara BACnet service, offers unique network-level search functionality. Using this command, you can search all networked BACnet devices for instances of objects by name, type, instance number, or combinations of type and instance number range. Devices report back with their objects deviceIds, objectIds, and objectNames. This data can be useful when selecting which devices and BACnet objects are of interest.

Client-side support for the BACnet SubscribeCOV service provides for better network utilization than in most other integrations, which are poll-only.

Similarities

In the JDE, the BACnet service provides a BACnetUtility View that provides learnNetwork and learnDevice commands. These commands automate the stations creation of the available BACnet shadow objects, from which you can keep those needed (and delete those that are not). These commands are similar to others in network- and device-level manager views in other integrations. For more information, refer to Chapter 2, Using the BACnet Utility. Real-time values in BACnet shadow objects are updated using a polling mechanism (if the source BACnet device does not support the SubscribeCOV service). The same polling model is used in other integrations (for example,

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

17

Chapter 1 Installing and Configuring the BACnet Service

Getting Started

AcInfinity, Modbus, others). In addition, a device-status mechanism is also available. Refer to Chapter 6, Configuring BACnetService Properties, for more information. As with most other integrations, shadow objects can be placed in PollOnDemand containers to further increase overall data updates.

Installing and Configuring the BACnet Service


These main topics explain initial BACnet module installation and configuration: Licensing Considerations Installing BACnet Modules Adding the BACnetService in a JACE station Configuring Essential Station Properties

Licensing Considerations
JACE Controllers Web Supervisor

JACE Controllers

JACE controllers are typically licensed to run the BACnetService. Verify this by using the Admin Tool to open the JACE, and then select the Installation tab, View License. The features line will contain bacnet. Contact Tridium if it does not. Starting in Niagara r2.3.5 (or r2.301.432 or later), a new line in the license.properties file, if present, defines the maximum number of client BACnet devices that can be shadowed in the station database. This line is:
numberOfBACnetDevices=n

Note

Note that after reaching this device limit, BACnet device learns will stop, or if BACnet device objects are manually added, will fail to properly initialize. This device limit applies across all BACnet link-layer types (BACnet/IP, MS/TP, and BACnet/Ethernet). Depending on the JACE model or licensed purchased, this limit value may vary. If this line is absent, there is no explicit device limit. In addition, the BACnet MS/TP option for a JACE-4/5 has additional license considerations. Refer to Licensing for BACnet MS/TP, page F-4.

Caution

Do not attempt to edit the license file. If you make any changes to the license file, your JACE station will not operate! Contact Tridium if you need any changes made to your license, so that you may be sent a proper license.

18

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started Installing and Configuring the BACnet Service

Web Supervisor

A special Web Supervisor product, the BACnet Supervisor, is available for use on a BACnet network without requiring JACE controllers. For the equivalent Niagara document on this product, refer to the Niagara BACnet Supervisor Reference. A typical Web Supervisor PC is not licensed to run the BACnetService. However, the engineering PC used by a Vykon systems integrator may be licensed that way. In this case, use the Admin Tool to open the engineering PC host, and then select the Installation tab, View License. Verify that the features line contains bacnet. A Niagara host PC may require some additional driver configuration to use the Niagara BACnet service. Refer to Appendix C, BACnet PC Notes.

Note

Installing BACnet Modules


Any Web Supervisor requires a bacnet module in its modules directory. The Niagara bacnet module is typically installed on a JACE-NX or -NP at the factory, prior to shipment. For any JACE-4 or JACE-5, you must install all needed modules. You may receive updated BACnet module files as: (for JACE-4 and JACE-5) bacnet-<release>.jar.nt (for JACE-NX, JACE-NP and Web Supervisor) where <release> is 2.305.508, or whatever the current build number is.

bacnet-<release>.jar.jace

You can follow this procedure to install all BACnet modules.


Procedure 1 Installing the necessary Niagara modules.

Step 1

Make station backups of any existing stations running BACnet services, saving databases to XML. For procedures, see the Niagara JDE Users Guide. On your Niagara engineering PC/Web Supervisor, copy the nt jar file to the Niagara modules subdirectory, for example, D:\niagara\<release>\nre\modules Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes BACnet components available to the Web Supervisor and Local Library.

Step 2

Step 3 Step 4

Close and restart the JDE to load updated module(s) on your PC. On your Niagara engineering PC/Web Supervisor, copy the nt jar file (again) to the Niagara subdirectory you use to store JACE-NX/NP modules, for example,
D:\niagara\<release>\nt

Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-NX or JACE-NP.
Step 5

On your Niagara engineering PC/Web Supervisor, copy the jace jar file to the Niagara subdirectory you use to store JACE-4/5 modules, for example,
D:\niagara\<release>\emb

Remove the .jace portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-4 or JACE-5.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

19

Chapter 1 Installing and Configuring the BACnet Service

Getting Started

Step 6

Using the Admin Tool, open the JACE host and select Installation tab, Installation Wizard. In the Select Distribution Directory dialog box: a. If you are installing modules on a JACE-4/5 controller, select emb. b. If you are installing modules on a JACE-NX/NP controller, select nt. Click Install. In the Niagara Remote Installation dialog box, click the radio button for Configure Modules Only. Click Next. In the Configure Modules dialog box, scroll down to find the row for the bacnet module and click in the Upgrade/Add column beside it. A red check mark appears besides bacnet module in Upgrade/Add. If installing in a JACE-4, also select (upgrade/add) the bacxNdio module. This allows Ndio objects in the JACE-4 to be exposed as BACnet objects.

Step 7

Step 8 Step 9

Step 10

Note

Step 11 Step 12 Step 13 Step 14 Step 15

Click Next. In the Database Backup dialog box, select the database to be backed up. Enter an administrative-level station user name and password. Click Next. Click Finish. In the summary dialog box, click OK to continue. A dialog box displays each task as it is performed. Typically, this process takes a couple of minutes. When the installation is complete, click OK.

Step 16

Adding the BACnetService in a JACE station


Procedure 1-1 Adding the BACnetService in a JACE station.

Step 1

Using the JDE, open the station and expand the stations services folder (to verify the BACnetService is missing). Open the Local Library. In the tridiumx folder, expand the bacnet jar to tridiumx/bacnet/services. Right-click the BACnetService and select Copy. Right-click the stations services container and select Paste. The service is not effective until the station is restarted. However, you should first specify the BACnet device ID for the station, as well its link-layer options. See the next section, Configuring Essential Station Properties.

Step 2 Step 3 Step 4 Step 5

110

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started Installing and Configuring the BACnet Service

Configuring Essential Station Properties


Before starting a Niagara station with the BACnet service, it is recommended that you configure essential properties such as its numerical BACnet Device object ID, the link-layer type(s) to use, and perhaps other items.
Procedure 1-2 Specifying essential BACnetService properties.

Step 1

Under the stations services folder, right-click the BACnetService and select Go > Properties. On the General, Config tab, set the deviceID, Instance Number from the default -1 (disabled) to a unique device number for the BACnet network. Click Apply. This is the BACnet object indentifier for the Device object that externally represents the Niagara station. Valid range is from 0 to 4194302.

Step 2

Note

Step 3

Click the appropriate link-layer tab, for example BACnetIP or BACnetEthernet, and then its Config subtab. (BACnet/IP requires review of several properties.) Each of the link-layer type tabs has a network number, used to specify the BACnet network associated with that link layer. Defaults values are BACnet/IP as network 1, and BACnet/Ethernet as network 2. For any existing job that already has one or more BACnet routers, you need to edit these network numbers to match others in use. The valid range for a BACnet network is a unique number from 1 to 65535. Link-layer tabs BACnetMSTP(n) currently apply only to a station in a JACE-4 or JACE-5, and are not supported on a JACE-NP or JACE-NX. For more information, see Appendix F, Niagara MS/TP Support.
a.

Note

For BACnetIP, also see BACnet/IP Considerations, page 1-11. If not using BACnet/IP, simply set ipEnable as False, and click Apply. For BACnetEthernet, enter a value in the ethernetNetworkNumber for the BACnet network number in use. Set ethernetEnable to True. Click Apply. If not using BACnet/Ethernet, set ethernetEnable as False, and click Apply.

b.

Step 4 Step 5

After reviewing the appropriate changes on all tabs, click Apply. Save the station database and restart the station.

BACnet/IP Considerations

The address of a BACnet/IP device is determined by the combination of two things: IP address of the device UDP port number (the default is the hexadecimal number BAC0).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

111

Chapter 1 Installing and Configuring the BACnet Service

Getting Started

Depending on the configuration of other BACnet/IP devices on the BACnet network, address issues may be encountered. These issues are divided into two broad areas: Network, Subnet and UDP Port BBMD Support

Network, Subnet and UDP Port

You should know the BACnet network number used by other BACnet/IP devices on the network. The default network number (1) may be used in a new installation. Typically, the JACEs IP address, the default UDP port (BAC0), and default subnet mask (255.255.255.0) are the appropriate values. However, if part of a custom subnet, or another UDP port is being used in a BACnet/IP configuration, you might need to edit the appropriate subnet and UDP port properties.
Procedure 1-3 BACnet/IP configuration for BACnet network, subnet mask and UDP port.

Step 1 Step 2

On the BACnetIP, Config tab, set ipEnable to True. In the ipNetworkNumber property, enter the BACnet network number in use for other BACnet/IP devices. Set the needed values in the subnetMaskString and udpPortString properties. Note that subnetMaskString uses the conventional dotted decimal format. The udpPortString property requires an 0x prefix on the hexadecimal value, for example: 0xBAC1 Click Apply after changing.

Step 3

Step 4 Step 5

A station restart is needed to become effective. However, you should review other BACnet/IP properties first. See the next section, BBMD Support.

BBMD Support

In BACnet/IP networks, BBMDs (BACnet broadcast management devices) are commonly used. Using BBMDs, a BACnet network using BACnet/IP can span multiple IP subnets. Otherwise, BACnet broadcast-type messages from services like Who_Is, I_Am, (and others) are typically blocked at standard TCP/IP routers. One (and only one) BBMD is typically required on each IP subnet. If a subnet has only one or a few BACnet devices, they may each alternately register as a foreign device with a BBMD on another (remote) subnet. The BACnetService offers a number of BBMD-related options, based on the selection in the bacnetIPDeviceType property. Configuration is as either:

noneThe Niagara station does not act as a BBMD, nor is it registered with a BBMD on a different (remote) IP subnetthe default setting. This none setting is acceptable if the JACE resides on an IP subnet that currently has a device operating as a BBMD. foreignDeviceThe Niagara station registers with a BBMD on a remote subnet. You must know the IP address of the remote BBMD. In this scenario, other BACnet devices on the same (local) IP subnet (if any) are also likely to be registered as a foreign device with a remote BBMD.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

112

Chapter 1

Getting Started Installing and Configuring the BACnet Service

bbmdThe Niagara station acts as a BBMD on its local subnet. No other BBMD should reside on that subnet. Here again, you need to know the IP address of any other (remote) BBMD. The station will automatically copy its BBMD distribution table and update it again among all BBMDs.

Note

If the JACE is on the same subnet as a BBMD, leave these properties at defaults. The local BBMD will distribute all broadcast messages to/from the remote BBMDs.
Procedure 1-4 BACnet/IP configuration for BBMD operation.

Step 1 Step 2

Open the services property sheet to the BACnetIP, Config tab. Make the selection for bacnetIPDeviceType, based on the previous information. If selecting none, you have finished configuration. Click Apply. If selecting foreignDevice or bbmd, enter the known address of the remote BBMD in the remoteBBMDAddress property, default value is null). Entry format requires all hexadecimal with colons: xx:xx:xx:xx:yy:yy where xx:xx:xx:xx is IP address and yy:yy is UDP port. For example, if the BBMD has an IP address of 192.168.1.21 and is using the default UDP port (BAC0), its MAC Address is: C0:A8:01:15:BA:C0 You can use the Windows Calculator to convert the IP octets from decimal.

Step 3

Note

If selecting bbmd, configuration is finished. Click Apply.


Step 4

If selecting foreignDevice, you can specify the length of time that the station registers with a BBMD in its foreign device table with the registrationLifetime property (default value is 900 seconds). The station periodically re-registers with the BBMD to maintain its table entry. Either accept this default, or enter another registrationLifetime value.

Step 5

Click Apply after changing. A station restart is needed to become effective.

Note

BACnet/IP properties are covered in Chapter 6, Configuring BACnetService Properties. Refer to Configuring BACnet/IP Properties, page 6-18.

Verifying Communications
With the JACE connected on the network with other BACnet devices, use the BACnet servicess BACnetUtility to verify communications.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

113

Chapter 1 Installing and Configuring the BACnet Service

Getting Started

Procedure 1-5

Verifying BACnet communications.

Step 1

Expand the stations services folder, and double-click the BACnetService. This opens the BACnetUtility view. Select Category: network, Command: whoIs, and then click Execute. A WhoIs dialog appears (Figure 1-1).
Figure 1-1 WhoIs dialog box.

Step 2

You can run the WhoIs command with the default options as shown above, or change them as follows: Use device instance limits?Check if you want to limit the device ID address range for the Who-Is message. Only those BACnet devices within the low limit or high limit should reply (limits are inclusive). The default device instance range is the entire BACnet device ID range (0 to 4194302). Wait time for I-Am responses (sec)The time waited after issuing the command to receive all I-am responses from all devices. Default value is 5 seconds. Typically, you would adjust this up (say, 60 seconds) if a large network with many devices, or an internetwork with BACnet routers. After issuing the command, the WhoIs dialog remains visible for this time period.

Step 3

With options either at defaults or at different values, click OK. After the I-am wait time, the utility window shows the message from each BACnet device (Figure 1-2). Each message contains five pieces of data about that device: Device Identifier(Device object Id number), unique among all devices. Maximum APDU Length Acceptedmaximum APDU length (min. = 50). Segmentation SupportedMessage segmentation, where both is best. Vendor Identifierunique number assigned to the vendor for the device. Currently, vendors by number are listed at the BACnet org website at URL:

http://www.bacnet.org/VendorID/BACnet%20Vendor%20IDs.html

Source Addresslists network number, then devices BACnet MAC address.

114

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started Learning a BACnet Network

Figure 1-2

BACnetUtility view, whoIs command results.

last field, sourceAddr, shows: n m:m:m:m:m:m where n = BACnet network number m: = BACnet MAC address

Issue a whoIs as often as you likeit does not write data to remote devices. Refer to Chapter 2, Using the BACnet Utility, for more details on whoIs. Refer to the Go/No-Go Communications Checklist section on page A-1 if communications cannot be verified.

WhoIs Notes
When performing a whoIs command, the BACnet service will not only learn about devices, but possibly also about BACnet routers. If you examine the whoIs results carefully, and notice a device that has responded with sourceAddr data that includes a network number that does not match the network number on the BACnetServices link-layer tabs (either BACnet/IP or BACnet/Ethernet), chances are that device is on a remote network. This means that a BACnet router forwarded your Who-Is message and the devices I-am response. To check, open the property sheet for the BACnetService. Click the tabs General, Config. At the bottom of the property sheet is a router table, listing any known BACnet routers (apart from itself). Often, a BACnet device may perform router functions in addition to other application duties. This is true for any Niagara station running the BACnet service with multiple link-layer tabs (networks) enabled.

Learning a BACnet Network


After verifying BACnet communications, you can read Chapter 2, Using the BACnet Utility, to understand the different BACnetUtility commands and how they operate, or simply choose to follow this procedure. This procedure globally makes BACnet shadow objects in the station for all devices found by the whoIs command. You can rerun this procedure (learnNetwork command) whenever needed, and/or delete any or all shadow objects that it creates.
Procedure 1-6 Learning a BACnet network (and creating shadow objects).

Step 1

Using the JDE, in the stations services folder, double-click the BACnetService. This opens the BACnetUtility View.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

115

Chapter 1 Learning a BACnet Network

Getting Started

Step 2

Select Category: network, Command: learnNetwork, and then click Execute. The LearnNetwork dialog box appears, with options to Learn device contents (create child objects under device objects) and Use lite objects (Figure 1-3). You can also specify device ID instance limits, and modify the collective wait time for receiving I-am messages. In general, option defaults are recommended (see Tip).
Figure 1-3 LearnNetwork dialog determines whether child objects are created.

Learn commands from the BACnetUtility place created shadow objects in a BACnetTemp container in the stations root, also automatically created (if not already existing).

Tip

Unless you are learning a BACnet network with very few devices, or you have restricted the device ID range to include only a few devices, and all devices contain only important objects, it is recommended that you leave the Learn device contents option cleared, as shown here. Otherwise, the Learn Network command will attempt to create a shadow object for every BACnet object in every BACnet device within the device ID range, and you may easily create more objects than you intended. Also, if BACnet MS/TP is enabled, be aware that only the first 31 devices can be learned on any MS/TP trunk (network)the learn will skip to another link-layer (network), or stop at this point. And if a JACE-403, the learn automatically stops whenever the maximum 27 BACnet devices have been learned. If you clear Learn device contents, the learn still creates a BACnetDevice shadow object for each discovered device. You can then individually learn each device, applying instance limits for the various BACnet object types, as needed, and select lite objects if wanted. See the learnDevice section on page 2-9 for more details.

116

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started Learning a BACnet Network

Device instance limits are inclusive. For example, if you check device limits and enter a low limit of 99 and high limit of 102, a maximum of four devices can be learnedthose with device IDs 99, 100, 101, and 102. Note the default I-am wait time is 5 seconds. You may need to adjust this upwards, especially if you found that some devices did not reply previously to a whoIs command unless this value was set higher (Verifying Communications, page 1-13).
Step 3

Usually (as noted above), you go with default settings, and click Apply. The BACnetUtility window updates with progress messages as it creates a BACnetTemp container (Figure 1-3), and a BACnetDevice object for each discovered device. If Learn device contents was selected, shadow objects are also created for all BACnet objects in every device. Lite objects are similar to standard BACnet shadow objects, but contain only required BACnet properties, whereas normal BACnet shadow objects contain both required and optional properties. For example, lite shadow objects for Analog_Inputs do not have alarm limit properties, and so forth. They are best for devices that contain objects mostly with required properties only, as they consume less station resources. However, note that a lite object counts towards the licensed limit the same as a standard object.

Note

Depending on the number of networked BACnet devices and their contained objects, this may take from several minutes to over an hour. During this time, the status bar at the windows bottom continues to periodically flash. When the learnNetwork command is done, the status bar displays Network learn complete (Figure 1-4). An Abort button (Figure 1-4) is available. You may wish to abort a learn in progress for these reasons:

Note

It is taking longer than expected. The learn is creating more shadow objects that originally estimated. This might occur if you are not familiar with the object contents of some BACnet devices.

When you abort a learn, any BACnet objects created (up to the point of the abort) remain in the station database. See Step 4.
Figure 1-4 Status bar updates during operation and ends with Network learn complete.

Abort button. Status bar.

Step 4

When the learnNetwork command has finished, expand the BACnetTemp folder in the Tree View (Figure 1-5, left). A BACnetDevice object will exist for each BACnet device learned by the utility.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

117

Chapter 1 Learning a BACnet Network

Getting Started

Figure 1-5

BACnetDevice objects are created in a BACnetTemp container.

Step 5

In the Tree View, double-click on BACnetDevice to see the child objects created (Figure 1-5, right). This applies if you selected the Learn device contents option. Refer to the the learnNetwork section on page 2-6 for more details. For information on the individual shadow objects created by the BACnetUtility, refer to Chapter 3, BACnet Client Operation.

Notes

Once a BACnet device is learned, it is not polled until you right-click on its associated device object in the JDE Workspace and select enablePolling. This clears the outOfService status for that device object.
Right-click device, set enablePolling Object shape changes from cyan to gray.

On the Config tab of the property sheet for any BACnetDevice, the writePropertyEnabled property must be set to True in order for any input links, object commands, or writes to properties for any of the BACnetDevice objects child objects to become effective (write to the BACnet device). In addition, the remote BACnet device may require local configuration to authorize these writes. Refer to the Properties That Do Not Write to the Device section on page 3-13, for related information on BACnetDevice configuration.

118

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 1

Getting Started Station Engineering Considerations

Station Engineering Considerations


BACnet networks are often big, and may easily contain 100 or more devices. In addition, a single BACnet device may contain hundreds, or even thousands, of BACnet objects. A complete learn (of all BACnet devices and objects) in such a system is typically not desirable. Usually, only some of the objects in any device are of any interest in the station. Also, some BACnet devices have been known to contain many objects that are actually unused. Shadowing these unused objects is actually detrimentalstation resources, processing, and network traffic is increased, but without any payback. For these reasons, it is recommended that a learnNetwork for most BACnet networks is given without the Learn device contents option enabled (cleared). This will make one BACnetDevice container object for each device, with all the device objects residing in the BACnetTemp folder. You can then individually learn each BACnetDevice, using the learnDevice command, along with its instance limits feature (if necessary). For more details, refer to the learnDevice section on page 2-9.

Important General Facts


Although the following topics are explained in full context in various parts of this document, they are important enough to be assembled here for your convenience.
1.

Polling is not automatic for any new BACnetDevice object, whether learned (typical) or if copied from the Local Library (with edited objectIndentifier). Child objects typically appear with a value that was uploaded when the device was learned, but that value will remain frozen unless polling is enabled. To enable polling, find the BACnetDevice in its workspace, right-click it, and select enablePolling. For a related graphic, see the Notes on page 1-19. In order to command remote BACnet objects, or to successfully have Niagara write to object inputs, the writePropertyEnabled property of the parent BACnetDevice object (Config tab) must be set to True. Refer to Properties That Do Not Write to the Device, page 3-13.
Note

2.

In Niagara BACnet releases prior to r2.3.4, the writePropertyEnabled property default value was False, even for learned devices. Note this since changed for learned devices, such that the default value is True. This is a convenience change, because it is typically needed as True.

Also, the remote device (itself) must also permit BACnet writes. This is typically a local configuration matter, and varies from device to device. Please note that if you have any learned device that you wish to remain read-only from Niagara, you should set its devices writePropertyEnabled property value from True to False.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

119

Chapter 1 Important General Facts

Getting Started

3.

In order to allow remote BACnet devices to command or write properties to objects exposed in the station as BACnet objects, you need to define a station user account named BACnet (with proper permissions). Refer to Allowing BACnet Write Access, page 4-6. If exposing Niagara Multistate objects (MultistateInput, MultistateOutput) as BACnet objects, you need to remove the zero (0) field from the stateText property (Visual tab) first. Otherwise, the object will not be exposed. For more details, refer to Multistate Object Considerations, page 4-5. Per the BACnet specification, the outOfService flag for any client object, (BACnetDevice included), actually sets that object to be Out_Of_Service in the remote device. To send alarms, a BACnet device receiving the alarm must be shadowed in the station (as a BACnetDevice), plus the recipientDeviceId must be specified in the BACnetRecipient notification object. Also, Niagara does not add notification classes of a remote BACnet device; our address will need to be added on the third-partys side manually.

4.

5.

6.

7.

BBMD is for IP where a Who-Is or learn operation is required over/through routers. The MAC address is the IP + UDP of the BBMD. See BBMD Support on page 1-12. For more detailed explanations, refer to Configuring BACnet/IP Properties, page 6-18, and BACnet/IP and BBMDs, page E-3.

8.

Niagara supports subscribeCOV for client objects, providing the device supports it on the server side. You must individually enable COV usage for each objectand it is recommended that you do this in some order of importance, as devices often limit the number of COV subscriptions. For more information, refer to Using COV in Shadow Objects, page 3-18. Niagara automatically uses the readPropertyMultiple service for any learned device that supports this service. This increases polling efficiency.

9.

120

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

CHAPTER

Using the BACnet Utility


The Niagara BACnet service provides a BACnetUtility View for use in the JDE. This view provides learn commands to automate the creation of BACnet shadow objects in the station, including a complete set of the child objects within each device. The BACnetUtility also provides standard BACnet application services, such as Who-Is, Who-Has, and Get Alarm Summary. The following main sections are contained: Opening the BACnetUtility Using Network Commands whoIs whoHas learnNetwork Using Device Commands learnDevice getAlarmSummary Manually Adding BACnet Shadow Objects Adding a Device Object Adding a Child Object

Opening the BACnetUtility


The BACnetUtility is the default JDE view for the BACnet service. To open the BACnetUtility in the JDE, expand the services folder in the Tree View and double-click the BACnet service. The utility appears in the Workspace (Figure 2-1).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

21

Chapter 2 Opening the BACnetUtility

Using the BACnet Utility

Figure 2-1

BACnetUtility is default view for BACnetService.

Command selections

Action Buttons (see next section)

Status Line History (expand control)

The BACnetUtility provides two categories of commands you can execute: networksee Using Network Commands devicesee Using Device Commands

Action Buttons
Action buttons appear near the bottom of the BACnetUtility view, described below: ExecuteExecutes the currently selected utility command. After executing any BACnetUtility command, output results appear in the main window. A right-side scroll bar appears whenever results exceed the main area. SaveProduces a dialog box for you to save the last command results to file, including controls to specify any target drive or directory on your PC. Use MS Word, Wordpad, or a similar programs to work with saved files.

AbortApplies to learn type commands only. Stops any learn in progress.

Status Line History


At the bottom of the BACnetUtility view is the status line, showing the last line of output results from the last command. To see all command results (since first opening the utility), click the expand control. A Status Line History window appears, showing the results of the first command through the most recent. As needed, use the scroll bar to view items of interest.

22

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 2

Using the BACnet Utility Using Network Commands

Using Network Commands


Under the network category, there are three commands available: whoIsDiscovers possible BACnet devices on the network. whoHasSearches for a specific BACnet object by name or object ID. learnNetworkCreates shadow objects for devices and optionally, children.

The whoIs and whoHas commands work with complimentary I-Am and I-Have services offered by networked BACnet devices. All of these BACnet services are unconfirmed types.

whoIs
This command is for the BACnet Who-Is service. By default, the station issues a globally broadcast Who-Is, sent to all possible BACnet devices (Figure 2-2). Sections ahead describe WhoIs options and results.
Figure 2-2 WhoIs dialog box, showing default settings.

Options

The WhoIs dialog provides two types of options: Device Instance Limits Wait Time for I-Am

Device Instance Limits


By default, the device instance limits option is clearedthe entire possible BACnet device ID range receives the Who-Is broadcast. If you check this option, you can enter a low limit and high limit for BACnet devices to respond to the Who-Is. Low and high limits are inclusive. For example, if you specify a low limit of 50 and a high limit of 60, you should receive no more than 11 total responses, namely for devices with device IDs of 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, and 60. If only a single device is wanted, simply enter the same number for low limit and high limit. In the case of misconfiguration, multiple devices may be assigned the same numerical device ID, and you may see duplicates using the same number.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

23

Chapter 2 Using Network Commands

Using the BACnet Utility

Wait Time for I-Am


The wait time applies after you click OK (to issue the Who-Is command) before the received I-Am results are posted in the BACnetUtility window. The default value of 5 seconds may be sufficient where there are relatively few devices, or perhaps where they are all BACnet/Ethernet or perhaps BACnet/IP. In general, however, a longer wait time is recommendedperhaps 60 seconds or higher, especially if MS/TP devices exist or if there are many BACnet routers.

Results
Results from the whoIs command display in the utility window, in order of being received. Each I-Am message contains five pieces of information about that device: Device IdentifierThe object identifier of the Device object in the device. Maximum APDU Length AcceptedThe largest PDU, in bytes, handled by the devices BACnet application layer. The Niagara max APDU is 1500 bytes. Segmentation SupportedWhether message segmentation is supported by the device: either no, transmit, receive, or both, where both is best. Vendor IdentifierUnique number assigned to the vendor for the device. Currently, vendors by number are listed at the BACnet org website at URL:

http://www.bacnet.org/VendorID/BACnet%20Vendor%20IDs.html

Source Addresslists network number1, devices BACnet MAC address.


The whoIs command can find all BACnet devices on the network.

Figure 2-3

On the server-side, a Niagara station sends an I-Am message to respond to Who-Is service requests from other networked BACnet devices. In addition, the station sends an I-Am message upon each station startup (power up, reboot, or restart).
1. Network number matches that configured on the corresponding link-layer tab in the Niagara BACnet service. BACnet devices that are connected to a single network may not actually know their network number.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

24

Chapter 2

Using the BACnet Utility Using Network Commands

whoHas
This command launches a dialog box to set parameters for the BACnet Who-Has service (Figure 2-4). Using this command, you can search networked BACnet devices for specific objects by name or by object ID (combination of object type and instance number). Devices respond using the I-Have service. You can further request that only devices within a certain device ID-range respond to the Who-Has request.
Figure 2-4 WhoHas dialog allows search by object name or object ID.

Select search either by object name or object ID. If by name, the exact name is needed. See Note below. If by object ID, you must select an object type and a specific instance number. Check device instance limits only if you want to limit the Who-Has search to a range of devices, for example, 5 to 15.

Note

If searching by object name, note the name is case-sensitive and must be complete (no wildcard characters). In addition, the I-Have service in a Niagara station responds to a Who-Has-by-name search request only if the objects swid is given. When the service executes, it returns an I-Have message from any networked BACnet device that meets the search parameters. Each I-Have message returns three pieces of information from that device: Device IdentifierThe device objects identifier. For example, device: 14. Object IdentifierThe object identifier of the target object in that device. Includes object type and instance number. For example, analog_inpuput: 1. Object NameThe objects BACnet name. For example, ExhDamper1.

Figure 2-5 Example WhoHas results.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

25

Chapter 2 Using Network Commands

Using the BACnet Utility

learnNetwork
The learnNetwork command provides a single-click method to create BACnet shadow objects in the station for all currently communicating BACnet devices. For step-by-step instructions, refer to Learning a BACnet Network, page 1-15. You can select LearnNetwork to create shadow objects for: Only BACnet devices, which is the default and recommended setting. Both devices and all their contained (child) objects (Learn device contents). If creating child objects, to create only Lite objects. These objects expose only BACnet-required properties, and omit all optional properties. Variations of the above for any range of devices, by device instance number. This works as in the whoIs command, see Device Instance Limits, page 2-3

Note

The default LearnNetwork dialog is shown in Figure 2-6.


Figure 2-6 User dialog for LearnNetwork command.
Learn device contents creates all objects under every device. Recommendation is to leave this cleared. Then use Use lite objects applies only if learning device contents. Device Instance Limits narrows range of devices to learn. Default is all possible devices (up to 4194302 devices). Wait time to receive all I-Am messages, before shadow object creation process starts. Default is 5 secondsadjust upwards if many devices, BACnet routers, etc.

Notes

Once a BACnet device is learned, it is not polled until you right-click on its associated device object in the JDE Workspace and select enablePolling. This clears the outOfService status for that device object. Typically, you should also configure each BACnetDevice object. Refer to the BACnetDevice Notes section on page 3-11 for more information. If you move a BACnet device object from the BACnetTemp folder, the learn device contents option of LearnNetwork has no further effect on it. However, you can still use the learnDevice command from the device Category.

26

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 2

Using the BACnet Utility Using Network Commands

How it Works

The learnNetwork command performs a number of actions, executed in this manner:


1. 2. 3. 4.

A Who-Is request looks for all BACnet devices within the specified range. Each unique I-Am response received represents a single BACnet device. If BACnet devices are discovered that do not already have a corresponding shadow object, a folder called BACnetTemp is created (if not already existing). A device object for each newly-discovered device is created in BACnetTemp. Properties for each BACnetDevice object are uploaded. If LearnDevices was selected, BACnet shadow objects for all AI, AO, AV, BI, BO, BV, MSI, MSO, and MSV objects are created under each BACnet device object, where: a. If Use lite objects was selected, lite versions are created. b. If Use lite objects was cleared, full versions are created. Object properties are uploaded, along with a value and status (at time of shadow object creation). However, values remain static until you give the parent BACnetDevice object an enablePolling command.

Note

If the learnDevice encounters a device limit, which may occur after 31 devices are learned for an MS/TP trunk, or for 27 total BACnet devices if a JACE-403, a message similar to the following is displayed: Unable to create shadow object for device <deviceName> [deviceId], addr <address> due to device count limitations When doing a learnNetwork command but not learning devices, you would get a return similar to the following.
Figure 2-7 Example learnNetwork with options cleared (not learning devices).

Examples

As shown in the example above, no device child objects were created. In this particular case, a BACnet device object for device 14 already existed. If instead you ran learnNetwork and included learning device options, you would get a return similar to one shown in Figure 2-8.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

27

Chapter 2 Using Network Commands

Using the BACnet Utility

Figure 2-8

Example learnNetwork with Learn device contents option selected.

Note

If you click Abort during a learnNetwork, all BACnet objects created up to that point remain in the station database. The object shape (glyph) for each BACnetDevice shows both the associated BACnet network number as well as the devices instance number, as shown in Figure 2-9.
Figure 2-9 BACnetDevice shape in JDE shows network and Device instance numbers.
This BACnetDevice object shadows BACnet device 501 named Btest19, located on network 85.

BACnetDevice Shape Information

This BACnetDevice object shadows BACnet device 103 named device_103, located on network 11.

In the case of a BACnet internetwork (multiple networks) you may find this information useful. For example, you can cut and paste devices from the BACnetTemp container to a new container you have created for a particular BACnet network, where you can perform the learnDevice command on each device. For more information on the learn device utility, see learnDevice, page 2-9. For information about shape information for child shadow objects, refer to Shape Information, page 3-16.

28

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 2

Using the BACnet Utility Using Device Commands

Using Device Commands


Under the Category device, there are two commands available: learnDeviceCreates child shadow objects for the selected BACnet device. getAlarmSummaryReturns a list of object identifiers in the device that are currently in an alarm state. This is a standard BACnet application service. You can run the learnDevice command even if the device was previously learned.

learnDevice
As with the learnNetwork commands Learn Device option, you can select BACnet shadow objects to be either full or Lite types. In addition, you can specify whether or not: Existing shadow objects should be re-uploaded (overwritten in the station). Instance number limits should be used, available for each object type.

Procedure 2-1 Using the learnDevice command.

Step 1 Step 2 Step 3

Start the BACnetUtility by double-clicking on the BACnet service. From the Category drop-down list, select device. From the Device drop-down list, click the target device. Only devices with BACnet device shadow objects created with learnNetwork (or that were manually added from the Local Library) will appear in the list. Verify the Command drop-down list shows learnDevice, and click Execute. The LearnDevice popup dialog appears (Figure 2-10).
Figure 2-10 LearnDevice popup dialog to set Learn Device options.

Step 4

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

29

Chapter 2 Using Device Commands

Using the BACnet Utility

Step 5

As needed, select or clear the LearnDevice options: Upload existing objectsIf checked, existing shadow objects in the station are recreated (in addition to any new objects). If cleared, only new shadow objects are created. Use lite objectsIf checked, Lite shadow objects are created. If cleared, full versions of shadow objects are created. Wait time for device I-Am response (sec)Default is 5 seconds. You may wish to adjust this upwards if the device is reached through a router. Use instance limitsBy default, this option is cleared. If checked, these other fields in the dialog become active: Object type Instance Number Range Configured Types (read-only) If left cleared, skip ahead to Step 7.

Note

The need for instance limits depends on a number of factors. Instance limits are useful when a device contains an extraordinarily large number of BACnet objects. For example, a device may contain 1000 Analog_Value and 1000 Binary_Value objects, although only a small portion are actually used. If you do not define instance limits for that portion, learnDevice will create shadow objects for all object instances, needlessly consuming both station resources and your time. For the example device with 2000 objects, learn time without instance limits could easily take from 3 to 4 minutes to much longer, depending on a number of factors. You would also see only a small portion of the objects in the workspace of the BACnetDevice, although they would be visible in the Tree View. When engineering a station, you typically wish to limit the creation of shadow objects among devices. For example, you may know that for a particular device, the only objects of interest are Analog_Inputs in the instance range from 5 to 20, Analog_Values under instance 10, and Binary_Outputs instances 1 and 2. By specifying these instance limits (and none for other object types) before executing the learn, only objects of interest are learned. Without instance limits, a learn would probably create objects you would then have to delete, in order to have adequate allocation of client objects among devices. Furthermore, for any device you can rerun learnDevice with different instance limits as many times as needed. This is one strategy to avoid having objects unavailable in the device container workspace. Here, you could create sub-containers under the BACnetDevice, and cut and paste groups of learned objects (as needed) into them.

Step 6

As needed, set the instance limits needed for each object type in the device, following these substeps.
a. b.

From the Object type drop-down list, select an object type. In the Instance Number Range field, type a number range or ranges. Use a hyphen (-) in a range and a comma (,) between numbers or ranges.

210

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 2

Using the BACnet Utility Using Device Commands

For example: 1-5,12-16,19,205-207 specifies object instances 1, 2, 3, 4, 5, 12, 13, 14, 15, 16, 19, 205, 206, and 207.
c.

Press ENTER to configure this instance range for the selected object type. The object types abbreviation will appear in the Configured Types field, as shown in Figure 2-11. You must press ENTER to enter the instance range for any object typenote that this does not trigger the learn, but only enters the range.

Note

d.

Repeat, as necessary, starting again at step a for each object type requiring instance number limitations. The default instance range for any object type is all. You can re-enter all, if needed, for any object typethis removes instance limits for that type. You can also enter none, if needed, to prevent the learning of that particular object type. You see a final summary of instance ranges when you click OK.
Use the ENTER key after setting instance limit range(s) for each object type.

Note

Figure 2-11

Use the drop-down control to select each object type that requires instance limits. Type the instance limits needed for the selected object type, hitting ENTER when done.

Abbreviations for all object types that have been assigned instance limits appear in Configured Types.

Step 7

When options are set as needed, click OK. The LearnDeviceContinue popup displays, showing instance limits (Figure 2-12). If you are not using instance limits, all object types will show all.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

211

Chapter 2 Using Device Commands

Using the BACnet Utility

Figure 2-12

LearnDeviceContinue popup lets you review what objects can be learned.


If instance limits are not used, all possible object types show all, as shown here.

Finish launches the LearnDevice routine, creating shadow objects as defined.

Back returns you to the LearnDevice dialog, where you can adjust instance limits as needed.

To start LearnDevice, click Finish, or To set or change any instance limits, click Back. (You may need to check Use Instance Limits, if not previously checked.) Follow Step 6 to apply instance limits by object type. As LearnDevice operates, results display in the utility window (Figure 2-13).

Figure 2-13 LearnDevice results display in the BACnetUtility window.

212

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 2

Using the BACnet Utility Using Device Commands

Notes

The learnDevice command works regardless of where the device shadow object is located in the station database (does not need to be in BACnetTemp). Existing lite shadow objects in a device, if any, are not converted to full objects even if Upload existing objects is selected and Use lite objects is not. If you need full versions, select and cut the existing lite ones from the station database, and then rerun the learnDevice command. When existing shadow objects are uploaded, device-resident properties are relearned, but Niagara-related properties such as description and executionParameters remain unchanged. Object links also remain unaffected. If you want to exclude any object type(s), select Use instance limits and enter none for the Instance Number Range, as needed, for each object type. Instance limits does not affect any existing shadow objects that do not fall into the entered number range.

getAlarmSummary
The getAlarmSummary command returns a list of object indentifiers in a device that are currently in alarm. You can use this command on any BACnet device on the network that has a device shadow object (regardless if it has child shadow objects).
Procedure 2-2 Using the getAlarmSummary command.

Step 1 Step 2 Step 3

Start the BACnetUtility by double-clicking on the BACnet service. From the Category drop-down list, select device. From the Device drop-down list, click the target device. Only devices with BACnet device shadow objects created with learnNetwork (or that were manually added from the Local Library) will appear in the list. From the Command drop-down list, click getAlarmSummary, and click Execute. The device is queried and the results appear in the utility window (Figure 2-14).

Step 4

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

213

Chapter 2 Manually Adding BACnet Shadow Objects

Using the BACnet Utility

Figure 2-14

The getAlarmSummary command queries the device for active alarms.

Results show three pieces of data for any object currently in an alarm condition: Object IdentifierThe object type and instance number. Alarm StateThe current value of the objects Event_State property. Acknowledged TransitionsThe value of the objects Acked_Transitions property. A missing transition means an acknowledgement is still pending.

Notes

Object names are not returned by the BACnet GetAlarmSummary service. However, you can use the network command whoHas, and search on the appropriate object Id, limiting the device instance high and low to the target device, in order to see the object name. A Niagara station can also generate and receive (and reformat) BACnet alarms. Refer to Chapter 5, Configuring BACnet Alarming, for more information.

Manually Adding BACnet Shadow Objects


As an alternative to using the BACnetUtility learn commands, you can manually add BACnet shadow objects (Device and various child objects) to the station. To do this, you need to copy the objects to the station database from the Local Library. However, you will need specific details about the BACnet objects for correct communications and operation. These details are automated by the learn commands. For this reason, manual addition of shadow objects is not typically done, except for the writable types of input objectsthese objects must be added manually. Writable input objects provide a linkable input that allow you to simultaneously override the objects present value and set it to out_of_service. Adding a Device Object Adding a Child Object

214

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 2

Using the BACnet Utility Manually Adding BACnet Shadow Objects

Adding a Device Object


To manually add a BACnet device shadow object, you must know the instance number of its Device object. Essentially, this is the unique logical address for the device on the BACnet network (or if multiple networks, across the entire BACnet internetwork).
Procedure 2-3 Adding a BACnetDevice object.

Step 1 Step 2 Step 3 Step 4

Working in the Tree View of the JDE, open the Local Library. Expand the /niagara/<release>/tridiumx folder to reveal the bacnet jar file. Expand the objects folder, right-click on BACnetDevice, and select Copy. In the station database, expand the database to select the target container. You can put the device object wherever it logically makes sense. Right-click and select Paste. Right-click the object and select Go > Properties to open its property sheet. Edit the Config property objectIdentifier, Instance Number, to the correct value. This automatically causes a network command whoIs, which should populate the objects address property value with the correct MAC Address. Select upload from the Commands menu, then Yes (you wish to upload). The status bar (at the bottom of the window) updates with upload progress data. You can verify the upload by looking at various Config properties of the object, for example, objectName and vendorId, which should have values.

Step 5 Step 6 Step 7

Step 8

Notes

Typically, you would rename a manually created BACnetDevice object. You can use its objectName (or some portion), and combine it with instance number, if neededfor example, Alerton3_AHU1. A newly-added BACnetDevice object is outOfService, by default. You can give the enablePolling command to clear this status. This also causes any child objects created for the device to be immediately polled.

After you add a BACnetDevice, it appears in the BACnetUtility under the drop-down list of Devices, and the LearnDevice command is available. If adding a BACnetDevice object that represents an MS/TP slave device, you must also enter its network number and MAC address (in hexadecimal). For more details, refer to Working with Slave Devices, page F-18. Be aware that if attempting to add a device object where the allowed limit of BACnetDevices already exist, you will receive an error message and the object will not be created. This scenario might come up if adding more devices on the same BACnet MS/TP trunk than allowed in the license, or whenever 27 total BACnet devices already exist in a JACE-403 station database.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

215

Chapter 2 Manually Adding BACnet Shadow Objects

Using the BACnet Utility

Adding a Child Object


To manually add a BACnet shadow object for a device, you first need to determine:
1.

The type of BACnet object to be shadowed. Available shadow object types in the Local Library include both lite and full versions of these types: AnalogInput AnalogOutput AnalogValue BinaryInput BinaryOutput BinaryValue MultistateInput MultistateOutput MultistateValue MultistateValuePriority

AnalogInputWritable BinaryInputWritable MultistateInputWritable

AnalogValuePriority BinaryValuePriority
2.

The numeric instance number (Object_Identifier) for that object.


Adding a child object.

Procedure 2-4

Step 1 Step 2 Step 3 Step 4

Working in the Tree View of the JDE, open the Local Library. Expand the /niagara/<release>/tridiumx folder to reveal the bacnet jar file. Expand the objects folder, right-click on the object needed, and select Copy. In the target container in (or under) the appropriate BACnetDevice, or in the WorkPlaceEditor view of this container, right-click and select Paste. Open the objects property sheet and edit the Config property: objectIdentifier, Instance Number. Select upload from the Commands menu, then Yes (you wish to upload). The status bar (at the bottom of the window) updates with upload progress data. You can verify communications by looking at the objects Status property presentValue, which should have a value. After uploading the object, you should rename it to match the BACnet object being shadowed in the device (this is automatically done when adding objects using learn device commands in the BACnetUtility). To rename the object: On the Config tab of the objects property sheet, highlight the objectName. b. Press CNTRL-C to copy the name to the Windows clipboard. c. Highlight the object in the Tree View (or select it in the WorkspaceEditor of the BACnetDevice container), right-click, and select Rename. d. With the current name highlighted, press CNTRL-V (this pastes the copied objectName into the Rename dialog). Press OK.
a.

Step 5

Step 6

Step 7

Note

In general, it is recommended that you use the BACnetUtility learn device commands rather than manually adding shadow objects. When adding objects manually, there is a risk of mismatched types and/or instance numbers.

216

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

CHAPTER

BACnet Client Operation


As previously mentioned, remote BACnet objects are modeled locally within a Niagara station as shadow objects. Essentially, these objects act as the interface to a stations BACnet client operation. The following main topics are explained ahead: About BACnet Shadow Objects About Lite BACnet Objects About Writable Input Objects BACnet Integration Objects

BACnetDevice BACnetAnalogInput BACnetAnalogOutput BACnetAnalogValue BACnetBinaryInput BACnetBinaryOutput BACnetBinaryValue BACnetMultistateInput BACnetMultistateOutput BACnetMultistateValue

BACnetAnalogInputWritable BACnetAnalogValuePriority BACnetBinaryInputWritable BACnetBinaryValuePriority BACnetMultistateInputWritable BACnetMultistateValuePriority

About BACnet Shadow Objects


BACnet shadow objects provide station access to BACnet objects in networked devices, including input and output link access. BACnet shadow objects have common characteristics, explained below. The entire collection of BACnet shadow objects can be divided in 2 classes: BACnetDevice objectA container that can reside anywhere in the station database. Each represents an individual BACnet device. BACnet objects (children)Can reside only under a BACnetDevice object. There are 15 types available, with 2 versions of each type (full or lite).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

31

Chapter 3 About BACnet Shadow Objects

BACnet Client Operation

Property Types
Each BACnet child (data) object has a polled property, statusOutput, that appears on the objects shape, as shown in Figure 3-1. This ouput represents current values polled1 from the source objects properties statusFlags and presentValue.
Figure 3-1 Each statusOutput (sOut) property is a polled ({P}) property.

statusOutput reflects statusFlags by color in Niagara, both for object shape and statusOutput. See Object Color and Status, page A-2.

Provided that polling is enabled (at the parent BACnetDevice level), statusOutputs of child objects continuously update. If the object is a type with a priorityArray input (AO, AVP, BO, BVP, MSO, MSVP), the source objects priorityArray property is also updated through polling.

On Demand Transient

Apart from statusOutput and priorityArray, most other properties of BACnet shadow objects are considered on_demand_transient types in Niagara. These property values are captured in any upload (from the device to Niagara), but are not stored in the station database. An upload occurs automatically whenever a device is learned, that is, when each object was initially created in the station. Following this initial upload, a fetch command (or upload command) is necessary to refresh these values. These commands are available at the individual object-level, either as right-click or JDE menu bar commands. An uploadAll command is also available at the device-level.
Notes

After a station restart, the on_demand_transient properties will show default values (0.0 or false). For any BACnet object of interest, a fetch command will be necessary. An uploadAll command (at the device level) can also be used. Many of these properties are persistently-stored by the BACnet (foreign) device. They are indicated on property sheets by an {F} in the property label:
covIncrement {F} <value>

A few of these {F} properties are also persistently stored in a Niagara station. These properties are description, objectName, units (for analog types) and stateText (for multistate types). These properties are the principle difference between a fetch and an upload. A fetch does not replace these values in the station, whereas an upload does.

1. Child objects using COV have statusOutput updates from COV notifications.

32

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation

About Lite BACnet Objects


Lite shadow objects include only required properties for that BACnet object type. Starting in Niagara r2.3.4, each Lite object appears in the JDE Workspace with extra -Lt text in the object shape to differentiate it from a full object.
Figure 3-2 Lite object shapes include the text -Lt after the object type abbreviation.

Lite objects have -Lt after type abbreviation inside object shape. For example: AVP-Lt MSI-Lt and AO-Lt.

Full objects show the type abbreviation, but without -Lt.

Lite objects are the best choice for a device that contains objects with only required properties, and few (if any) optional properties. Usually, optional properties relate to event (alarm) detection, and occasionally an isolated configuration property (for example, resolution).

Tip

If in doubt, use the BACnetUtility to learnDevice, clearing the option Use lite objects. This creates full BACnet shadow objects. Then open the property sheet for a representative shadow object, and click the Fetch button. The status bar at the bottom of the window shows updates, including errors. Click the pointer in the lower-right corner to open the Status Line History. Any read failed for property <propertyName>:unknown-property entries indicate that these optional properties are not implemented in that device.

Notes

Object descriptions given in sections ahead (for the different types of BACnet shadow objects) do not include separate sections for the Lite objects. Instead, those properties not included in Lite objects are noted as not Lite objects. There is no Lite version of a BACnetDevice object. For any type of shadow object, there is no difference in inputs and outputs (or object shape) between its full version and its Lite version.

About Writable Input Objects


Starting in Niagara r2.3.4, writable versions of BACnet AnalogInput, BinaryInput, and MultistateInput objects are available for manual copy and paste from the Local Library (Figure 3-3). Both full and lite versions of these objects are available. You can use these writable objects in place of the standard equivalent input objects.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

33

Chapter 3

BACnet Client Operation

Figure 3-3

Writable input objects must be copied from the bacnet JAR in the Local Library.

Writable input types operate exactly like normal input objects. However, writable objects have one important addition: a linkable statusInput that allows you to force the target object to a Niagara value with an out_of_service status. Whenever this input value returns from an out_of_service state, the input value is ignored and the source object is under local device control. See Figure 3-4 for an example.
Figure 3-4 Writable input objects respond to an out_of_service statusInput.

Writable input object, linked to another object.

Here, the linked AO is first commanded to a value (in this case 123 ). Then the AOs outOfService property is set to True, as shown below.

Input value is ignored if input is not out_of_service.

While its statusInput is out_of_service, the writable input BACnet object uses the input value as present value, and its own statusFlag is set to out_of_service.

Use of this feature is expected to be atypical, perhaps for early commissioning or application testing. For more information on manually adding objects, see Manually Adding BACnet Shadow Objects, page 2-14.

34

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetDevice

BACnet Integration Objects


This section provides descriptions of all the BACnet shadow objects. Covered first are details on the BACnetDevice object, then properties common among all (child) BACnet shadow objects. Right-click commands for these objects are also explained. BACnetDevice BACnet objects (children)

BACnetDevice
abbrev: Device n The BACnetDevice object is the Niagara shadow object representing a remote BACnet device. Specifically, it shadows the BACnet Device object in that device. This is a container object, under which BACnet (child) shadow objects can exist (either directly, or in other containers such as PollAlways and PollOnDemand). The BACnetDevice can be pinged by the BACnet service to determine if the device is still communicating.
Default Resource Count: 78 to 107, plus the sum of all child object resource counts.
Inputs

Default Object Shape


Outputs

All Used Inputs / Outputs


Inputs
(not shown): executeTrigger

Outputs
systemStatus deviceDown

Input/Output Property Reference for BACnet Device Object


(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe system down

Property Name
executeTrigger systemStatus deviceDown

Data Species
TriggerType BACnetDeviceStatusEnum BooleanStatusType

Shape Information

Numbers (n) inside the BACnetDevice object shape (Figure 3-5) reflect as follows: Net nBACnet network number. Matches network number1 on the services link-layer tab if a local network, or is a different number if a remote network. Dev nUnique instance number of that devices Device object.

In addition (if the object was created by the learnNetwork command), the name of the object is the Device objects name.
Figure 3-5 BACnetDevice shape in JDE shows network and Device instance numbers.
This BACnetDevice object shadows BACnet device 501 named Btest19, located on network 85.

This BACnetDevice object shadows BACnet device 103 named device_103, located on network 11.

1. BACnet devices do not typically know their BACnet network, unless they have router functionality (such as Niagara station). However, devices do know their device instance number, which must be unique across all possible interconnected BACnet networks.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

35

Chapter 3 BACnetDevice

BACnet Client Operation

BACnetDevice Links

The BACnetDevice object has three linkable properties: executeTriggerAn input that is rarely (if ever) used. systemStatusAn output, using data species BACnetDeviceStatusEnum. This output reflects the value of the BACnet Device objects System_Status property, as one of the following: operational operational_read_only download_required download_in_progress non_operational deviceDownAn output, using data species BooleanStatusType. Remains active (true) while the BACnet device status/ping mechanism detects the device is down. (All child objects and their outputs are down in this state.) Can be connected to control logic for fallback schemes, if desired.

Notes

Updates to systemStatus and deviceDown outputs require device status/ping to be enabled. Refer to Configuring Device Status/Ping, page 6-15. The device status ping automatically marks a BACnetDevice as down whenever the received response is non-operational.

Typically, the systemStatus output is linked to a StringLog object (set to log on change-of-value) and/or a GxText object to display current device status. If the devices systemStatus is needed as part of a control scheme, a Program object can be used to convert the BACnetDeviceStatusEnum input and produce an output using another Niagara data species. See Figure 3-6 for an example.
Figure 3-6
Program object

Program object linked to the systemStatus output of a BACnetDevice object.

(TRIPL program code used for this Program object): //Example for systemStatus to IntegerStatusType input BACnetDeviceStatusEnum deviceStatusIn output BACnetDeviceStatusEnum deviceStatusOut output IntegerStatusType devStatOut deviceStatusOut = deviceStatusIn if deviceStatusIn == "operational" devStatOut.value = 0 devStatOut.status.inAlarm = false elseif deviceStatusIn == "operational_read_only" devStatOut.value = 1 devStatOut.status.inAlarm = false elseif deviceStatusIn == "download_required" devStatOut.value = 2 devStatOut.status.inAlarm = false elseif deviceStatusIn == "download_in_progress" devStatOut.value = 3 devStatOut.status.inAlarm = false elseif deviceStatusIn == "non_operational" devStatOut.value = 4 devStatOut.status.inAlarm = true endif

BACnetDevice object

Note: The BACnetDevice object must be enabled for polling (gray), as shown here. A device object set to pollingDisabled (cyan) or that is down (yellow) will not have an accurately reflected systemStatus.

36

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetDevice

BACnetDevice Commands

The BACnetDevice object provides numerous right-click commands in the JDE Workspace (or when accessed using a Web browser through a linked Gx object). The following right-click commands are available: These commands require user security privileges of Command, Std. fetchQueries the device and updates all on_demand_transient-type object properties for this device object. disablePollingStops the periodic polling of all contained BACnet shadow objects. The device objects statusFlags property is set to outOfService and the Engineering property pollingEnabled is set to False. However, all contained BACnet objects continue processing. enablePollingStarts the periodic polling of all contained BACnet shadow objects. The outOfService flag is cleared from the objects statusFlag property and the pollingEnabled property is set to True. uploadUploads on_demand_transient and foreign_persistent-type object properties from the Device object, and updates them in this shadow object. uploadAllUploads on_demand_transient and foreign_persistent-type object properties from the Device object and all of the devices (child) BACnet objects, and updates them in the stations shadow objects. downloadAllDownloads on_demand_transient and foreign_persistent-type object properties from the stations shadow objects (device and all child objects) to the devices BACnet objects. getAlarmSummaryEquivalent to the same command in the BACnetUtility. Results are sent to the stations Standard Output.

Note

When using the JDE, the following additional right-click commands are available for the BACnetDevice object: readPropertyUploads only the specified property entered in the Command Arguments dialog box (default is presentValue, not applicable for a device). The property is updated in the objects property sheet. Requires the Niagara property name, for example, apduTimeout. readPropertyMulitpleUploads only the specified properties (default is presentValue, again not applicable) entered in the Command Arguments dialog box. Uploaded properties are updated in the objects property sheet. The device must support the ReadPropertyMultiple service. Requires use of Niagara property names, using a comma (,) for a delimiter between properties. For example: apduTimeout,systemStatus,location.

BACnetDevice Properties

Table 3-1 lists important properties for the BACnetDevice object. These properties are in addition to the standard Niagara properties common among all object types, such as executionParameters, position, and securityGroups.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

37

Chapter 3 BACnetDevice

BACnet Client Operation

Table 3-1

BACnetDevice object, important properties.

Tab Property Name


objectType statusFlags

Description
Read Only: The BACnet object type. Read Only: Current Niagara state of the shadow device object, as one of these:

Valid Values
BACnetDevice (appears in braces { }) ok, outOfService, down

Default
see Notes

Notes
The default for a newly learned (created) BACnetDevice object is {outOfService}. Not a BACnet property for a Device object.

Always BACnetDevice

okPolling is enabled. outOfServicePolling is disabled. downThe device status ping mechanism


cannot detect the device, or a response non_operational was received. description Read/Write: User-defined text descriptor for the device. Any printable characters, including spaces and mixed case characters. Read Only: Current BACnet device physical and/or logical state, as one of the following:

See descrip.

systemStatus

See descrip.

See descrip.

operational (the default) operational_read_only download_required download_in_progress non_operational

Status

Available as a linkable output, using the BACnetDeviceStatusEnum data species. See Figure 3-6 for an example. As stated in the BACnet spec, the exact meaning of these states (and how they affect the BACnet services of the device) are left as local matters.

Note: Property updates require device status pings from the BACnet service. Ensure that the deviceStatusDisabled property of the BACnet service is set to False, and that the device object is set to pollingEnabled (object is gray). A device object set to pollingDisabled (cyan) or that is down (yellow) will not have an accurately reflected systemStatus or deviceDown state.
deviceDown Read Only: Remains true (Down) while device status pings go unanswered, or if the systemStatus response is non_operational. Same note as above applies. objectIdentifier, Object Type Instance Number objectName Read Only and Read/Write: Object Type field is read-only, and is device. Instance Number is read/write (integer) and defines the Device object instance number. Read Only: The Device objects name. device <integer>, 1 to 4194302
(BACnet max)

false: {ok}, Down

false (ok) Available as a linkable output, using BooleanStatusType data species. device -1 Instance Number must be unique across the internetwork of BACnet devices. Uploaded from device.

Note: If another r2.3.5 or later Niagara host, is <stationName>_<instanceNumber>


Config. address, Network Number, MAC Address Read/Write: (Values typically are defined automatically in the learnNetwork utility). Network Number defines the network connection to a BACnet router. MAC Address depends on the link-layer used by the BACnet service (Ethernet, IP, MS/TP), and is either: 0 to 65534, valid MAC address 0, null Typically, Network Number matches one on one of the enabled link-layer tabs in the BACnet service (local network). If on a remote network, that is, on the far side of a BACnet router, the network number will be a different number.

Ethernet adapter MAC address, in hex IP address and UDP port, in hex If MS/TP device, a number from 1 to 253.

38

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetDevice

Table 3-1

BACnetDevice object, important properties. (continued)

Tab Property Name


vendorName vendorId

Description
Read Only: Text descriptor for the manufacturer of the device. Read Only: The numeric identifier unique to the vendor. Read Only: Text descriptor assigned by the vendor to define the model of the device. Read Only: Text descriptor for device firmware revision, assigned by the vendor. Read Only: Text descriptor for the application version, typically assigned by the devices application programmer. Read Only: Text descriptor that can be used to describe the devices physical location. Read Only: Defines the version of BACnet protocol supported by the device. Read Only: Defines the minimum set of services, objects, and properties supported, by conformance class number. Read Only: Defines which standardized BACnet services the device supports. A drop-down list shows supported services.

Valid Values

Default

Notes

Refer to the BACnet vendor ID information at www.bacnet.org.

modelName firmwareRevision application SoftwareVersion location protocolVersion protocol ConformanceClass Config, cont protocolServices Supported

1 1 to 6

0 0 See the BACnet spec for more details. A station running the BACnet service (currently) is class 3. Use this information to set the 2 supported config properties (Figure 3-9) accordingly.

Many types possible. See Figure 3-7.

protocolObjectTypes Supported maxApduLength Accepted segmentation Supported

Read Only: Defines which standardized BACnet objects the device supports. A drop-down list shows the supported types. Read Only: Defines the maximum number of octets that can be contained in a single, indivisible APDU. Read Only: Determines if message segmentation is supported, and if so, for transmit and receive. Possible values are:

Many types possible. See Figure 3-8. Minimum of 50

See the BACnet spec for more details. Niagara supports message segmentation.

See Descrip.

See Notes


utcOffset

segmented_both segmented_transmit segmented_receive no_segmentation -780 to 780, integer False, True 0 See the BACnet spec for additional details.

Read/Write: Defines the number of minutes between local standard time and Universal Time Coordinated Read/Write: Defines whether daylight savings time is in effect at the devices location.

daylightSavings Status

False

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

39

Chapter 3 BACnetDevice

BACnet Client Operation

Table 3-1

BACnetDevice object, important properties. (continued)

Tab Property Name


apduSegment Timeout apduTimeout

Description
Read/Write: Defines the time period, in milliseconds, between APDU segment retransmissions. Read/Write: Defines the time period, in milliseconds, between APDU retransmissions when an APDU requiring acknowledgement was not acknowledged. Read/Write: Defines the maximum number of times an APDU can be transmitted. Read/Write: Specifies whether Niagara can use the BACnet ReadPropertyMultiple service for client access to the device. This service reduces communications load.

Valid Values

Default
2000

Notes
Default values (as shown) are typically used. In the case of a Niagara station, these values are defined in the BACnet service. In general, BACnet recommends all devices use the same values. Any learned device (that supports this) automatically has this property as True. Automatically set to True if device was learned (learnNetwork). If set False, acts as an interlock to prevent unintended writes (if needed). See Figure 3-9.

3000

numberOfApdu Retries Config, cont. readProperty MultipleSupported

False, True

False

writePropertyEnabled Read/Write: Determines if a property write to a devices Niagara shadow object results in a write to the devices BACnet object (providing the server device authorizes this). Set this to True if linking child objects, issuing commands, or writing properties.

False, True

False

userData

Engineering

Read-Write: String-type property common to Any string most Niagara objects. Usually left blank, value for unless special servlet or API access is used. servlet/API use, Note: In Niagara r2.301.429 and later, you or can use this property to specify a poll delay to throttle back the poll rate, as applied to pollDelay=n each child object. This is done with a poll where n is delay value, defined in milliseconds, using number of ms this specific entry: delay for the pollDelay=n BACnet poll For example, service before pollDelay=80 polling each child object.

Poll delay feature does not apply to MS/TP devices or objects. Delay feature is useful only if target device cannot keep up with normal poll rate. Delays added this way append to the overall poll cycle time, (does not help slow polling). Delay is in addition to any imparted by services interNodeDelay.

localTime

Read-Only: The time as local in the device, reflecting any UTC offset and daylight savings status (if receiving a UTCTimeSynchronization message). Read-Only: The date as local in the device, to the best of the devices knowledge. Read/Write: (Applies to MS/TP device only) If a master node, specifies highest possible address for master nodes. A value of 127 indicates it is not writable.

hh:mm

12:00PM

localDate maxMaster

dd mm yyyy -1, 0 to 127

1 Jan 1970 -1

These property values can be fetched or uploaded from the device.

310

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetDevice

Table 3-1

BACnetDevice object, important properties. (continued)

Tab Property Name


maxInfoFrames

Description
Read/Write: (Applies to MS/TP device only) Specifies highest number of information frames the device may send before it must pass the token. A value of 1 indicates it is not writable or otherwise user configurable. Read-Only: A logical revision number for the devices database. Read-Only: Determines if polling of the devices child shadow objects should occur. This property is automatically set to True whenever an enablePolling command is issued, and set to False on a disablePolling command. In the case of the latter, the objects outOfService statusFlag is set.

Valid Values
-1, 1 to ?

Default
-1

Notes
These property values can be fetched or uploaded from the device.

databaseRevision pollingEnabled

-1, 1 to ? True, False

-1 False

Engineering, cont.

useCOV

Read/Write: Specifies if the device is capable of server-side support for SubscribeCOV using either type of COV notifications. Read/Write: Specifies whether confirmed COV notifications are to be used. This property matters only if useCOV is also True. If True, all child objects set to useCOV use confirmed COV notifications. If False, unconfirmed COV notifications are used.

True, False

False

useConfirmedCOV

True, False

False

For any learned device that supports SubscribeCOV, useCOV property is automatically True. In each child object you want as COV, you need to set its useCOV property to True.

covSubscriptionCount Read-Only: Current number of COV subscriptions from device to Niagara. maxCOVSubscriptions Read/Write: Maximum number of COV subscriptions attempted by Niagara.

0 to ? 1 to ?

0 50

Confirmed COV is an option, however, it does add some additional messaging overhead.

BACnetDevice Notes

The following main subsections apply to a BACnetDevice: Supported Services and Objects Properties That Do Not Write to the Device

Note

In r2.3.5, you can define a poll delay for BACnet devices that cannot keep up with Niagara polling, either at the parent (device) or child shadow object level. Due to token-passing timing constraints, this option does not apply to BACnet MS/TP devices. For more details, see descriptions for the BACnetDevice property userData, page 3-10, and common child objects property userData, page 3-22. Need for this configuration is expected to be rare. Please note that it adds to the overall poll cycle time, but may be necessary under certain circumstances.

Supported Services and Objects


After learning (or creating and uploading) a BACnet device, you can see which BACnet services and objects it supports. Find this information on the Config tab of the BACnetDevice objects property sheet. Figure 3-7 lists all possible protocol services, and Figure 3-8 lists all possible object types.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

311

Chapter 3 BACnetDevice

BACnet Client Operation

After you determine the devices supported services, it is recommended that you set and review some important properties accordingly. See the Properties That Do Not Write to the Device section on page 3-13.
Figure 3-7 Supported BACnet services are listed in the protocolServicesSupported property.

protocolServicesSupported Click the drop-down control to expand and contract the list.

Possible Protocol Services include: ackowledgeAlarm confirmedEventNotification getEnrollmentSummary atomicReadFile addListElement createObject readProperty readPropertyMultiple writePropertyMultiple confirmedPrivateTransfer reinitializeDevice vtClose authenticate iAm unconfirmedCOVNotification unconfirmedPrivateTransfer timeSynchronization whoIs utcTimeSynchonization subscribeCOVProperty confirmedCOVNotification getAlarmSummary subscribeCOV atomicWriteFile removeListElement deleteObject readPropertyConditional writeProperty deviceCommunicationControl confirmedTextMessage vtOpen vtData requestKey iHave unconfirmedEventNotification unconfirmedText Message whoHas readRange lifeSafetyOperation getEventInformation

Notes

An especially important protocol service is subscribeCOV, which allows the Niagara station to receive updates from child objects using COV notifications from subscriptions (either unconfirmed or confirmed), rather than polling request/response messages. For each child object you wish to use COV, you must set its config property useCOV to Truenote also that some devices limit the number of COV subscriptions. For more details, Using COV in Shadow Objects, page 3-18. See the section ahead, Properties That Do Not Write to the Device, for more details on special BACnetDevice properties.

312

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetDevice

Figure 3-8

Supported BACnet objects are listed in the protocolObjectServicesSupported property.

protocolObjectServicesSupported Click the drop-down control to expand and contract the list.

Possible BACnet objects supported: analog_input analog_value binary_output calendar device file loop multi_state_output program averaging trend_log life_safety_zone analog_output binary_input binary_value command event_enrollment group multi_state_input notification_class schedule multi_state_value life_safety_point

Properties That Do Not Write to the Device


Each BACnetDevice has Niagara-only properties, specifying how Niagara reads and writes and values. These properties are found on tabs: Config and Engineering. ConfigOn the bottom of the Config tab of the property sheet for a BACnetDevice are two important properties (Figure 3-9), each with a default value of False: readPropertyMultipleSupportedWill show True if device was learned, providing that it supports the BACnet readPropertyMultiple service. writePropertyEnabledShows True if device was learned. This must set this to True before any object commands, links, or property changes will work from Niagara. If you wish to protect against Niagara writing to this device, set this property to False.

If you add a BACnetDevice manually, that is copy it from the Local Library, both of these properties will be False (by default). You need to set them according to the capabilities of the device and how Niagara should interact.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

313

Chapter 3 BACnetDevice

BACnet Client Operation

Figure 3-9

Two important BACnetDevice properties at the bottom of Config tab.

Note: The first property, readPropertyMultipleSupported, is automatically set to True if the device was learned (BACnetUtility), and the device supports this BACnet service. Also (if learned), the writePropertyEnabled property will be set to True, as a convenience. If you want read-only access from Niagara, set this to False.

Note

The property writePropertyEnabled must be True in order for any input links, object commands, or writes to properties for any of the BACnetDevice objects child objects to become effective (write to the BACnet device). In addition, the foreign BACnet device may require configuration to authorize these writes (a local matter). Editing these properties will not write or send anything to the device (query for permission to write, as one example). Put another way, if the device does not support a service (for example, the ReadPropertyMultiple service), setting this property to True will not make it support that service. To determine which of the multiple services is supported by the device, you can expand the read-only Config property protocolServicesSupported (Figure 3-7) and look at the corresponding services. EngineeringOn the bottom of the Engineering tab of the property sheet for a BACnetDevice are five properties (Figure 3-10), the last four of which are important only if the device supports the BACnet SubscribeCOV service.

pollingEnabledReflects the current polling status: enabled or disabled. (Note that COV usage requires polling enabled, but if polling is set from enabled to disabled, COV updates may continue for a bit before stopping.) useCOVDetermines whether any child object can use COV. If the device supports SubscribeCOV and was learned, this is automatically set to True. useConfirmedCOVMakes all COV usage confirmed COV. covSubscriptionCountReflects the number of child objects currently subscribed with the device to receive COV notifications. maxCOVSubscriptionsThe maximum number of COV subscriptions that the station will attempt with this BACnet device (default is 50).

314

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnet objects (children)

Figure 3-10

Important BACnetDevice properties at the bottom of Engineering tab.

Note: The useCOV property is automatically set to True if the device was learned (BACnetUtility), and the device supports this SubscribeCOV service. If SubscribeCOV is supported, it is usually best to use unconfirmed COV, (leave useConfirmedCOV property as False). You must individually set each child object to useCOV (Config tab), and because the device may limit the number of COV subscriptions, you should do this in a most important object-first order.

BACnet objects (children)


BACnet child objects shadow standard BACnet objects in networked BACnet devices. Depending on whether a device implements optional properties for its objects, you can use lite versions or full versions of shadow objects (Table 3-2).
Table 3-2 BAcnet (child) shadow object types.

Full versions:
BACnetAnalogInput and BACnetAnalogInputWritable1 BACnetAnalogOutput BACnetAnalogValue BACnetAnalogValuePriority BACnetBinaryInput and BACnetBinaryInputWritable1 BACnetBinaryOutput BACnetBinaryValue BACnetBinaryValuePriority BACnetMultistateInput and BACnetMultistateInputWritable1 BACnetMultistateOutput BACnetMultistateValue BACnetMultistateValuePriority
1.

Lite versions:
BACnetAnalogInputLite and BACnetAnalogInputWritableLite1 BACnetAnalogOutputLite BACnetAnalogValueLite BACnetAnalogValuePriorityLite BACnetBinaryInputLite and BACnetBinaryInputWritableLite1 BACnetBinaryOutputLite BACnetBinaryValueLite BACnetBinaryValuePriorityLite BACnetMultistateInputLite and BACnetMultistateInputWritableLite1 BACnetMultistateOutputLite BACnetMultistateValueLite BACnetMultistateValuePriorityLite

For an explanation of how the Writable input-type shadow objects differ from regular input-type objects, see About Writable Input Objects, page 3-3.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

315

Chapter 3 BACnet objects (children)

BACnet Client Operation

Shape Information

Inside the object shape for every BACnet shadow object is an object type abbreviation and an instance number (Figure 3-11). Additional text may also be included, namely -Lt if a Lite object, plus COV indicating COV usage. Finally, if the shadow object was created by the learn device command, the name of the object is the BACnet objects name.

Figure 3-11

BACnet shadow object shape in JDE WorkPlace shows type and instance number.
Default shapes for all types of BACnet shadow objects, as copied from the Local Library. Full objects Lite objects

Object for BACnet Analog Input object, instance number 7.

Object for BACnet Binary Output object, instance number 1, with object name AHU1Sfan.

Object for BACnet Binary Value object, instance number 3. The BV source object has the optional priority input, and so a BVP shadow object is used (input not linked in Niagara). This shadow object uses COV subscription for data updates.

Type: Shape type abbreviations are:



1.

AI is Analog Input AO is Analog Output AV is Analog Value AVP1 is Analog Value Priority BI is Binary Input BO is Binary Output BV is Binary Value BVP1 is Binary Value Priority

MSI is Multistate Input MSO is Multistate Output MSV is Multistate Value MSVP1 is Multistate Value Priority For all types, if a Lite object: -Lt follows type, for example: AI-Lt, AVP-Lt, BO-Lt, etc.

Priority value objects have an optional priority input, and are considered the same BACnet type as the corresponding value object. For example, AV and AVP objects are both Analog_Value objects.

Instance Number: The unique instance number within that device among other objects of the same type. COV: Any object with shape text ending in COV indicates it is currently subscribed for COV notificationsthe objects covSubscribed property is True. You must individually configure each object that you wish to use COV. See Using COV in Shadow Objects, page 3-18, for additional information.

316

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnet objects (children)

Inputs and Outputs

Each BACnet (child) shadow object has at least one linkable output property: statusOutput. If the object is a commandable type (AO, BO, MSO, AVP, BVP, MSVP), it also has a linkable input property, priorityArray. These properties are individually described in sections ahead on each BACnet object type. Any BACnet (child) object must reside under the appropriate BACnetDevice object (either directly, or in other containers under the BACnetDevice, such as PollOnDemand or PollAlways). A BACnet (child) object provides numerous right-click commands in the JDE Workspace (or when accessed using a Web browser through a linked Gx object). These right-click commands are included for any BACnet shadow object. Commands listed below require user security privileges of Command, Std. Commandable-type objects (for example AO and BO) include additional right-click commands, in addition to these common commands. A fetch or upload updates the polled properties (presentValue and statusFlags), in addition to working as described below.

Parent Dependencies Common Commands

Notes

fetchQueries the device and updates all on_demand_transient-type object properties for the shadow object. On the objects property sheet, this includes most properties marked with an {F} (not description and objectName). pollRenewForces an immediate poll of a shadow object in a PollOnDemand container, to update presentValue and statusFlags properties. uploadUploads on_demand_transient and foreign_persistent-type object properties and updates them in this shadow object. On the objects property sheet, this includes all properties marked with an {F}. downloadDownloads on_demand_transient and foreign_persistent-type object properties from the shadow object to the associated BACnet object. When using the JDE, the following additional right-click commands are available for any BACnet child object:

readPropertyUploads only the specified property (default is presentValue) entered in the Command Arguments dialog box. The property is updated in the objects property sheet. Requires the Niagara property name. readPropertyMultipleUploads only the properties entered in the Command Arguments dialog box (default is presentValue). Uploaded properties update in the objects property sheet. The device must support the ReadPropertyMultiple service. You must use Niagara property names, and a comma (,) delimiter between properties. For example: lowLimit,highLimit.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

317

Chapter 3 BACnet objects (children)

BACnet Client Operation

Using COV in Shadow Objects

If a device supports the BACnet SubscribeCOV service, you can select some (or perhaps all) of its child shadow objects to update using received COV notifications. COV notifications are more efficient than polling updates, especially for binary or multistate-type objects, which may infrequently change. For any analog-type object using COV notification, its value must change greater than its COV increment before any notifications are sent to the station. Any learned device that is SubscribeCOV-capable will be created with a True for useCOV, as shown on its Engineering tab (Figure 3-10 on page 3-15). If a learned device shows this as False, the following subsections do not apply. Subscribing COV Strategy Notes

Subscribing
You must individually subscribe each child shadow object you wish to use COV, by setting its useCOV property (Config tab) from False to True (Figure 3-12). This causes the station to immediately request a COV subscription. If the subscription attempt succeeds, the read-only covSubscribed property below also becomes True.
Figure 3-12 useCOV property (Config tab) for any child object is used to subscribe COV.

Note

The parent BACnetDevice must be enabled for polling (status ok) for this to work. If the COV subscription attempt does not succeed, covSubscribed remains False, the object is placed in the polling queue. Starting in Niagara r2.3.5, a progressive backoff scheme was implemented for COV re-subscriptions, as described below. If a COV-configured object attempts COV and fails, its useCOV property remains True, and it attempts again after 1 poll cycle, then 2, then 4, and so on. This allows the object eventually to get fully re-subscribed without manual intervention (albeit taking longer in cases where a network disruption lasts for a long period). Note this difference from the earlier (r2.3.4) COV subscription process, whereby any failed COV subscription attempt reset the useCOV property to False. Thus, objects needed manual intervention for them to use COV again (after fallback polling).

318

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnet objects (children)

To unsubscribe any currently COV-subscribed object, that is one showing covSubscribed as True (COV inside its shape), simply set its useCOV property (Config tab) from True to False. The station immediately requests to unsubscribe COV for that object, and the covSubscribed property goes to False.

COV Strategy Notes


Limited Subscriptions = Order of ImportanceThe number of COV subscriptions allowed can vary greatly from BACnet device to device. By default, you can attempt up to 50 COV subscriptions per device. However, sometimes a device may only allow a few COV subscriptions. Therefore, it is recommended that you configure objects for useCOV in some order of importance, by subscribing the most important objects first. If you can successfully subscribe 50 objects in a device for COV, you may wish to continue to subscribe even more. Do this by changing the maxCOVSubscriptions property of the parent BACnetDevice (Engineering tab) to a higher number. Best Candidates for COVIn general, the best usage of COV is for objects that have values that change infrequentlytypically binary and multistate input objects or binary and multistate value objects. These are represented by BACnet shadow object types BI, BV, MSI, and MSV. You can also use COV for analog input and value objects (AI and AV). However, to reduce notifications you would have to increase each objects covIncrement value, which would also reduce sensitivity to changesconsider that only changes larger than the covIncrement value will be reported. Poor Candidates for COVStarting in Niagara r2.3.4, the priorityArray property of output-type objects (AO, BO, MSO) and value-priority objects (AVP, BVP, MSVP) is polled, in addition to presentValue and statusFlags properties. This is done as part of a rewrite mechanism (see Rewrite Mechanism, page 3-25). Although you can configure any of these BACnet objects to useCOV, the object remains in the poll queue to receive priorityArrayas this property cannot be received using SubscribeCOV logic. Therefore, configuring these objects to useCOV will not significantly reduce message traffic. The poll message for each will request only one value instead of three, but this typically makes little difference. Therefore, it is recommended that you do not configure any output-type and value-priority objects for COV usage, unless the device can support plenty of COV subscriptions, and you have already subscribed all of the input and non-priority value type objects. Related BACnet Service PropertyOn the Engineering tab of the BACnet service is a property covResubscriptionInterval, in seconds. The default value is 600 seconds, and the range is from 300 to 2147483647 (MAX_VALUE). This value is global for all objects in the station configured to useCOV, and represents the frequency at which COV resubscription requests are sent to the various devices. Typically, there is no reason for you to change this property. However, you may notice that if you disable a device for polling, objects configured to useCOV will update for some period of time, but typically not longer than this period.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

319

Chapter 3 BACnet objects (children)

BACnet Client Operation

Common BACnet Shadow Object Properties


Table 3-3

Table 3-3 lists important common properties for any BACnet (child) shadow object. These properties are in addition to the standard Niagara properties common among all object types, such as executionParameters, position, and securityGroups. For a listing of properties unique to each of the different shadow object types, see sections ahead.

Common properties for all BACnet (child) shadow objects.

Tab Property Name


objectType

Description
Read Only: The BACnet shadow object type. If copied from the Local Library, the object uses this string in its name, at least until renamed. Read Only: The polled (or COV updated) state of the objects status flags, which reflect the general health of the object. Appears as a component of the objects statusOutput.

Valid Values
See Table 3-2.

Default

Notes

reflects An abbreviation for the object type object type appears inside the objects shape (near the top). {ok} The total set of 6 status flags is a superset of the BACnetStatusFlag type, where these 2 flags are added to the 4 BACnet types (originating from the device):

statusFlags

where values appear in braces { }:

inAlarm fault Depending on conditions, status flags can overridden be set in combinations. A dominant flag sets outOfService the objects color to something other than unackedAlarm gray (the same color appears at its outputs). down A normal state (no flags set) is where the status flags value is {ok}, and the objects color is gray. Outputs appear normally. Briefly, status flag values mean:

unackedAlarm down

inAlarmAn alarm state currently exists.


The objects shape and outputs are red. Another property, alarmState, is True. faultA fault state occurs when another property, reliability, has any value except no_fault_detected. The objects shape and outputs are orange. overriddenThe objects properties presentValue and reliability are no longer tracking changes. outOfServiceThe objects property outOfService has been set to True. The objects shape and outputs are cyan. unackedAlarmAn alarm has occurred that is still pending acknowledgement. If the inAlarm flag is still set, the object outputs are red and also flashing. downThe device is down or offline. The object s shape and outputs are yellow. See Description Status

description

Read-Write: Permits a user-defined text descriptor for describing the object. Any printable characters, including spaces and mixed case characters, are allowed.

320

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnet objects (children)

Table 3-3

Common properties for all BACnet (child) shadow objects. (continued)

Tab Property Name


presentValue

Description
Read Only: The polled (or COV received) value of the object, which appears as a component of the objects statusOutput.

Valid Values
output value or state

Default

Notes

For analog types, is a floating point value. For binary types, is the assigned active or
inactive text (if full object), or either false or true (if lite). For multistate types, is a text state (if a full object) or an integer value (if lite). eventState Read Only: Shows the objects current alarm state, which is one shown at right. normal fault offnormal high_limit low_limit False, True normal Offnormal applies to binary and multistate types. High_limit and low_limit states apply to analog types. Property is read-only for any of the writable input types. It is set by the input value only (see page 3-3).

Status, cont.

outOfService

Read-Write: Allows setting the object as out of service (when set to True). This allows logic testing of error conditions. While set to outOfService, you can then select a value for the reliability property.

False

reliability (not Lite objects)

Read-Write: Can be used to indicate whether the presentValue or operation of the object is reliable, and if not, why. Selections include: no_fault_detected, no_sensor, overrange, under_range, open_loop, shorted loop, no_output_value, unreliable_other, process_error

See Description

no_fault_ detected

ackedTransitions (not Lite objects)

Read Only: Flags, that when cleared, indicate that an unacknowledged event transition has occurred. Separate for event types: to-offnomal, to-fault, to-normal. Read Only and Read/Write: Object Type field is read-only, and reflects the type of BACnet object. For example: binary_output, analog_value, or multi_state_input. Instance Number is read/write (integer) and defines the object instance.

set or cleared

set

Relates to the setup of the associated NotificationClass object. Instance Number must be unique in the device for that particular object type.

objectIdentifier, Object Type Instance Number

<object type> <integer>, 1 to 4194302


(BACnet max.)

<type> -1

objectName

Config

Read-Write: The assigned object name for the BACnet object. In most BACnet devices, this name must be unique among all BACnet objects in the device.

If the shadow object was created by the BACnetUtility, any spaces in this name appear as underscores (_) in its originally assigned name. If the parent device does not support SubscribeCOV, these properties do nothing. If covSubscribed is True, the objects shape shows COV. See page 3-18 for more.

useCOV

Read-Write: Used to configure for COV subscription to receive data updates, vs. polling updates. A False-to-True transition produces the COV subscription request. Read Only: Indicates whether the object is currently successfully subscribed for COV notifications from the parent BACnetDevice.

False, True

False

covSubscribed

False, True

False

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

321

Chapter 3 BACnet objects (children)

BACnet Client Operation

Table 3-3

Common properties for all BACnet (child) shadow objects. (continued)

Tab Property Name


timeDelay

Description
Read-Write: Minimum time period in Hr:Min:Sec, that an alarm (off-normal) condition must exist before the object alarms (statusFlag inAlarm becomes set and the object and outputs turn red).

Valid Values
any practical value in Hr:Min:Sec

Default
00:00:00 (no delay)

Notes
This delay time routine also applies to an object returning to-normal from an alarm state. The timeDelay routine does not affect reporting of fault conditions.

Typically, this is some number The delay timer begins when an alarm of seconds and condition, as configured, occurs. If the alarm or minutes condition clears before the delay timer expires, the object does not alarm and the delay timer is reset. notificationClass Read-Write: The assigned notification class number, used in routing alarms. If alarms for this object are needed in Niagara, a NotificationClass object using the same number should exist in the stations NotificationService container. Configuration of this NotificationClass object determines what type of events (to-offnormal, to-fault, to-normal) require acknowledgement (ack). If an event type, such as to-normal, does not require an ack, then it is always set (checked) in this objects status property, ackedTransitions. Such an event transition will never set this objects statusFlag {unackedAlarm}. eventEnable Read-Write: Flags that define the types of event (alarm) transitions for this object that are sent to the alarm console. Selection to-offnormal applies to any alarm state, e.g. high-limit or low-limit for an AI, AO, AV object, or offnormal for a BI, BO, BV, MSI, MSO, or MSV object. notifyType Read-Write: Required for BACnet compliance. The only effective difference is that unacknowledged events for objects with notifyType of event do not appear in a server response to a BACnet GetAlarmSummary client request. selection of any or all: to-offnormal to-fault to-normal (none selected) 0 to any positive integer up to 4194302 0

Alarm Setup (not Lite objects)

NotificationClass objects reside in the NotificationServices container (under the stations services container).

event or alarm

event

Either selection functions in the same manner in the Niagara alarming subsystem.

userData

Read-Write: String-type property common Any string to most Niagara objects. Usually left blank, value for unless special servlet or API access is used. servlet/API use, or Note: In Niagara r2.301.429 and later, this pollDelay=n property lets you specify a poll delay (pause in polling) to a specific child object where n is number of ms (as here), or in the parent BACnetDevice object (delay applied to each child object). delay for the BACnet poll This is done with a poll delay value, defined in milliseconds, using this specific service before polling the entry: object. pollDelay=n For example, pollDelay=100

Poll delay feature does not apply to MS/TP devices or objects. Delay feature is useful only if target device cannot keep up with normal poll rate. Delays added this way append to the overall poll cycle time, (does not help slow polling). Delay is in addition to any imparted by services interNodeDelay.

Engineering

322

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnet objects (children)

Common BACnet Object Notes

When learning objects to shadow in a BACnet device, the BACnetUtility creates the appropriate Niagara shadow objects based upon the object types in the device. All instances of the supported object types are automatically created in the device container in stations database. The following general topics should be understood about BACnet child objects:

Device Down Inheritance Value-Type Objects, Regular and Priority Value-Type Objects, Input Usage Multistate Object Notes Writing to BACnet Objects

Device Down Inheritance


Whenever a parent BACnetDevice is marked down by the services device status/ping mechanism, all child objects (and their statusOutputs) inherit a down status (yellow color) as shown in Figure 3-13. System users have a quick visual indication whether a device is down or up.
Figure 3-13 Child objects and their outputs indicate Down while parent device is down.
BACnetDevice marked down by Device Status ping. All child objects also indicate Down.

Value-Type Objects, Regular and Priority


In a typical BACnet device (particularly one that has field I/O), input and output objects are used to interface to physical inputs and outputs, and value-type objects (Analog_Value, Binary_Value, Multistate_Value) are used to hold application values. Typical application value examples include setpoints and occupancy states. Value-type objects for these application values may be selectively implemented as either read-only (status) or writable, and (if writable) optionally commandable. In the case of Value types, note there are two separate types of Niagara shadow objects for each (a total of six types, counting full and lite versions):

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

323

Chapter 3 BACnet objects (children)

BACnet Client Operation

Regular typesBACnetAnalogValue, BACnetBinaryValue, and BACnetMultistateValue. Priority typesBACnetAnalogValuePriority, BACnetBinaryValuePriority, and BACnetMultistateValuePriority. The difference between these two types is that the priority-types are for BACnet objects that are implemented as commandable, meaning that the optional property Priority_Array exists. The regular types are for BACnet objects not implemented with this optional property. The BACnetUtility learn automatically creates the appropriate type (regular or priority) for each value-type object in the device.

You can quickly see the difference between the two shadow object types in the JDE workspace of the BACnetDevice, where priority-types have a P included in the type abbreviation inside the object shape: AVP, BVP, and MSVP.

Value-Type Objects, Input Usage


Regular non-commandable versions of the value-type shadow objects (BACnetAnalogValue, BACnetBinaryValue, BACnetMultistateValue) feature a linkable input, statusInput, designed to allow the Niagara station to supply presentValue. However, you should understand there is no way for Niagaras BACnet service to determine if the BACnet object is implemented with a read-only presentValue, in which case linking to this input is not advisable (see Note below). In Niagara r2.3.4 and later, a rewrite mechanism periodically attempts to write a linked input value. If read-only type Value objects are left linked in Niagara, performance may degrade, as resources are wasted trying to write values that can never be written. Priority versions of value-type shadow objects also feature a linkable input, priorityArray, designed to allow the Niagara station to supply presentValue using the BACnet-compatible priority level mechanism. Providing that the device allows property writes (and that you have enabled write services in the parent device object), linking to this input will provide control from Niagara station logic.

Note

Multistate Object Notes


Client support for BACnet multistate object types (Multi-state Input, Output, and Value) is provided. However, be aware that Niagara multistate objects differ from BACnet multistate objects in the implementation of presentValue. Specifically, a presentValue of 0 (zero) is valid in the Niagara object, whereas it is not valid for a BACnet object. For more details from the server-side perspective, refer to the Multistate Object Considerations section on page 4-5. From a client-side perspective, this difference means that multistate shadow objects can never have an integer value lower than 1, even for state0 (the first state). These differences are mentioned here, and also in the individual sections ahead on multistate shadow objects (BACnetMultistateInput, BACnetMultistateOutput, BACnetMultistateValue, and BACnetMultistateValuePriority).

324

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnet objects (children)

Writing to BACnet Objects


Starting in r2.3.4, changes were made in how writes to shadow objects are executed. Specifically, a rewrite delay mechanism was implemented. Related to this, all commandable objects (AO, AVP, BO, BVP, MSO, and MSVP) are now polled for their priorityArray value, in addition to presentValue and statusFlags.
Note

Be aware that all commands, input value writes, property edits from Niagara to BACnet shadow objects in a device still have two prerequisites, namely:
1. 2.

The BACnet device must be configured to allow external writes. How this is accomplished is a local matter, and will vary from device to device. The device shadow object (BACnetDevice) must be configured to allow writes. On the Config tab of its property sheet, writePropertyEnabled must be True.

Otherwise, no commands, input writes, or property edits from Niagara will succeed. Rewrite MechanismBy default, rewrite messages occur if the station detects the initial command or input value change is not accepted. Some examples: An object (AO, AVP, BO, BVP, MSO, MSVP) receives a Niagara write to an element of the priorityArray input at a particular level (1 to 16), or a command (level 1 or 8). The write may be a value or an auto. A rewrite delay timer is started, and the array values are stored away. Upon the next poll of the object, its priorityArray is compared to the stored array. If the entry in the stored array does not match the objects current priorityArray, and the rewrite delay time has expired, a write (rewrite) of the value/auto is issued again. (If the entry does match, the rewrite timer is cleared.) This underscores the need for Niagara not to contend for control with another source at a particular control levelby default, Niagara will always attempt to win. A rewrite is also issued to input-linked value objects (AV, BV, and MSV) and writable AI, BI, and MSI input objects upon each object poll, providing that a mismatch exists between the input and output, and the rewrite delay time has expired. In the case of a value (AV, BV, or MSV) object, the source object must be writable to benefit from the rewrite. If the value object is read-only, the rewrite is actually detrimental, as station resources are spent trying to do the impossible. To summarize, unlink the input of any AV, BV, or MSV object known to be read-only, or that does not respond to a Niagara input write. In the case of a writable input object, the input must have an out_of_service status, or the input is ignored. See About Writable Input Objects, page 3-3.

Note

Rewrite Delay TimeDefault rewrite delay time is 60 seconds. Adjust this globally on the property sheet for the BACnet service (General, Engineering tab). rewriteDelay: range is from 30 seconds minimum, to 2147483647 (MAX_VALUE). If you set rewriteDelay to a high value or MAX_VALUE, this essentially disables the rewrite feature. Basic operation can then be described as last command wins.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

325

Chapter 3 BACnetAnalogInput

BACnet Client Operation

BACnetAnalogInput
abbrev: AI These objects shadow Analog Input objects in BACnet devices. They are used to bring sensed values from device AIs into the control engine, format them for display, and link into other control logic. If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV). A special writable variation of this object is available for manual copy from the Local Library. Use of this object allows for Niagara override of the local presentValue with an out_of_service value at the statusInput. See About Writable Input Objects, page 3-3.
Default Resource Count: 59 (full), 41 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
(not shown): executeTrigger

Outputs
statusOutput

Input/Output Property Reference for BACnet AI Object


(only input and output types, see Table 3-1 for all properties)

Type
input1 output 1.

Label
exe sOut

Property Name
executeTrigger statusOutput

Data Species
TriggerType FloatStatusType

If a writable type copied from the Local Library, an additional input is available: sIn (statusInput), of data species FloatStatusType (see below).

Writable Type, All Used Inputs /Outputs


Inputs
statusInput (not shown): executeTrigger

Outputs
statusOutput

The BACnet AI object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.

Commands Properties

Table 3-1 BACnetAnalogInput (AI) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, Status reliability, ackedTransitions (not Lite objects) updateInterval (not Lite objects)

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.

Valid Values

Default

Notes
If a writable AI object, outOfService is read-only from the property sheet, and is controlled from the statusInput.

See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Specifies maximum time period, in hundredths of second, between updates to presentValue when the input is not overridden and not outOfService. Read-Write: Specifies the smallest recognizable change that can be reliably obtained for presentValue.

integer

resolution (not Lite objects)

valid float

0.0

326

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetAnalogInput

Table 3-1 BACnetAnalogInput (AI) object properties. (continued)

Tab Property Name


Status, cont. statusInput (input: sIn) (only writable AI)

Description
Read Only: Shows the current Niagara value and status at the statusInput. Ignored unless out_of_service.

Valid Values
<float value> {status flags}

Default
00.0 {ok}

Notes
See About Writable Input Objects, page 3-3.

objectIdentifier, objectName useCOV covSubscribed units Config

See Table 3-3 on page 3-20 for details on these common shadow object properties.

Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Text descriptor typically used to describe the physical device (sensor) connected to the analog input. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. Read-Write: Lowest number that can be reliably used for presentValue. Below this value, the object and its output have a fault status (orange color). Read-Write: Highest number that can be reliably used for presentValue. Above this value, the object and its output have a fault status (orange color). See Figure 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit.

Select any (BACnet-type unit choices) Device-support ed text string. valid float

Other, no_units -

deviceType (not Lite objects) covIncrement (not Lite objects) minPresentValue

0.0 (no minimum)

valid float

0.0

maxPresentValue

valid float

0.0

Alarm Setup (not Lite objects).

timeDelay, notificationClass highLimit

valid float

0.0

lowLimit

valid float

0.0

deadband

valid float

0.0

Deadband does not apply to fault conditions.

limitEnable

Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Figure 3-3 on page 3-20 for information on these common full object properties. Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values.

(select) low-limit, high-limit 0 to 6, (+) sign no (+) sign

(none)

eventEnable, notifyType Visual decimalFormat

2, no (+) sign

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

327

Chapter 3 BACnetAnalogInput

BACnet Client Operation

Table 3-1 BACnetAnalogInput (AI) object properties. (continued)

Tab Property Name


Engineering statusOutput (output sOut)

Description
Read Only: Shows the current value and status of the statusOutput.

Valid Values
<float value> {status flags}

Default
00.0 {ok}

Notes

BACnet AI Notes

The BACnetAnalogInput object is a real workhorse in most BACnet integrations. The statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for a BACnet Analog_Input object). If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

328

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetAnalogOutput

BACnetAnalogOutput
abbrev: AO These objects shadow Analog Output objects in BACnet devices. Access to an AO features a priorityArray input for linking to station control logic. The object also provides right-click commands to set (or auto) an output value at priority levels 1 and 8. If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on the Priority tab of the objects property sheet).
Default Resource Count: 66 (full), 49 (lite) Trigger Properties
input output

Default Object Shape


Inputs Outputs
statusOutput

All Used Inputs / Outputs


Inputs
priorityArray (not shown): executeTrigger

Outputs
statusOutput

Input/Output Property Reference for BACnet AO Object


(only input and output types, see Table 3-1 for all properties)

Type

Label
exe pIn sOut

Property Name
executeTrigger priorityArray statusOutput

Data Species
TriggerType FloatPriorityArrayType FloatStatusType

The BACnet AO object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the object provides AO control commands. By default, these commands appear as follows (note the descriptors are modifiable using the objects commandTags property): SetTo set an output value at the Manual level (8). Requires Command, Std privileges. AutoTo clear an output value set at the Manual level (8). Requires Command, Std privileges. EmergencySetTo set an output value at the Emergency level (1). Requires Command, Emer privileges. EmergencyAutoTo clear an output value set at the Emergency level (1). Requires Command, Emer privileges.

Commands

Properties
Table 3-2 BACnetAnalogOutput (AO) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not AO Lite objects)

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.

Valid Values

Default

Notes

Status

See Table 3-3 on page 3-20 for information on these common full object properties.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

329

Chapter 3 BACnetAnalogOutput

BACnet Client Operation

Table 3-2 BACnetAnalogOutput (AO) object properties. (continued)

Tab Property Name


Status, cont. resolution (not AO Lite objects)

Description
Read-Write: Specifies the smallest recognizable change that can be reliably obtained for presentValue.

Valid Values
valid float

Default
0.0

Notes

Priorities

priorityArray (input: pIn)

Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.

<valid float> or auto, levels 1 to 16 valid float

auto 1 to 16

May not reflect station generated commands (see intPriorityArray).

relinquishDefault objectIdentifier, objectName useCOV covSubscribed units

0.0

Config

Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Text descriptor typically used to describe the physical device (actuator, etc.) connected to the analog output. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. Read-Write: Lowest number that can be reliably used for presentValue. Below this value, the object and its output have a fault status (orange color). Read-Write: Highest number that can be reliably used for presentValue. Above this value, the object and its output have a fault status (orange color). See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit. Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Table 3-3 on page 3-20 for information on these common full object properties.

Select any (BACnet-type unit choices) Device-support ed text string. valid float

Other, no_units -

deviceType (not AO Lite objects) covIncrement (not AO Lite objects) minPresentValue

0.0 (no minimum)

valid float

0.0

maxPresentValue

valid float

0.0

Alarm Setup (not Lite objects).

timeDelay, notificationClass highLimit

valid float

0.0

lowLimit

valid float

0.0

deadband

valid float

0.0

Deadband does not apply to fault conditions.

limitEnable

(select) low-limit, high-limit

(none)

eventEnable, notifyType

330

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetAnalogOutput

Table 3-2 BACnetAnalogOutput (AO) object properties. (continued)

Tab Property Name


decimalFormat

Description
Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values. Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:

Valid Values
0 to 6, (+) sign no (+) sign Any desired text string, including spaces and numerals.

Default
2, no (+) sign See descrip.

Notes

commandTags Visual


intPriorityArray Engineering (input pIn)

Set (manualSet level) Auto (manualAuto level) Emergency Set (emergencySet level) Emergency Auto (emergencyAuto level)

If a tag is blank (no characters), the command is not available on the command menu.

Read Only: Shows the commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current value and status of the statusOutput.

<valid float> or auto, levels 1 to 16 <float value> {status flags}

auto 1 to 16

These station-generated commands can dynamically update.

statusOutput (output sOut)

00.0 {ok}

BACnet AO Notes

Depending on the BACnet device and the vendors implementation, BACnet Analog_Output objects may exist for either (or both) physical analog outputs and/or commandable values, such as setpoints. For example, Figure 3-14 shows a BACnetAnalogOutput object used for setpoint control in an AHU controller.
Figure 3-14 BACnet AO objects are sometimes used for setpoint control.

As with other analog-type BACnet objects, the statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for a BACnet Analog_Output object). If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

331

Chapter 3 BACnetAnalogValue

BACnet Client Operation

BACnetAnalogValue
abbrev: AV This object shadows a non-commandable Analog Value object in a BACnet device. It is one of two Niagara shadow-object types possible for a BACnet Analog Value object; the other is BACnetAnalogValuePriority. This object brings an analog control-system value into the control engine. A linkable statusInput allows the analog value to be sourced from another Niagara object (providing that the value is writable). If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV).
Default Resource Count: 53 (full), 42 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
statusInput (not shown): executeTrigger

Outputs
statusOutput

Input / Output Property Reference for BACnet AV Object


(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe sIn sOut

Property Name
executeTrigger statusInput statusOutput

Data Species
TriggerType FloatStatusType FloatStatusType

The BACnet AV object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.

Commands Properties

Table 3-3 BACnetAnalogValue (AV) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not AV Lite objects) statusInput

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.

Valid Values

Default

Notes

Status

See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the float value and status currently at the statusInput. If linked, and this property is writable in the device (and write support is set for the device), changes are written to presentValue.

valid float {status flags}

Note: Do not link statusInput if the Analog Value object is read-only.

See Value-Type Objects, Input Usage on page 3-24, and Rewrite Mechanism, page 3-25.

332

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetAnalogValue

Table 3-3 BACnetAnalogValue (AV) object properties. (continued)

Tab Property Name


objectIdentifier, objectName useCOV covSubscribed Config units

Description
See Table 3-3 on page 3-20 for details on these common shadow object properties.

Valid Values

Default

Notes

Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit. Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values. Read Only: Shows the current value and status of the statusOutput.

Select any (BACnet-type unit choices) valid float

Other, no_units 0.0 (no minimum)

covIncrement (not AV Lite objects) timeDelay, notificationClass highLimit Alarm Setup (not Lite objects).

valid float

0.0

lowLimit

valid float

0.0

deadband

valid float

0.0

Deadband does not apply to fault conditions.

limitEnable

(select) low-limit, high-limit 0 to 6, (+) sign no (+) sign <float value> {status flags}

(none)

eventEnable, notifyType Visual decimalFormat

2, no (+) sign 00.0 {ok}

Engineering

statusOutput (output sOut)

BACnet AV Notes

BACnetAnalogValue objects are often used for read-only status values, therefore, note that links to the statusInput property will have no positive affect on these particular objects. In fact, linking to an input of a read-only object will waste extra station resources due to the overhead of the rewrite mechanism As with other analog-type BACnet shadow objects, the statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for a BACnet Analog_Value object). If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

333

Chapter 3 BACnetAnalogValuePriority

BACnet Client Operation

BACnetAnalogValuePriority
abbrev: AVP This objects shadows a commandable Analog Value object in a BACnet device, meaning an AV object with priorityArray and relinquishDefault properties. This object is like the BACnetAnalogValue object, but has a priorityArray input instead of a statusInput, and also provides right-click control commands (like an AO object). If the object is a full type, the value can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on the Priority tab of the objects property sheet).
Default Resource Count: 60 (full), 49 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
priorityArray (not shown): executeTrigger

Outputs
statusOutput

Input/Output Property Reference for BACnet AVP Object


(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe pIn sOut

Property Name
executeTrigger priorityArray statusOutput

Data Species
TriggerType FloatPriorityArrayType FloatStatusType

The BACnet AV object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the AV priority object provides control commands. By default, these commands appear as follows (note the descriptors are modifiable using the objects commandTags property): SetTo set an output value at the Manual level (8). Requires Command, Std user privileges. AutoTo clear an output value set at the Manual level (8). Requires Command, Std user privileges. EmergencySetTo set an output value at the Emergency level (1). Requires Command, Emer user privileges. EmergencyAutoTo clear an output value set at the Emergency level (1). Requires Command, Emer user privileges.

Commands

Properties
Table 3-4 BACnetAnalogValuePriority (AVP) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, Status

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.

Valid Values

Default

Notes

334

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetAnalogValuePriority

Table 3-4 BACnetAnalogValuePriority (AVP) object properties. (continued)

Tab Property Name


Status, cont. reliability, ackedTransitions (not Lite objects)

Description
See Table 3-3 on page 3-20 for information on these common full object properties.

Valid Values

Default

Notes

priorityArray Priorities

Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.

<valid float> or auto, levels 1 to 16 valid float

auto 1 to 16

relinquishDefault objectIdentifier, objectName useCOV covSubscribed

0.0

Config

units

Read-Write: Selection of engineering units for display purposes. Choose from a logical grouping, then a specific unit. Read-Write: Minimum required change in presentValue to cause a COVNotification to be issued to subscriber COV-clients. See Figure 3-3 on page 3-20 for information on these common full object properties. Read-Write: Value above which the object is evaluated in high-limit alarm. Above this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Value below which the object is considered in low-limit alarm. Below this value (if not in fault), the object and output have inAlarm status (red color). Read-Write: Differential value applied to high and low limits before return-to-normal. Deadband is subtracted from highLimit and added to lowLimit. Read-Write: Flags that enable low-limit and high-limit alarms, as needed. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Sets decimal position from 0 to 6 places, and optionally force (+) sign for positive values. Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:

Select any (BACnet-type unit choices) valid float

Other, no_units 0.0 (no minimum)

covIncrement (not AV Lite objects) timeDelay, notificationClass highLimit Alarm Setup (not Lite objects)

valid float

0.0

lowLimit

valid float

0.0

deadband

valid float

0.0

Deadband does not apply to fault conditions.

limitEnable

(select) low-limit, high-limit 0 to 6, (+) sign no (+) sign Any desired text string, including spaces and numerals.

(none)

eventEnable, notifyType decimalFormat

2, no (+) sign See descrip. If a tag is blank (no characters), the command is not available on the command menu.

commandTags Visual

Set (manualSet level) Auto (manualAuto level) Emergency Set (emergencySet level) Emergency Auto (emergencyAuto level)

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

335

Chapter 3 BACnetAnalogValuePriority

BACnet Client Operation

Table 3-4 BACnetAnalogValuePriority (AVP) object properties. (continued)

Tab Property Name


Engineering intPriorityArray (input pIn)

Description
Read Only: Shows the commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current value and status of the statusOutput.

Valid Values
<valid float> or auto, levels 1 to 16 <float value> {status flags}

Default
auto 1 to 16

Notes
See Value-Type Objects, Input Usage on page 3-24.

statusOutput (output sOut)

00.0 {ok}

BACnet AV (Priority) Notes

Depending on the BACnet device and the vendors implementation, commandable BACnet Analog_Value objects may exist for setpoints and other application parameters. For example, Figure 3-14 shows a BACnetAnalogValuePriority object used for setpoint control in an AHU controller.
Figure 3-15 Commandable BACnet AV objects are sometimes used for setpoint control.

As with other analog-type BACnet shadow objects, the statusOutput value is typically pre-formatted with the correct engineering units (the Units property is a required property for any BACnet Analog_Value object). If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

336

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetBinaryInput

BACnetBinaryInput
abbrev: BI These objects shadow Binary Input objects in BACnet devices. They are used to bring sensed values from device BIs into the control engine, format them for display, and link into other control logic. If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV). A special writable variation of this object is available for manual copy from the Local Library. Use of this object allows for Niagara override of the local presentValue with an out_of_service value at the statusInput. See About Writable Input Objects, page 3-3.
Default Resource Count: 62 (full), 40 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
(not shown): executeTrigger

Outputs
statusOutput

Input / Output Property Reference for BACnet BI Object


(only input and output types, see Table 3-1 for all properties) Type input1 output 1. Label exe sOut Property Name executeTrigger statusOutput Data Species TriggerType FloatStatusType

If a writable type copied from the Local Library, an additional input is available: sIn (statusInput), of data species BooleanStatusType (see below).

Writable Type, All Used Inputs /Outputs


Inputs
statusInput (not shown): executeTrigger

Outputs
statusOutput

The BACnet BI object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.

Commands Properties

Table 3-5 BACnetBinaryInput (BI) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime (not Lite objects)

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BI object, presentValue is displayed in terms of inactiveActiveText. If a Lite BI, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state).

Valid Values

Default

Notes
If a writable BI object, outOfService is read-only from the property sheet, and is controlled from the statusInput.

Status

timestamp or null (none)

null

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

337

Chapter 3 BACnetBinaryInput

BACnet Client Operation

Table 3-5 BACnetBinaryInput (BI) object properties. (continued)

Tab Property Name


changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) Status, cont. elapsedActiveTime (not Lite objects) timeOfActiveReset (not Lite objects) statusInput (input: sIn) (only writable BI) objectIdentifier, objectName useCOV covSubscribed Config deviceType (not Lite objects) polarity

Description
Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the current Niagara value and status at the statusInput. Ignored unless out_of_service. See Table 3-3 on page 3-20 for details on these common shadow object properties.

Valid Values
integer value

Default
0

Notes

timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) valid timestamp or null (none) false or true, {status flags}

null 00:00:00

null

false {ok}

See About Writable Input Objects, page 3-3.

Read-Write: Text descriptor typically used to describe the physical device (sensor, equipment) connected to the binary input.

Device-support ed text string. normal

Read-Write: Determines if the physical state normal, reverse at the device input is reflected at the presentValue (normal), or if presentValue remains opposite from the input (reverse). See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state that is evaluated as an alarm. See Table 3-3 on page 3-20 for information on these common full object properties. True, False

Alarm Setup (not Lite objects)

timeDelay, notificationClass alarmValue eventEnable, notifyType

Active

Visual

activeInactiveText (not Lite objects) statusOutput (output sOut)

Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the current boolean state and status of the statusOutput. If a full-type BI object, statusOutput is displayed in terms of inactiveActiveText.

Active, Inactive false {ok}

If a Lite object, states are always false or true.

Engineering

Inactive or Active, {status flags}

BACnet BI Notes

The BACnetBinaryInput is another frequently-used object in typical BACnet integrations. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

338

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetBinaryOutput

BACnetBinaryOutput
abbrev: BO This object shadows a Binary Output object in a BACnet device. Access to the BO features a priorityArray input for linking to station control logic. The object also provides right-click commands to set (or auto) an output state at priority levels 1 and 8. If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on the Priority tab of the objects property sheet). A separate presentValue output is also available. Default Resource Count Trigger Properties 70 (full), 46 (lite)
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
priorityArray (not shown): executeTrigger

Outputs
presentValue statusOutput

Input / Output Property Reference for BACnet BO Object


(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe pIn present sOut

Property Name
executeTrigger priorityArray presentValue statusOutput

Data Species
TriggerType FloatPriorityArrayType Float FloatStatusType

The BACnet BO object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the BACnet BO object provides control commands. By default, these commands appear as follows (note these descriptors are modifiable using the objects commandTags property):

Commands

ActiveTo set an active output at the Manual level (8). Requires Command, Std user privileges. InactiveTo set an inactive value at the Manual level (8). Requires Command, Std user privileges. AutoTo clear any active or inactive output at the Manual level (8). EmergencyActiveTo set an active output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyInactiveTo set an inactive output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyAutoTo clear any active or inactive output at the Emergency level (1). Requires Command, Emer user privileges.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

339

Chapter 3 BACnetBinaryOutput

BACnet Client Operation

Properties
Table 3-6 BACnetBinaryOutput (BO) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime (not Lite objects) Status changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) elapsedActiveTime (not Lite objects) timeOfActiveReset (not Lite objects) feedbackValue (not Lite objects) priorityArray Priorities

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BO object, presentValue is displayed in terms of inactiveActiveText. If a Lite BO, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state). Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the status of a feedback value, from which presentValue must differ before an event is generated. Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.

Valid Values

Default

Notes

timestamp or null (none) integer value

null 0

timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) valid timestamp or null (none) False, True

null 0:00:00

null

False

<valid float> or auto, levels 1 to 16 valid float

auto 1 to 16

relinquishDefault objectIdentifier, objectName useCOV covSubscribed deviceType

0.0

Config

(not Lite objects) minimumOnTime (not Lite objects)

Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. Read Only: Minimum number of seconds that presentValue remains at the active state after a write to present Value causes that property to assume the active state. An active at the Minimum On Off priority level (6) occurs for this time.

Device-support ed text string. integer value 0

340

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetBinaryOutput

Table 3-6 BACnetBinaryOutput (BO) object properties. (continued)

Tab Property Name


minimumOffTime (not Lite objects) Config, cont.

Description
Read Only: Minimum number of seconds that presentValue remains at the inactive state after a write to present Value causes that property to assume the inactive state. An inactive at the Minimum On Off priority level (6) occurs for this time.

Valid Values
integer value

Default
0

Notes

polarity

Read-Write: Determines if the physical state normal, reverse at the device output is reflected by the presentValue (normal), or if presentValue remains opposite from the input (reverse). See Table 3-3 on page 3-20 for information on these common full object properties.

normal

Alarm Setup

timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) commandTags

Read-Write: Defines the labels used to list commands that appear on the right-click command menu. Default text values for commandTags are:


activeInactiveText (not Lite objects) intPriorityArray

Active (active at level 8) Inactive (inactive at level 8) Auto (auto at level 8) EmergencyActive (active at level 1) EmergencyInactive (inactive at level 1) EmergencyAuto (auto at level 1)

Any desired text string, including spaces and numerals.

See descrip.

If a tag is blank (no characters), the command is not available on the command menu.

Visual

Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the boolean commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current boolean state and status of the statusOutput.

Active, Inactive auto 1 to 16

If a Lite object, states are always false or true. These station-generated commands can dynamically update.

Engineering

(input pIn)

false, true, or auto, levels 1 to 16 false or true, {status flags}

statusOutput (output sOut)

false {ok}

BACnet BO Notes

Depending on the BACnet device and the vendors implementation, BACnet Binary_Output objects may exist for either (or both) physical digital outputs and/or commandable states, such as occupancy control. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

341

Chapter 3 BACnetBinaryValue

BACnet Client Operation

BACnetBinaryValue
abbrev: BV This object shadows a non-commandable Binary Value object in a BACnet device. It is one of two Niagara shadow-object types possible for a BACnet Binary Value object; the other is BACnetBinaryValuePriority. This object brings a boolean control-system parameter into the stations control engine. A linkable statusInput allows the boolean value to be sourced from another Niagara object (providing that the value is writable). If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV).
Default Resource Count: 59 (full), 40 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
statusInput (not shown): executeTrigger

Outputs
statusOutput

Input / Output Property Reference for BACnet BV Object


(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe sIn sOut

Property Name
executeTrigger statusInput statusOutput

Data Species
TriggerType FloatStatusType FloatStatusType

The BACnet BV object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.

Commands Properties

Table 3-7 BACnetBinaryValue (BV) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime (not Lite objects)

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BV object, presentValue is displayed in terms of inactiveActiveText. If a Lite BV, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state).

Valid Values

Default

Notes

Status

timestamp or null (none)

null

342

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetBinaryValue

Table 3-7 BACnetBinaryValue (BV) object properties. (continued)

Tab Property Name


changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) elapsedActiveTime (not Lite objects) Status, cont. timeOfActiveReset (not Lite objects) statusInput

Description
Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the boolean value and status currently at the statusInput. If linked, and this property is writable in the device (and write support is set for the device), changes are written to presentValue.

Valid Values
integer value

Default
0

Notes

timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) timestamp or null (none) false, true: {status flags}

null 0:00:00

null

false: {ok}

Note: Do not link statusInput if the Binary Value object is read-only.


objectIdentifier, objectName useCOV covSubscribed timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) alarmValue (not Lite objects) Visual activeInactiveText (not Lite objects) statusOutput (output sOut) Read Only: Defines the presentValue state that is evaluated as an alarm. Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the current boolean state and status of the statusOutput. True, False True Active, Inactive false {ok} Config See Table 3-3 on page 3-20 for details on these common shadow object properties.

See Value-Type Objects, Input Usage on page 3-24, and Rewrite Mechanism, page 3-25.

Alarm Setup

See Table 3-3 on page 3-20 for information on these common full object properties.

If a Lite object, states are always false or true.

Engineering

false or true, {status flags}

BACnet BV Notes

BACnetBinaryValue objects are often used for read-only status states, therefore, note that links to the statusInput property will have no positive affect on these particular objects. In fact, linking to an input of a read-only object will waste extra station resources due to the overhead of the rewrite mechanism. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

343

Chapter 3 BACnetBinaryValuePriority

BACnet Client Operation

BACnetBinaryValuePriority
abbrev: BVP This object shadows a commandable Binary Value object in a BACnet devices, meaning a BV object with priorityArray and relinquishDefault properties. This object is like the BACnetBinaryValue object, but has a priorityArray input instead of a statusInput, and also provides right-click control commands (like a BO object). If the object is a full type, the statusOutput reflects inactive and active text descriptors (vs. only false or true if a Lite type). Full types can also monitor for off-normal conditions and generate alarms, plus provide properties for tracking change-of-state (COS) statistics and elapsed active time (runtime). The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on Priority tab of the objects property sheet). A separate presentValue output is also available.
Default Resource Count: 67 (full), 45 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
priorityArray (not shown): executeTrigger

Outputs
presentValue statusOutput

Input / Output Property Reference for BACnet BVP Object


(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe pIn present sOut

Property Name
executeTrigger priorityArray presentValue statusOutput

Data Species
TriggerType BooleanPriorityArrayType Boolean BooleanStatusType

This object has an input trigger-type property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the BACnet BV Priority object provides control commands. By default, these commands appear as follows (note that descriptors are modifiable using the objects commandTags property):

Commands

ActiveTo set an active output at the Manual level (8). Requires Command, Std user privileges. InactiveTo set an inactive value at the Manual level (8). Requires Command, Std user privileges. AutoTo clear any active or inactive output at the Manual level (8). EmergencyActiveTo set an active output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyInactiveTo set an inactive output at the Emergency level (1). Requires Command, Emer user privileges. EmergencyAutoTo clear any active or inactive output at the Emergency level (1). Requires Command, Emer user privileges.

344

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetBinaryValuePriority

Properties
Table 3-8 BACnetBinaryValuePriority (BVP) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, reliability, ackedTransitions (not Lite objects) changeOfStateTime Status (not Lite objects) changeOfStateCount (not Lite objects) timeOfStateCountReset (not Lite objects) elapsedActiveTime (not Lite objects) timeOfActiveReset (not Lite objects) priorityArray Priorities

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. If a full-type BVP object, presentValue is displayed in terms of inactiveActiveText. If a Lite BVP, presentValue is false or true. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows a date/timestamp for the last COS (change of state). Read Only: Shows the total number of changes of state that have occurred since the last COS count reset (clear). Read Only: Shows a date/timestamp for when the COS count was last cleared. Read Only: Shows the accumulated runtime (elapsed active time) formatted in Hr:Min:Sec. Read Only: Shows a date/timestamp for when the accumulated runtime (elapsed active time) was last cleared. Read Only: Shows the values and priorities in the objects 16-level priorityArray (in the device). A fetch provides current values. Read Only: Defines the output value when all 16 priority level slots have an auto. See Table 3-3 on page 3-20 for details on these common shadow object properties.

Valid Values

Default

Notes

timestamp or null (none) integer value

null 0

timestamp or null (none) Time period up to 9999:99:99 (Hr:Min:Sec) valid timestamp or null (none) <valid float> or auto, levels 1 to 16 valid float

null 0:00:00

null

auto 1 to 16 0.0

relinquishDefault objectIdentifier, objectName useCOV covSubscribed deviceType (not Lite objects) minimumOnTime (not Lite objects)

Config

Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. Read Only: Minimum number of seconds that presentValue remains at the active state after a write to present Value causes that property to assume the active state. An active at the Minimum On Off priority level (6) occurs for this time. Read Only: Minimum number of seconds that presentValue remains at the inactive state after a write to present Value causes that property to assume the inactive state. An inactive at the Minimum On Off priority level (6) occurs for this time.

Device-support ed text string. integer value

minimumOffTime (not Lite objects)

integer value

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

345

Chapter 3 BACnetBinaryValuePriority

BACnet Client Operation

Table 3-8 BACnetBinaryValuePriority (BVP) object properties. (continued)

Tab Property Name


polarity

Description

Valid Values

Default
normal

Notes

Read-Write: Determines if the physical state normal, reverse at the device output is reflected by the presentValue (normal), or if presentValue remains opposite from the input (reverse). See Table 3-3 on page 3-20 for information on these common full object properties.

Alarm Setup

timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) alarmValue (not Lite objects) commandTags

Read Only: Defines the presentValue state that is evaluated as an alarm. Read-Write: Defines the labels used to list commands that appear on the right-click command menu. Default text values for commandTags are:

True, False Any desired text string, including spaces and numerals.

True See descrip. If a tag is blank (no characters), the command is not available on the command menu.


activeInactiveText (not Lite objects) intPriorityArray (input pIn)

Active (active at level 8) Inactive (inactive at level 8) Auto (auto at level 8) EmergencyActive (active at level 1) EmergencyInactive (inactive at level 1) EmergencyAuto (auto at level 1)

Visual

Read-Write: Defines how states and presentValue display at the statusOutput, also on the objects property sheet. Read Only: Shows the Niagara (station) boolean commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current boolean state and status of the statusOutput.

Active, Inactive auto 1 to 16

If a Lite object, states are always false or true. See Value-Type Objects, Input Usage on page 3-24.

Engineering

false, true, or auto, levels 1 to 16 false or true, {status flags}

statusOutput (output sOut)

false {ok}

BACnet BV (Priority) Notes

Depending on the BACnet device and the vendors implementation, commandable BACnet Binary_Value objects may exist for application control modes and related parameters. If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information.

346

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetMultistateInput

BACnetMultistateInput
abbrev: MSI This object shadows a Multi-state Input object in a BACnet device. It is used to bring a sensed state (integer value) from a device MSI into the control engine, where it can be linked into other control logic. If the object is a full type, the state value is formatted using descriptive state text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV). A special writable variation of this object is available for manual copy from the Local Library. Use of this object allows for Niagara override of the local presentValue with an out_of_service value at the statusInput. See About Writable Input Objects, page 3-3.
Default Resource Count: 62 (full), 40 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
(not shown): executeTrigger

Outputs
statusOutput

Input / Output Property Reference for BACnet MSI Object


(only input and output types, see Table 3-1 for all properties)

Type
input1 output 1.

Label
exe sOut

Property Name
executeTrigger statusOutput

Data Species
TriggerType IntegerStatusType

If a writable type copied from the Local Library, an additional input is available: sIn (statusInput), of data species IntegerStatusType (see below).

Writable Type, All Used Inputs /Outputs


Inputs
statusInput (not shown): executeTrigger

Outputs
statusOutput

The BACnet MSI object has an input property, executeTrigger, (typically not used). Niagara multistate objects differ from BACnet multistate objects in the implementation of presentValue. Specifically, a presentValue (and stateText entry) of 0 (zero) is valid in a Niagara MSI, whereas 0 is not valid in a BACnet MSI object. See the the Common Commands section on page 3-17.

Note

Commands Properties

Table 3-9 BACnetMultistateInput (MSI) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService,

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects. presentValue reflects the current state by integer value (if lite object) or its assigned stateText descriptor.

Valid Values

Default

Notes
If a writable MSI object, outOfService is read-only from the property sheet, and is controlled from the statusInput.

Niagara Release 2.3.5 BACnet Integration Reference

Status

Published: April 26, 2004

347

Chapter 3 BACnetMultistateInput

BACnet Client Operation

Table 3-9 BACnetMultistateInput (MSI) object properties. (continued)

Tab Property Name


numberOfStates

Description
Read Only: Shows the number of states defined in the objects stateText property. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the current Niagara value and status at the statusInput. Ignored unless out_of_service. The default value is Error, which occurs with a 0 value or any other inappropriate value.

Valid Values
1 to ?

Default

Notes

Status, cont.

reliability, ackedTransitions (not Lite objects) statusInput (input: sIn) (only writable MSI)

<state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)

Error {ok}

See About Writable Input Objects, page 3-3.

Config

objectIdentifier, objectName useCOV covSubscribed deviceType (not Lite objects)

See Table 3-3 on page 3-20 for details on these common shadow object properties.

Read-Write: Text descriptor that can describe the physical device (sensor, etc.) connected to the multistate input. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state(s) that are evaluated as an alarm. Read Only: Defines the presentValue state(s) that are evaluated as a fault. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines all possible discrete states by value-name pairs. Each state has two fields:

Device-support ed text string. state0 through 7 state0 through 7 If the source object has more than 8 states, only the first 8 are accessible.

Alarm Setup (not Lite obj.)

timeDelay, notificationClass alarmValues faultValues eventEnable, notifyType stateText (not Lite objects)

valueUnique integer. Values are


contiguous and typically start at 1. (Only the first 8 stateText are visible as alarmValues or faultValues). tagText that describe the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. statusOutput (output sOut) Read Only: Shows the current state and status present at the statusOutput. Visual

Unique integers, with associated text descriptor. Up to ? states can be learned.

State descriptors (tags) are seen in linked MultistateLog object samples and also can display at a linked GxText object.

Engineering

Lite objects have integer-only values to


represent the different states.

<state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)

Full objects use the stateText descriptors


to represent the different states.

348

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetMultistateInput

BACnet MSI Notes

Full versions include read-only access to the native text descriptors used in the shadowed MSI object (providing it is implemented with the optional State_Text property). This allows for more understandable display of values in the station, as opposed to integer values. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information. If the source BACnet MSI object has more than 8 states, only the first 8 are available for review in Niagara as alarmValues and faultValues. Note also that BACnet Multistate Input objects, unlike their Niagara equivalents, do not offer runtime (elapsed active time) and change-of-state (COS) count capabilities.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

349

Chapter 3 BACnetMultistateOutput

BACnet Client Operation

BACnetMultistateOutput
abbrev: MSO This object shadows a Multi-state Output object in a BACnet device, a commandable integer-based object. Access to the MSO features a priorityArray input for linking to station control logic. The object also provides right-click commands to set (or auto) an output state at priority levels 1 and 8. If the object is a full type, the state value is formatted using descriptive text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on Priority tab of the objects property sheet).
Default Resource Count: 70 (full), 46 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
priorityArray (not shown): executeTrigger

Outputs
statusOutput

Input / Output Property Reference for BACnet MSO Object


(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe pIn sOut

Property Name
executeTrigger priorityArray statusOutput

Data Species
TriggerType IntegerPriorityArrayType IntegerStatusType

The BACnet MSO object has an input property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the object provides MSO control commands. By default, these commands appear as follows (note these descriptors are modifiable using the objects commandTags property): SetTo set an output state at the Manual level (8). Drop Requires Command, Std privileges. AutoTo clear an output state set at the Manual level (8). Requires Command, Std privileges. EmergencySetTo set an output state at the Emergency level (1). Requires Command, Emer privileges. EmergencyAutoTo clear an output state set at the Emergency level (1). Requires Command, Emer privileges.

Commands

Note

If full objects, both the Set and Emergency Set command menus provide a drop-down list of states (described in text) for selection. If lite objects, command menus provide only a field in which an integer value can be entered.

350

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetMultistateOutput

Properties
Table 3-10 BACnetMultistateOutput (MSO) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, Status numberOfStates reliability, ackedTransitions (not Lite objects) feedbackValue (not Lite objects) priorityArray Priorities

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.

Valid Values

Default

Notes
presentValue reflects the current state by integer value (if lite object) or its assigned stateText descriptor.

Read Only: Shows the number of states defined in the objects stateText property. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the status of a feedback value, from which presentValue must differ before an event is generated. Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto.

1 to ?

a valid state

<valid state or integer> or auto, levels 1 to 16 <valid integer>

auto 1 to 16

relinquishDefault

The default value (0) is not a valid value, but does indicate an upload is necessary.

Config

objectIdentifier, objectName useCOV covSubscribed deviceType (not Lite objects)

See Table 3-3 on page 3-20 for details on these common shadow object properties.

Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. See Table 3-3 on page 3-20 for information on these common full object properties.

Device-support ed text string.

Alarm Setup

timeDelay, notificationClass, eventEnable, notifyType (not Lite objects) commandTags

Visual

Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:

Set (manualSet level) Auto (manualAuto level) Emergency Set (emergencySet level) Emergency Auto (emergencyAuto level)

Any desired text string, including spaces and numerals.

See descrip.

If a tag is blank (no characters), the command is not available on the command menu.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

351

Chapter 3 BACnetMultistateOutput

BACnet Client Operation

Table 3-10 BACnetMultistateOutput (MSO) object properties. (continued)

Tab Property Name


stateText (not Lite objects) Visual, cont.

Description
Read-Only: Defines all possible discrete states by value-name pairs. Each state has two fields:

Valid Values
Unique integers, with associated text descriptor. Up to ? states learned.

Default

Notes
State descriptors (tags) are used in linked MultistateLog object collections and also can display at a linked GxText object.

valueUnique integer. Values are


contiguous and typically start at 1. tagText that describe the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. intPriorityArray (input pIn) Read Only: Shows the Niagara (station) commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current state and status present at the statusOutput.

<integer or text state>, or auto, levels 1 to 16 <state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)

auto 1 to 16

Station-generated commands only. Dynamically update.

Engineering

statusOutput (output sOut)

Lite objects have integer-only values to


represent the different states.

Full objects use the stateText descriptors


to represent the different states.

BACnet MSO Notes

Depending on the BACnet device and the vendors implementation, BACnet Multi-state_Output objects may exist for either (or both) physical discrete outputs and/or commandable states. Full versions include read-only access to the native text descriptors used in the shadowed MSO object (providing it is implemented with the optional State_Text property). This allows for more understandable display of values in the station, as opposed to integer values. If the device (and object) supports alarming, BACnet alarms can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information. Note also that BACnet Multistate Output objects, unlike their Niagara equivalents, do not offer runtime (elapsed active time) and change-of-state (COS) count capabilities.

352

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetMultistateValue

BACnetMultistateValue
abbrev: MSV This object shadows a non-commandable Multi-state Value object in a BACnet device, an integer-based object. It is one of two Niagara shadow-object types possible for a BACnet Multi-state Value object; the other is BACnetMultistateValuePriority. This object brings a multistate (integer) control-system parameter into the stations control engine. A linkable statusInput allows the state to be sourced from another Niagara object (providing that its value is writable). If the object is a full type, the state value is formatted using descriptive text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput. If supported by the parent device, updates may alternately occur by COV notifications (if set to useCOV).
Default Resource Count: 59 (full), 40 (lite) Trigger Properties
Inputs

Default Object Shape


Outputs
statusOutput

All Used Inputs / Outputs


Inputs
statusInput (not shown): executeTrigger

Outputs
statusOutput

3
Input/Output Property Reference for BACnet MV Object
(only input and output types, see Table 3-1 for all properties)

Type
input output

Label
exe sIn sOut

Property Name
executeTrigger statusInput statusOutput

Data Species
TriggerType IntegerStatusType IntegerStatusType

The BACnet MSV object has an input property, executeTrigger, (typically not used). See the the Common Commands section on page 3-17.

Commands Properties
Table 3-4

BACnetMultistateValue (MSV) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, numberOfStates

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.

Valid Values

Default

Notes
presentValue reflects the current state by integer value (if lite object) or its assigned stateText descriptor. If more than 8 states, alarm and fault values show only for first 8.

Status

Read Only: Shows the number of states defined in the objects stateText property.

1 to ?

reliability, ackedTransitions (not Lite objects)

See Table 3-3 on page 3-20 for information on these common full object properties.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

353

Chapter 3 BACnetMultistateValue

BACnet Client Operation

Table 3-4

BACnetMultistateValue (MSV) object properties. (continued)

Tab Property Name


statusInput Status, cont.

Description
Read Only: Shows the multistate value and status currently at the statusInput. If linked, and this property is writable in the device (and write support is set for the device), changes are written to presentValue.

Valid Values
<state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)

Default
false: {ok}

Notes
See Value-Type Objects, Input Usage on page 3-24, and Rewrite Mechanism, page 3-25.

Note: Do not link statusInput if the Multistate Value object is read-only.


objectIdentifier, objectName useCOV covSubscribed timeDelay, notificationClass alarmValues faultValues eventEnable, notifyType See Table 3-3 on page 3-20 for details on these common shadow object properties.

Alarm Setup (not Lite objects)

Config

See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state(s) that are evaluated as an alarm. Read Only: Defines the presentValue state(s) that are evaluated as a fault. See Table 3-3 on page 3-20 for information on these common full object properties.

state0 through 7 state0 through 7

If the source object has more than 8 states, only the first 8 are displayed.

stateText (not Lite objects) Visual

Read-Only: Defines all possible discrete states by value-name pairs. Each state has two fields:

valueUnique integer. Values are


contiguous, and typically start at 1. tagText that describe the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. statusOutput (output sOut) Read Only: Shows the current state and status present at the statusOutput.

Unique integers, with associated text descriptor. Up to ? states learned.

State descriptors (tags) are used in linked MultistateLog object collections and also can display at a linked GxText object.

Engineering

Lite objects have integer-only values to


represent the different states.

<state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)

Full objects use the stateText descriptors


to represent the different states.

BACnet MSV Notes

BACnet Multi-state_Value objects are sometimes used for read-only status states, therefore, note that links to the statusInput property will have no positive affect on these particular objects. In fact, linking to an input of a read-only object will waste extra station resources due to the overhead of the rewrite mechanism. Note that full versions include read-only access to native text descriptors used in the shadowed MSV object. Alarming support is also available for full MSV objects. If the source BACnet MSV object has more than 8 states, only the first 8 are available for review in Niagara as alarmValues and faultValues.

Note

354

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetMultistateValuePriority

BACnetMultistateValuePriority
abbrev: MSVP This object shadows a commandable Multi-state Value object in a BACnet device, meaning an MSV object with priorityArray and relinquishDefault properties. This object is similar to the integer-based BACnetMultistateValue object, but has a priorityArray input instead of a statusInput, and also provides right-click control commands (like an MSO object). If the object is a full type, the state value is formatted using descriptive text, and can be monitored for an off-normal condition and generate an alarm. The BACnet service polls for the objects presentValue and statusFlags, which appear at the statusOutput, as well as its local priorityArray values (visible on Priority tab of the objects property sheet).
Default Resource Count: 67 (full), 45 (lite) Trigger Properties
input output

Default Object Shape


Inputs Outputs
statusOutput

All Used Inputs / Outputs


Inputs
priorityArray (not shown): executeTrigger

Outputs
statusOutput

Input / Output Property Reference for AI Object


(only input and output types, see Table 3-1 for all properties)

Type

Label
exe pIn sOut

Property Name
executeTrigger priorityArray statusOutput

Data Species
TriggerType IntegerPriorityArrayType IntegerStatusType

This object has an input trigger-type property, executeTrigger, (typically not used). In addition to the common commands (see page 3-17), the object provides MSV control commands. By default, these commands appear as follows (note these descriptors are modifiable using the objects commandTags property): SetTo set an output state at the Manual level (8). Drop Requires Command, Std privileges. AutoTo clear an output state set at the Manual level (8). Requires Command, Std privileges. EmergencySetTo set an output state at the Emergency level (1). Requires Command, Emer privileges. EmergencyAutoTo clear an output state set at the Emergency level (1). Requires Command, Emer privileges.

Commands

Note

If full objects, both the Set and Emergency Set command menus provide a drop-down list of states (described in text) for selection. If lite objects, command menus provide only a field in which an integer value can be entered.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

355

Chapter 3 BACnetMultistateValuePriority

BACnet Client Operation

Properties
Table 3-11 BACnetMultistateValuePriority (MSVP) object properties.

Tab Property Name


objectType, statusFlags, description, presentValue, eventState, outOfService, Status numberOfStates feedbackValue (not Lite objects) reliability, ackedTransitions (not Lite objects) priorityArray Priorities

Description
See Table 3-3 on page 3-20 for information on these properties common to all BACnet (child) shadow objects.

Valid Values

Default

Notes

Read Only: Shows the number of states defined in the objects stateText property. Read Only: Shows the status of a feedback value, from which presentValue must differ before an event is generated. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Shows the values and priorities active at the objects 16-level priorityArray. Continuously polled, providing the parent BACnetDevice is enabled for polling. Read Only: Defines the output value when all 16 priority level slots have an auto.

1 to ? <valid state or integer>

<valid state or integer> or auto, levels 1 to 16 <valid integer>

auto 1 to 16

relinquishDefault

The default value (0) is not a valid value, but does indicate an upload is necessary.

Config

objectIdentifier, objectName useCOV covSubscribed deviceType (not Lite objects)

See Table 3-3 on page 3-20 for details on these common shadow object properties.

Read-Write: Text descriptor used to describe the physical device (equipment) connected to the binary output. See Table 3-3 on page 3-20 for information on these common full object properties. Read Only: Defines the presentValue state that is evaluated as an alarm. Read Only: Defines the presentValue state(s) that are evaluated as a fault. See Table 3-3 on page 3-20 for information on these common full object properties. Read-Write: Defines the command labels that show on the right-click command menu for the object. Default tags are:

Device-support ed text string.

Alarm Setup (not Lite objects)

timeDelay, notificationClass, alarmValues faultValues eventEnable, notifyType commandTags

state0 through 7 state0 through 7

If the source object has more than 8 states, only the first 8 are displayed.

Visual

Set (manualSet level) Auto (manualAuto level) Emergency Set (emergencySet level) Emergency Auto (emergencyAuto level)

Any desired text string, including spaces and numerals.

See descrip.

If a tag is blank (no characters), the command is not available on the command menu.

356

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 3

BACnet Client Operation BACnetMultistateValuePriority

Table 3-11 BACnetMultistateValuePriority (MSVP) object properties. (continued)

Tab Property Name


stateText (not Lite objects) Visual, cont.

Description
Read-Only: Defines all possible discrete states by value-name pairs. Each state has two fields:

Valid Values
Unique integers, with associated text descriptor. Up to ? states learned.

Default

Notes
State descriptors (tags) are used in linked MultistateLog object collections and also can display at a linked GxText object.

valueUnique integer. Values are


contiguous and typically start at 1. tagText that describes the associated discrete state. State descriptors are used at the statusOutput, presentValue, alarm and fault values. intPriorityArray (input pIn) Read Only: Shows the Niagara (station) commands present on each of 16 priority level slots for the priorityArray (pIn) input. Read Only: Shows the current state and status present at the statusOutput.

<integer or text state>, or auto, levels 1 to 16 <state text> : {status flags} (if full version) or <integer> : {status flags} (if lite version)

auto 1 to 16

Engineering

See Value-Type Objects, Input Usage on page 3-24.

statusOutput (output sOut)

Error : {ok}

Lite objects have integer-only values to


represent the different states.

Full objects use the stateText descriptors


to represent the different states.

BACnet MSV (Priority) Notes

Depending on the BACnet device and the vendors implementation, commandable BACnet Multi-state_Value objects may exist for application control modes and related parameters. Full versions include read-only access to the native text descriptors used in the shadowed MSO object (providing it is implemented with the optional State_Text property). This allows for more understandable display of values in the station, as opposed to integer values. If the device (and object) supports alarming, BACnet alarms from the object can be received in the Niagara alarm subsystem. Refer to the Receiving BACnet Alarms section on page 5-7 for more information. If the source (commandable) BACnet MSV object has more than 8 states, only the first 8 are available for review in Niagara as alarmValues and faultValues.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

357

Chapter 3

BACnet Client Operation BACnetMultistateValuePriority

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

358

CHAPTER

BACnet Server Operation


Due to its BACnet heritage, a Niagara station requires minimal configuration for BACnet server operation. The few main topics below explain the related topics. Device Object Exporting Objects Allowing BACnet Write Access Using BACnet Log Objects

Device Object
The Device object that represents the Niagara station has various properties, some of which are populated by BACnetService properties. The Device object has a BACnet Object_Name property derived from the Stations name, with its Device object instance number appended to the end. For example, a Station named EastWing3 running the BACnetService that is configured with a deviceID, Instance Number of 101 will have an object name of: EastWing3_101 Table 4-1 shows how selected properties of the stations Device object are sourced.
Table 4-1 Device object for Station, selected properties and Niagara source.

BACnet property
Object_Identifier Object_Name Object_Type Vendor_Name Vendor_Identifier Model_Name

Niagara source
BACnetService, Config tab Station name and Device ID (fixed)

Niagara property/entry/(Notes)
deviceID, Instance Number <StationName>_<Instance Number> Device typically, is Tridium typically, is 36

typically, from license.properties file typically is value of line productSummary=<value> (plus) of Niagara host - powered by Niagara Framework (example: JACE-NX - powered by Niagara Framework) if productSummary line is absent, then Niagara Station.

Firmware_Revision

version of coreruntime module in Niagara host

(example, 2.301.508.v1)

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

41

Chapter 4 Exporting Objects

BACnet Server Operation

Table 4-1

Device object for Station, selected properties and Niagara source. (continued)

BACnet property

Niagara source

Niagara property/entry/(Notes)
(example, 2.305.508.v1)

Application_Software_Revision typically, is bacnet module version in host Location Description Segmentation_Supported Local_Time Local_Date APDU_Segment_Timeout APDU_Timeout Number_of_APDU_Retries Max_Master Max_Info_Frames BACnetService, Config tab

license.properties file of Niagara Default is value of line customerSite=<value> host (Each value can be overridden, see Adjunct Configuration: Default is value of line customerName=<value> bacnet.properties File, page 6-28 BACnetService, Config tab Station time Station data segmentationSupported apduSegmentTimeout apduTimeout numberOfApduRetries BACnetService, maxMaster BACnetMSTP tab, Config sub-tab maxInfoFrames

Note that other Device object properties not shown in Table 4-1 (where applicable), are sourced from the BACnetService, but have no visibility in Niagara.

Exporting Objects
The station acts as a BACnet server when exposing (exporting) Niagara objects as BACnet objects. By default, read-only access is given to all remote BACnet clients. Write-access is optionalsee Allowing BACnet Write Access, page 4-6. You can expose any of the following standard Niagara objects as BACnet objects, regardless of where they are in the station database:

AnalogInput (AI) AnalogOutput (AO) BinaryInput (BI) BinaryOutput (BO)


1.

MultistateInput 1 (MSI) MultistateOutput 1 (MSO) Calendar Schedule

All Ndio types (JACE-4 only), see Ndio Considerations, page 4-6.
StateText limitations apply. See Multistate Object Considerations, page 4-5.

In addition, you can expose Niagara logs as BACnet Trend_Log objects, but only by using the following special versions of Niagara log objects. You must copy and paste these log objects from the Local Library into your station database.

BACnet log objects have the following types:


BACnetAnalogLog BACnetBinaryLog BACnetIntegerLog

BACnetMultistateLog BACnetStringLog

42

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 4

BACnet Server Operation Exporting Objects

See the later section Using BACnet Log Objects, page 4-8, for more details. The following main topics apply when exporting Niagara objects to BACnet: Setting Object Properties Object Name Conventions

It is recommended that you read through both sections before exposing objects.

Setting Object Properties


For any Niagara object to be exported as BACnet, you must assign it an object instance number (foreignAddress property). Details are explained in these sections: Setting the foreignAddress BACnet Export Rules and Considerations

Note

Any Niagara object exported as BACnet incudes its entire station swid in its object name. This enforces (externally) the BACnet requirement for unique names for all objects in a device. The config property foreignAddress exists for most standard types of standard Niagara objects. However, foreignAddress currently applies only to object types previously listed under Exporting Objects, page 4-2. In combination with the objects type, foreignAddress specifies the objects BACnet object identifier within the Niagara station.
Figure 4-1 foreignAddress is a Config property that defines BACnet instance number.

Setting the foreignAddress

Note

The BACnet service has a similar property: deviceID, Instance Number, for the externally visible Device object that represents the running Niagara station. Refer to page 1-11 for more details.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

43

Chapter 4 Exporting Objects

BACnet Server Operation

Per the BACnet specification, each object in a device must have an identifier that is the unique combination of its object type and instance number, for example: Analog_Input: 2 Binary_Output: 11

The default foreignAddress for any Niagara object is -1 (not a BACnet object). To expose a Niagara object as BACnet, you must assign it a foreignAddress number.

BACnet Export Rules and Considerations

Before you export Niagara objects to BACnet, it is recommended that you read and understand the following rules and considerations: Instance Number Rules Multistate Object Considerations Ndio Considerations

Instance Number Rules


The following rules apply when you wish to expose an object as BACnet. A valid foreignAddress property value for a Niagara object is an integer from 0 to 4194302 (BACnet maximum for configured instance number). A BACnet device cannot contain two objects with the same object identifier, meaning type and instance number. This means that when exporting Niagara objects in a Niagara station, you must be careful to assign unique numbers to foreignAddress properties among any specific BACnet object type. It is permissible, for example, to have as many as 8 objects that each have a foreignAddress of 3 (when each object is a different type). However, you can only have one Calendar object with a foreignAddress of 3, one AnalogInput object with a foreignAddress of 3, and so on.

Note

The JDE does not automatically enforce this rule when editing properties. Therefore, you must keep track of foreignAddress values within object types.

If you try to export an object with a duplicate indentifier (or try to export a Niagara object with no BACnet equivalent), you see no indication of a problem from the property sheet. However, a specific WARNING is logged in the stations ErrorLogService, and also appears in the stations Standard Output.

Niagara multistate objects and Ndio objects (JACE-4 only) have special export considerationssee immediately following sections.

Note

When you duplicate or copy-and-paste Niagara objects that have been exported (assigned a specific foreignAddress), notice that the new objects do not have duplicate instance numbers. Instead, they automatically have a foreignAddress = -1, meaning not a BACnet object. If you wish to export them, you must assign foreignAddress appropriately.

44

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 4

BACnet Server Operation Exporting Objects

Multistate Object Considerations


Before exposing a Niagara MultistateInput (MSI) or MultistateOutput (MSO) object as a BACnet object, be aware that you must first edit its stateText property to be compliant with the BACnet definition. This is a Visual tab property (Figure 4-2). Specifically, a zero (0) value is not allowed, plus all values must be contiguous.
Figure 4-2 Niagara MSI or MSO object must have stateText with contiguous values, and with no zero (0).

Default stateText values for a Niagara MSI and MSO object include the non-compliant 0 value.

This MSI object has had its stateText property edited to remove the 0 value. Other values were modified and added as needed, using the StateText Guidelines (below).

By default, Niagara stateText settings include a 0 value for the Off (first) state. However, the BACnet protocol reserves a presentValue of 0 as an index into the array of possible states defined by stateText. Therefore, you cannot expose a Niagara MSI or MSO without first editing stateText using the guidelines below.

StateText Guidelines
If you follow these guidelines when assigning stateText values, you can then expose a Niagara MSI or MSO object as BACnet.
1.

Assign numerical states starting at 1 (not 0, as in a standard Niagara multistate). For a two-speed object, for example, this means 1 = Off, 2 = On, and 3 = Fast, versus the numerical 0, 1, and 2 assignments used in stateText defaults. Assign state numbers contiguously (without skipping a number), with a maximum of 8 discrete states for an MSI (1 to n, where n < 9). MSO objects may have more states, but they must be contiguous. Limitations on number of MSI states are from Niagara, while the contiguous restriction is from BACnet. If you assigned a foreignAddress value to expose an MSI or MSO object, but did so before stateText is in BACnet compliance, you will need to reassign the foreignAddress value (first to -1 and then back to the desired value). If you assign a foreignAddress value to an MSI or MSO object that has a non-compliant stateText configuration, this is recorded in the stations ErrorLogService.

2.

Notes

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

45

Chapter 4 Allowing BACnet Write Access

BACnet Server Operation

Ndio Considerations
When exposing Ndio objects (JACE-4 station), be aware that following object types count as standard Niagara objects: Ndio0to10VInput, NdioHighSpeedCounterInput, NdioResistiveInput, and NdioThermistorType3Input each count as a standard AnalogInput object. Ndio0to10VOutput and Ndio0to20MAOutput objects each count as a standard AnalogOutput object. (Ndio0to20MAOutput is for future use). NdioBinaryInput objects count as a standard BinaryInput. NdioBinaryOutput objects count as a standard BinaryOutput.

Refer to ndio (bacxNdio), page D-2 of Appendix D, Niagara bacnetx Modules, for more information.

Object Name Conventions


Typically, a BACnet device requires a unique name for each contained object. Due to the hierarchical architecture of a Niagara station, however, it is quite possible for a JACE to contain many objects with the same name (where each object resides in a different container). For example, there may be many objects named SpaceTemp, each with a unique swid, because each object has a unique parent container. When exposing Niagara objects as BACnet objects, Niagara accounts for this. Each exposed object uses the complete Niagara station swid as its BACnet object name. For example, an exposed BinaryOutput object from station demoR2 is named:
demoR2_Sim_LogicScreens_AirHandler_supplyFan

As needed, the station sends an I-Have message to respond to Who-Has service requests from other networked BACnet devices. Note that the stations I-Have service responds to a name-based request only if the objects swid is given. This is because multiple BACnet objects with the same name can exist in a station. The swid syntax for a Who-Has (by name) in stations running older builds is:
/<stationName>/<containerPaths>/<objectName>

for example,
/NewJ5b/AirHandlers/AHU1/Logic/SupplyFan

Allowing BACnet Write Access


To allow other BACnet devices (BACnet workstations included) to write values in exposed Niagara objects, you must define a special BACnet user for the station.
Procedure 4-1 Configuring a BACnet user.

Step 1

In the Tree View of JDE, right-click on the station and select Go > UserAdmin.

46

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 4

BACnet Server Operation Allowing BACnet Write Access

Step 2

From the UserAdmin menu, select New User. A New User dialog appears.
Figure 4-3 Adding a BACnet user to allow write access from other BACnet devices.

Step 3

Enter a user name of BACnet, any desired password, and click OK. While a password is technically not necessary, you should assign one because you must give write privileges to the BACnet user.

Note

Step 4

Double-click on the BACnet user in the Workspace to bring up the User Preferences dialog box. Click the Security tab. Assign write access, as needed, to appropriate security group(s) at the desired levels (Admin, Operator, Command). Figure 4-4 shows full access for the General group.
Figure 4-4 Assign write privileges as needed by security group and levels.

Step 5

Notes

If needed, you can assign BACnet-exposed objects to certain security groups and then define the appropriate access to those groups to the user BACnet. Generally, Admin-level write-access is required to modify most Niagara object properties, including configurations of Calendar and Schedule objects. Command access applies to commandable-type objects, such as AnalogOutput (AO) and BinaryOutput (BO) objects.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

47

Chapter 4 Using BACnet Log Objects

BACnet Server Operation

Using BACnet Log Objects


Starting in Niagara r2.3.4, the Niagara BACnet module contains special versions of log objects that you copy and paste from the Local Library. Use them in place of standard Niagara logs whenever you need to export a log as a BACnet Trend Log1. The following subsections apply to Niagara BACnet log objects: BACnet Log Overview Adding BACnet Logs BACnet Log Shapes BACnet Log Shapes

BACnet Log Overview


Each BACnet log object works exactly like the equivalent standard Niagara log object in all respects but oneconfig properties that define valid collection periods. Niagara logs have config properties daysOfWeek and timeRange. BACnet logs have (instead) config properties startTime and endTime, per the BACnet specification. See Collection Time Differences for more details.

Other features of the BACnet log objects are identical to standard Niagara logs, including archive functions, LogChart and LogTable views, commands, inputs, outputs, and config properties (except the two properties noted above). BACnet log objects also appear in the stations log index and log selector like standard logs.
Note

Refer to the Niagara Standard Programming Reference for detailed information about the equivalent standard Niagara log objects, which include:

AnalogLog Binary Log Integer Log

MultistateLog StringLog

Adding BACnet Logs


You add BACnet log object by copying and pasting from the Local Library.
Procedure 4-2 Copying BACnet logs into a station database.

Step 1 Step 2 Step 3

Open the station to receive a BACnet log, and navigate to the target container. Open the Local Library. Working in Tree View, expand the folder tridiumx, then the bacnet JAR.

1. BACnet Trend Log type 135-2001, not 135b-2001 (no concept of sequence number).

48

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 4

BACnet Server Operation Using BACnet Log Objects

Step 4

Under bacnet, expand services, then the sub-folder server. This reveals the 5 different BACnet log objects available. Right-click any object and select Copy, and then Paste it in the station in the desired container (Figure 4-5).
Figure 4-5 Copy BACnet logs from the tridiumx/bacnet/services/server folder.

Step 5

Local Library Right-click to paste copied BACnet log.

Right-click objects to copy

Step 6

Rename any copied log with an appropriate name, and configure standard log properties as needed for archiving, display, and so forth. When ready to export a copied log to BACnet, assign it a foreignAddress property number that is unique among all other BACnet log objects in the station.
Note

Step 7

All Niagara BACnet log objects are exported as a BACnet Trend_Log object.

Step 8

Continue to copy and paste BACnet logs as needed, either from logs previously copied/configured, or from the Local Library. Assign unique foreignAddress values.

BACnet Log Shapes


In BACnet log objects, the assigned foreignAddress value appears within its object shape, similar to what appears for BACnet client (shadow) objects. This is unique among BACnet-exported Niagara objects, and is useful when viewing a workspace to see assigned instance numbers (foreignAddress) for exposed Trend_Logs.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

49

Chapter 4 Using BACnet Log Objects

BACnet Server Operation

Figure 4-6
Default BACnet log objects copied from Local Library

Instance number (foreignAddress) appears within BACnet log objects shapes.

Trend Log instance number

Mouse over BACnet log object to see Niagara object type.

Note that the different Niagara type of BACnet log object (Analog, Binary, etc.) is not shown within its shapehowever, when you mouse over the object, its object type appears in the windows lower status line (Figure 4-6, right).

Collection Time Differences


By default, any BACnet log object copied from the Local Library will have all wildcards (*) for all fields in the properties startTime and endTime (Figure 4-7). The log will start collecting as soon as you connect the statusInput to a source data output. This is similar to how a standard Niagara log works, whereby by default, all days of week are selected, and the time range is from 12:00 AM to 12:00 AM.
Figure 4-7 Config properties startTime and endTime apply to each BACnet log object.

However, this similarity ends with a BACnet log if you need a daily timer to enable log collection. If any field in startTime or endTime contains a wildcard (*), this essentially disables that entire property (per the BACnet spec for a Trend_Log). For example, if you want to log daily only between the period of 8:00 AM and 5:00 PM, the startTime and endTimes values as shown in Figure 4-8 will not work. Instead, logging will continue all 24 hours, as startTime and endTime are ignored.

410

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 4

BACnet Server Operation Using BACnet Log Objects

Figure 4-8

Both startTime and endTime here are ignored, as each contains a wildcard (*).

Invalid entries due to the wildcard (*) fields.

In this case, you could link a Schedule to the log objects logEnable input, and define the desired log periods in the configuration of the Schedule object (Figure 4-9).
Figure 4-9 BACnet logs input logEnable is used (link to Schedule object).
logEnable input controlled by Schedule object.

Schedule objects weekly schedule will enable log collection.

Using Log Start and End Times

If you have an application to either start and/or stop log collection at a specific date and time, you can configure the startTime and endTime properties appropriately. For example, a BACnet log configured as shown in Figure 4-10 will collect only during February, 2003both startTime and endTime properties have no wildcards.
Figure 4-10 Both startTime and endTime here are observed, as there are no wildcards (*).

Either of these properties is observed only if wildcard (*) free.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

411

Chapter 4 Using BACnet Log Objects

BACnet Server Operation

412

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

CHAPTER

Configuring BACnet Alarming


A Niagara station supports BACnet intrinsic event reporting, more commonly called alarming. Support is available for both client and server operations, meaning the station can both receive (and reroute) BACnet alarms from shadowed objects, and also send BACnet alarms from objects exposed as BACnet. The following sections explain configuration required for BACnet alarming: Generating BACnet Alarms Receiving BACnet Alarms

Generating BACnet Alarms


Niagara alarms are exported to BACnet using a special notification recipient object, BACnetRecipient (Figure 5-1). The BACnetRecipient stores an address of a remote BACnet device to which alarms shall be sent.
Figure 5-1 BACnetRecipient object routes a Niagara alarm as a BACnet alarm.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

51

Chapter 5 Generating BACnet Alarms

Configuring BACnet Alarming

When a Niagara alarm occurs and is routed to a BACnetRecipient, the recipient creates a BACnet Event Notification Request and sends it to the configured device. The alarm is also routed in the standard manner to the station, Alarm Console, and Vykon Alarm Service (VAS) client. The alarm can be acknowledged normally using the Alarm Console/VAS client, or the remote BACnet device can issue a BACnet Acknowledge Alarm request to acknowledge the alarm. Upon receiving a valid BACnet ack request from the remote device, the station routes the ack throughout the Niagara system and removes the corresponding alarm from the Event.UnackedAlarms table of the Supervisor. Sections ahead explain the following Niagara BACnet alarm-generation topics: Requirements and Restrictions Configuring for BACnet Alarm Generation BACnetRecipient Object BACnetRecipient Notes

Requirements and Restrictions


These requirements and restrictions apply to Niagara BACnet alarm generation:

Only Niagara objects that are exposed as BACnet objects can generate BACnet alarms. This means only alarms from Niagara AIs, AOs, BIs, BOs, MSIs, and MSOs can be routed to BACnet devices (Calendar and Schedule objects are not alarmable). This draws from the BACnet requirement that every alarm message must contain the BACnet object ID of its source. Only local objects in a station can generate BACnet alarms. Therefore, a supervisor station cannot generate a BACnet alarm on behalf of an object in a subordinate station. If a subordinate station needs to generate a BACnet alarm, it must be configured with the BACnet service and the appropriate recipient(s). A separate BACnetRecipient must be created for each remote device to which BACnet alarms must be routed (one-to-one BACnetRecipient to device). Alarms are not regenerated. If a BACnet device is down when the Niagara system sends an alarm, the alarm is not saved for retransmission later. The Niagara system, of course, still maintains a record of the alarm in its buffer. The Niagara system does not support setting up a third-party BACnet system to receive BACnet alarms, configure its notification classes, and so forth. All alarm configuration and setup must be done using the systems native tools.

52

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 5

Configuring BACnet Alarming Generating BACnet Alarms

Configuring for BACnet Alarm Generation


Using the JDE, follow these steps to configure a station running the BACnet service to generate BACnet alarms.
Procedure 5-1 Configuring for BACnet alarm generation.

Step 1

Create (if not already created), BACnetDevice objects in the station. Typically, you use the BACnetUtility and its learnNetwork command. Note the device objects specific BACnet address (instance number) as shown in their respective shapes. In the NotificationService container, create a NotificationClass object to handle BACnet alarms. A dedicated NotificationClass is not necessary, but it helps you ensure that only objects exposed as BACnet use this notification class. In the JDE Tree View, open the Local Library and expand its tridiumx folder. Expand the bacnet JAR to the tridiumx/bacnet/notification level, and copy a BACnetRecipient (Figure 5-2).
Figure 5-2 BACnetRecipient objects are copied from the Local Library.
Local Library

Step 2

Step 3

tridiumx/bacnet/notification folder (right-click and select Copy).

Step 4

Paste the BACnetRecipient in the NotifcationService container, and link it to the NotificationClass created above.
Note

Paste and link an additional BACnetRecipient, as needed, for each remote BACnet device that needs to receive Niagara alarms.

Step 5

Edit the BACnetRecipient objects Config property, recipientDeviceId, to hold the Device object ID of the BACnet device to receive the alarms. The property field is Instance Number, which is -1 by default. Change this to the unique Device object ID (instance number) of the target BACnet device.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

53

Chapter 5 Generating BACnet Alarms

Configuring BACnet Alarming

Step 6

If needed, edit other Config properties of the BACnetRecipient object. See the BACnetRecipient Properties, page 5-5 for more details. For any Niagara AI, AO, BI, or BO object that is exposed as a BACnet object (foreignAddress property configured), assign the notification class (created above) used to handle BACnet alarms. The station is now configured to generate BACnet alarms for the specified objects. See the next section, Testing BACnet Alarm Generation, to verify proper operation.

Step 7

Testing BACnet Alarm Generation

In order to test Niagara BACnet alarm generation, you should have access to third-party BACnet tools for the remote devices. In addition, the Niagara system should be configured for standard Niagara alarming (Alarm Console receives alarms).
Procedure 5-2 Testing BACnet alarm generation from the JACE.

Step 1

Force into an alarm condition one of the standard AI, AO, BI, BO, MSI, or MSO objects that is exposed to BACnet (and assigned to the BACnet notification class). For example, with an analog object type, you can do this by setting the appropriate eventEnable properties and then modifying the alarm high or low limit. The alarm is routed via the notification class created in the previous Step 2, and passed onto the BACnetRecipient. The BACnetRecipient translates the alarm from the Niagara format to a BACnet format, and sends it to the BACnet device specified in the previous Step 5. At the same time, the alarm is also routed to its NotificationService archive location (local or supervisor) using the standard Niagara alarm mechanism.

Step 2

Using the third-party tool to access the remote BACnet device, verify the device receives the alarm. Open a Niagara alarm console and verify the alarm was received by Niagara. Using the third-party BACnet tool, issue an acknowledgement for the alarm. Verify an acknowledgment is received by the Niagara station. The alarm acknowledgement will be saved in the event history table. The alarm should also be removed form the list on unacknowledged alarms in the Alarm Console.

Step 3 Step 4 Step 5

54

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 5

Configuring BACnet Alarming Generating BACnet Alarms

BACnetRecipient
abbrev: none (BACnetRecipient) This object receives a Niagara alarm routed to a Niagara notification class, reformats it as a BACnet alarm, and sends it to a particular BACnet device. The object has a single linkable input property, notificationInput, for linking to NotificationClass object(s). The target BACnet device is identified in a Config property: recipientDeviceId. A separate BACnetRecipient object is needed for each remote BACnet device required to receive station-generated alarms.
Default Resource Count: 21 Dependencies
Inputs

Default Object Shape


Outputs
(none)

All Used Inputs / Outputs


Inputs
notificationInput

Outputs
(none)

Input / Output Property Reference for BACnetRecipient


(only input and output types, see Table 5-1 for all properties)

Type
input: output:

Label
notifica: (none):

Property Name
notificationInput: :

Data Species
NotificationTriggerType: :

Like other notification-type objects, a BACnetRecipient object must reside under the stations NotificationService container object. Important properties for a BACnetRecipient object are on its property sheets Config tab. Values reflect a BACnet Notification Class objects Recipient_List property. Description Valid Values Default
(all)

Properties
Table 5-1

BACnetRecipient object, important (Config) properties.

Tab Property Name


validDays

Notes
Default is for all days of the week. Separate recipient objects may specify the same BACnet device, but have different time ranges and other properties. See BACnetRecipient Notes for example.

Read-Write: Defines days of valid operation, Sun, Mon, Tue, by days of week. Any combination of days Wed, Thu, Fri, can be selected. Sat Read-Write: Defines time of valid operation, which applies to any of the defined valid days of week. The exclusive option, when checked, means the valid time range is any time outside the time range specified. 12:00 AM/PM to 12:00AM/PM, exclusive

timeRange

12:00 AM to 12:00 AM (constant)

Config

recipientDeviceId

Read-Write: Defines the target BACnet device to receive the alarm, by the instance number of its Device object. Read-Write: The handle of a process within the recipient device that is to receive the event notification. Read-Write: Defines whether notifications are to be sent using confirmed services (True) or unconfirmed services (False).

valid device instance number integer

-1 The single most (no device) important property. 0 Use of this property is a local matter in the remote device. If False (default), the station does not expect a response from the target device. Cleared transition types are not sent.

processId

issueConfirmedNotifications

False, True

False

validTransitions

Read-Write: Defines which event transition-types are valid for transmission.

to-offnormal, to-fault, to-normal

(all)

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

55

Chapter 5 Generating BACnet Alarms

Configuring BACnet Alarming

BACnetRecipient Notes
Depending on how a remote BACnet device processes received alarms, you may wish to configure BACnetRecipient properties apart from just recipientDeviceId. For example, if a device is configured to route incoming alarms received during weekdays to Process ID 1, and during weekends to Process ID 2, then in the station, two BACnetRecipient objects could target the same BACnet device (Figure 5-3).
Figure 5-3 Example of two BACnetRecipient objects with the same target BACnet device.

validDays = Mon, Tue, Wed, Thu, Fri deviceRecipientId = 14 processId = 1

validDays = Sat, Sun deviceRecipientId = 14 processId = 2

In the above example, both BACnetRecipient objects target BACnet device 14, however, they differ by values in properties validDays and processId. The validTransitions property is typically set to match the ackRequired property setting in the linked NotificationClass object. Depending on the capability of the target BACnet device, the property issueConfirmedNotifications may be left at default (False) or set to True.

Notes

If False, the alarm message is sent once, without any subsequent confirmation required from the target BACnet device. If True, a confirmation message from the target device is expected for each alarm issued (note this does not mean operator acknowledgement). If message confirmation is not received in the apduTimeout period, the alarm message is resent, up to the number of times specified in numberOfApduRetries (both are properties of the BACnet service). In general, by setting ackRequired in the linked NotificationClass object and issueConfirmedNotifications to True in the BACnetRecipient, the most secure communications between devices is provided.

56

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 5

Configuring BACnet Alarming Receiving BACnet Alarms

Receiving BACnet Alarms


The BACnet service can accept incoming alarms from remote BACnet devices, convert them to the Niagara alarm format, and route them through the Niagara system. In this way, BACnet alarms can be sent to printer recipients, e-mail recipients, and so forth. BACnet alarms will also appear in the Niagara Alarm Console (Figure 5-4) or Vykon Alarm Service (VAS) client. A console or VAS client user can acknowledge the BACnet alarms just like native Niagara alarms.
Figure 5-4 BACnet alarm received in the Niagara Alarm Console.

A Niagara BACnet alarm record has two additional fields from a native alarm: extEventData and proxySwid.

The extEventData field shows the received value of the BACnet-formatted BACnetTimeStamp. Depending on the capability of the device generating the alarm, this may be a date-time or a simple sequence number.

Note: eventCount remains at 0 for a BACnet alarm. (This feature is proprietary to Niagara).

The proxySwid field shows the BACnetService, used to route alarm acknowledgements back to the generating BACnet device. A proxySwid field can appear in an alarm record for another integration object that does not directly alarm, for example, a LON device. However, in this example, the proxySwid names the BACnetService, because this is a BACnet alarm.

Sections ahead explain the following topics on receiving BACnet alarms: Requirements and Restrictions Configuring for BACnet Alarm Reception Testing BACnet Alarm Reception Using the GetAlarmSummary

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

57

Chapter 5 Receiving BACnet Alarms

Configuring BACnet Alarming

Requirements and Restrictions


The following requirements and restrictions apply to BACnet alarms received by a Niagara station: A BACnet alarm must be generated by a BACnet device / object combination that is represented by valid shadow objects in the Niagara station. Otherwise, the alarm is discarded. The station must have the corresponding NotificationClass object in its NotificationService container (must be the same notification class number used by the alarming object in the remote BACnet device. In the property sheet of the alarmable shadow object, this is its notificationClass property.) Any BACnet alarms sent to a non-operative station are lost. The Niagara system does not query remote BACnet devices to retrieve lists of unacknowledged alarms. However, a JDE user can use the BACnetUtility command, getAlarmSummary, to retrieve a list of unacknowledged alarms from any specific BACnet device (providing it was previously learned). The Niagara alarming subsystem requires each alarm to be uniquely identified by a timestamp containing both time and date. Each BACnet alarm contains a BACnetTimeStamp field, which corresponds to the events to-<state> time. The value of this field can be a time, date-time, or simply a sequence number. For a BACnet alarm received with a date-time BACnetTimeStamp value, the date-time value is converted directly to a Niagara timestamp. Any BACnet alarm received with a time or sequence number is assigned a Niagara-type timestamp equal to its arrival time. The original BACnetTimeStamp value is stored in text format in the extEventData field of the Niagara alarm record.

Configuring for BACnet Alarm Reception


To configure BACnet alarm reception in a Niagara station, you need access to third-party configuration tools for the remote BACnet devices.
Procedure 5-3 Configuring for BACnet alarm reception.

Step 1

Using the JDE, create (if not already created), BACnetDevice objects and child objects in the station. Typically, you use the BACnetUtility and its learnNetwork and learnDevice commands. Refer to Chapter 2, Using the BACnet Utility for details. Using third-party tools for the remote BACnet devices, configure them to generate alarms for shadowed objects, and route them to the Niagara station. Note the notification class numbers used by the objects that will alarm (each Niagara shadow object will show its assigned notificationClass number). Using the JDE, create the necessary NotificationClass objects in the stations NotificationService container, based upon notification numbers obtained in Step 2.

Step 2

Step 3

58

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 5

Configuring BACnet Alarming Receiving BACnet Alarms

Testing BACnet Alarm Reception


Step 1

In order to test Niagara BACnet alarm generation, you should have access to third-party BACnet tools for the remote devices. In addition, the Niagara system should be configured for normal Niagara alarming (Alarm Console receives alarms).
Procedure 5-4 Testing BACnet alarm reception by the JACE.

Force into an alarm condition one of the remote BACnet objects (as configured in Step 2 of the previous procedure). Using the JDE and the Alarm Console, verify the alarm is received by the Niagara station. The alarm will be routed using a notification class created in Step 3 of the previous procedure. Using the Niagara Alarm Console, acknowledge the alarm. A BACnet AlarmAcknowledgement message is issued to the remote device. Upon receipt of the acknowledgement message, the BACnet device will generate an ack notification message to indicate the alarm was successfully acknowledged. This message is sent to the Niagara station. The ack notification will be routed using the same notification class as the alarm. The alarm is then removed from the Alarm Consoles list of unacknowledged alarms.

Step 2

Step 3

Using the GetAlarmSummary


Related to BACnet alarm reception is the BACnet GetAlarmSummary service, provided as a device command in the stations BACnetUtility. For more information on this service, refer to the getAlarmSummary section on page 2-13.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

59

Chapter 5 Receiving BACnet Alarms

Configuring BACnet Alarming

510

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

CHAPTER

Configuring BACnetService Properties


The property sheet for the Niagara BACnet service contain parameters that affect the polling of BACnet shadow objects, the device status (device/ping) mechanism, link-layer-specific engineering properties, plus a variety of other parameters. Included is a router table listing known BACnet routers. The property sheet is also where you selectively toggle debug services (if needed), as well as issue commands to the service. The following main topics are explained ahead:

BACnetService Property Sheet Overview General Properties Status (current object counts and limit) Config (includes router table) Engineering (includes time synch master setup) Configuring BACnet Polling Configuring Device Status/Ping Configuring BACnet/IP Properties Config (to define BBMD role) Engineering (BBMD tables for broadcast distribution and foreign devices) Configuring BACnet/Ethernet Properties Commands to the BACnet Service Using Debug Options Adjunct Configuration: bacnet.properties File

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

61

Chapter 6 BACnetService Property Sheet Overview

Configuring BACnetService Properties

BACnetService Property Sheet Overview


The BACnetService property sheet has two major types of tabs (Figure 6-1): Main tabsGeneral, Poll, DeviceStatus, and tabs for different link-layer (networks), BACnetIP, BACnetEthernet, and BACnetMSTP, 2, 3 and 4. Sub-tabsvary by main tab selected. For the main tab General, sub-tabs include Status, Config, Visual, Engineering, and Security.

Figure 6-1 BACnetService property sheet.

Right-click BACnetService, select Go > Properties.

Two rows of tabs, with main tabs at top and subtabs at bottom. When you click (select) any main tab, whatever subtabs it has appear at the bottom.

Resizing the JDE window smaller creates more rows for the tabs, with some link-layer main tabs remaining at the top. Subtabs always remain at the bottom.

When first configuring a station, you need to change properties on at least one of the link-layer (network) tabs, as described in Chapter 1, Getting Started. You also need to assign a unique device ID on the General, Config tab.

Note

Properties on the BACnetMSTP tabs are covered in Appendix F, Niagara MS/TP Support. Please refer to BACnetMSTP, page F-8. As explained in that appendix, initial support for BACnet MS/TP is available only JACE-4 or JACE-5 platforms, and requires the JACE to be licensed with the optional bacnetMSTP feature.

62

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties General Properties

General Properties
General properties have no specific associated task, however, among the different sub-tabs there is valuable information. Included are status counts on BACnet object capacities, config properties with a router table, engineering properties including setup for BACnet time-synch reception, and various other items. The important General sub-tabs are Status, Config, and Engineering.

Status
Figure 6-1 shows the General, Status tab for the BACnetService, where all properties (except description) are read-only. Included are object count figures which can be useful to estimate remaining object capacities. Each property is listed below with a brief description.
objectType: Fixed as BACnetService. statusFlags: Current Niagara service state, as either {ok} if station is running or Down if station is opened offline.

Note

Starting in r2.3.5, a {fault} status is displayed if a link-layer tab is enabled but has a fault condition.

description: Niagara service description, by default Handles reads / writes to

remote BACnet devices.


bacnetObjectCount: Total number of all BACnet shadow objects currently in the

station, including both parent device objects and child shadow objects.
bacnetDeviceCount: Number of parent (BACnetDevice) objects in the station.

Includes devices associated with all link-layers and networks.


routingEnabled: Applies if multiple link-layers (for example, BACnet/IP and

BACnet/Ethernet, or perhaps BACnet/IP and BACnetMSTP) are enabled. Shows True provided a single path to BACnet devices is detected, else False if multiple paths to devices are detected, such as from a Who-Is request. If routingEnabled is False it means the station is configured as a router (more than one link-layer tab is enabled), but it is not currently operating as a router, because another remote device is performing routing between the associated networks. In this case, it is recommended that you investigate and eliminate the redundant paths between BACnet devices.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

63

Chapter 6 General Properties

Configuring BACnetService Properties

Config
Apart from the Device ID for the JACE station (see Configuring Essential Station Properties, page 1-11), other properties on the General, Config tab are for: APDU properties, used for BACnet messaging. A router table, showing BACnet routers known to the station. Included is the ability to modify, add, or remove routers in this table.

Typically, the default APDU parameters for the BACnet service are sufficient when integrating a Niagara host in a BACnet network. Also, necessary routers are typically learned as a result of a whoIs command issued from the BACnetUtility.
Procedure 6-1 Accessing APDU properties and router table.

Step 1

In the Tree View, expand the stations services folder and right-click the BACnet service node. Select Go > Properties to open its Property Sheet. Click on tabs General, Config. (Figure 6-9).
Figure 6-2 General, Config tab of BACnet service property sheet.

Step 2

APDU properties Only the bottom two properties effect any change in the stations handling of APDUs in BACnet messaging.

APDU properties

APDU (application protocol data unit) handling properties are described as follows:
segmentationSupported: Shows that segmentation is supported by the Niagara station. This is a read-only property. apduSegmentTimeout: Specifies a timeout, in milliseconds, for retransmission of APDU segments. The default value is 2000 ms. apduTimeout: Defines the timeout, in milliseconds, for any APDU requiring

retransmission, before it is resent. APDUs are required to be retransmitted whenever a confirmed message service is used, and a message-reception acknowledgement is not received. The default value is 3000 ms.
numberOfApduRetries: Defines the maximum number of times an APDU will be resent, each following an APDU timeout, when a message-reception acknowledgement is not received. The default value is 3.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

64

Chapter 6

Configuring BACnetService Properties General Properties

Notes

In practice, BACnet recommends the same APDU timeout and retry parameters to be used among all BACnet devices on the same network. APDU parameters affect Niagara-generated BACnet alarms, if associated BACnetRecipient object(s) are configured to issueConfirmedNotifications. For more details, see the BACnetRecipient section on page 5-5.

Router Table

The router table is shown near the bottom of the property sheets General, Config tab (Figure 6-3). It shows all external BACnet routersmeaning all those currently known to the station. Each row in the table represents one logical router. Starting in r2.3.5, the router table shows BACnet router attributes Port ID, Status, and Port Info (in addition to DNET, Rtr Net#, and Rtr MAC Addr.).
Figure 6-3 Router table on General, Config tab.

Note

Port ID

DNET

Rtr Net#

Rtr MAC Addr

Status

Port Info

From left-to-right, the six routerTable columns are described below:


Port ID: Logical mapping to the local port on the Niagara host used to rout to this

network, where 1=BACnet/IP, 2=Ethernet, 36=Serial (MSTP1MSTP4).


DNET: Destination network number, meaning the remote BACnet network reached

through the router. The far-side network.


Rtr Net#: Local network number for the router, or the near-side network. This is a

network number on the services link-layer tab (BACnet/IP or BACnet/Ethernet).


Rtr MAC Addr: BACnet MAC (media access control) address of router device, in hexadecimal. Format varies according to link-layer for the local (Rtr Net#) network.

BACnet/IP: xx:xx:xx:xx:yy:yy where xx:xx:xx:xx is IP address and yy:yy is UDP port. BACnet/Ethernet: devices 48-bit Ethernet MAC address nn:nn:nn:nn:nn:nn

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

65

Chapter 6 General Properties

Configuring BACnetService Properties

Status: Currently known status of this router, either:


okCan be used to get to other networks. router unavailableA reject message was received from this router for this DNET, or the port used to reach this network is not enabled in Niagara. router busyA Router-Busy-To-Network message was received, indicating that this router is temporarily implementing congestion control. router not connectedAn I-Could-Be-Router-To-Network message was received from a BACnet half-router (provides PTP connection to another half-router, through which another DNET is reachable, but by request only). unknownA router table entry exists for the destination network, but verification has not occurred (not sent packets to the network and received messages from that router, indicating existence and operation for that DNET).

Port Info: Information about the local port, where Annex J IP is the default text

for BACnet/IP, Ethernet is the default text for BACnet/Ethernet, and MSTP14 is the default text for local MS/TP ports. Networks reachable through routers may not show port info (may have blank field), or if port info was received with unprintable characters, the read-only checkbox Binary-converted port info will be checked when selecting the router in the table.

Changing the Router Table


Typically, the router table is automatically populated after performing whoIs command(s), and does not require further maintenance. However, in some scenarios you may need to manually add, remove, or modify router entries. Procedure 6-2 provides the suggested steps for manually adding a new router.
Procedure 6-2 Manually adding a new router.

Step 1

Click in the Port ID field and enter the local port used to access the remote router, either 1 (IP/Ethernet), 2 (Ethernet), 36 for MSTP1MSTP4 (if JACE-4/5 only). Click in the DNET field and enter the known remote (far-side) network address. Click in the Rtr Net# field and enter the local network number used to reach the router. Click in the Rtr MAC Addr field and enter the known BACnet MAC address for the router device. Click the Add button, then Apply button (window bottom). The router is added to the table with an initial status of unknown, until verification is received that it is operational.

Step 2 Step 3 Step 4

Step 5

Notes

To modify an entry, click it in the table, then edit any selected field as needed. When done, click Modify button, then the Apply button (window bottom). The routers status changes to unknown until verification is received. To remove an entry, click it in the table. Click Remove button, then Apply.

66

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties General Properties

Engineering
Apart from various debug options covered in another section (Using Debug Options, page 6-24), the General, Engineering tab holds a number of properties that affect ongoing station operation.
Figure 6-4 General, Engineering tab of BACnet service property sheet.

Message Queue Properties

Four Unrelated Properties

They are described in the following sections, following a top-to-bottom order of how they appear on the Engineering tab. Message Queue Properties Four Unrelated Properties

Message Queue Properties

Three properties specify message queue sizes, which apply to different protocol layers.
transportQueueSize: Message capacity of the transport layer queue. serverQueueSize: Message capacity of the server layer queue. clientQueueSize: Message capacity of the client layer queue.

These properties specify the number of messages each queue can hold before overflowing. As messages in queues are typically processed very quickly, the default settings for each, 16 (messages), is typically sufficient. In the case of a Who-Is command, a symptom of a queue-size problem may be that some devices (otherwise known to exist on the network) are not reported.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

67

Chapter 6 General Properties

Configuring BACnetService Properties

Leave queue sizes at 16, unless you receive exceptions in Standard Output with messages like QueueFullException or QUEUE_OVERFLOW, with an accompanying transport or server label. In this case, increase queue sizes slightly (say to 18 or 20), until the same behavior does not generate the queue overflow. The possibility of queue-full exceptions is greatest when:
1. 2.

There are many BACnet devices, all responding simultaneously to a request (Who-Is, Who-Has) issued from the Niagara station. Most BACnet devices are the same types, meaning that they respond at the same time (far less likely if devices are different).

The recommended adjustment range for each is from 16 to 100, maximum. If many BACnet devices are the same, you may need to adjust each queue size upwards, to a number nearly equal to the number of identical devices.

Four Unrelated Properties

These unrelated properties appear grouped together: transportLockupThreshold, covResubscriptionInterval, timeSynchAcceptType, and rewriteDelay.
transportLockupThreshold: Default value is 30000 ms (30 seconds).

The need to edit this parameter is expected to be rare. You might need to adjust this upwards if a device (for whatever reason) takes longer than this period to respond to a learnDevice commandfor example, build its object list.
covResubscriptionInterval: Default value is 600 seconds, and the range is from

300 to 2147483647 (MAX_VALUE). This value is global for all objects in the station configured to useCOV, and represents the frequency at which COV resubscription requests are sent to the various devices. Typically, there is no reason for you to change this property. However, you may notice that if you disable a device for polling, objects configured to useCOV will update for some period of time, but typically not longer than this period. For related information, refer to Using COV in Shadow Objects, page 3-18.
timeSynchAcceptType: Default is None (no BACnet time synchronization

messages are accepted). Available options are: TimeSynch Only, UTCTimeSynch Only, and Both. A JACE station can be configured to accept periodic time-synchronization messages from any networked BACnet time-synchronization master device, which is in turn configured with a list of specific recipients. Acceptable messages types can be either BACnet TimeSynchronization or UTCTimeSynchronization, or both. Upon receipt of a valid message, the JACE adjusts its internal clock if necessary. Typically, you configure the JACE to accept UTC time-synch only when the sending BACnet master is in a different time zone.
rewriteDelay: Global rewrite value that applies to all input-writable shadow objects.

Default is 60 seconds, range is from 30 to 2147483647 (MAX_VALUE). This delay is observed following an input write to a shadow object and a subsequent poll determines a mismatch between the input value and output value. For more complete information, refer to Writing to BACnet Objects, page 3-25.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

68

Chapter 6

Configuring BACnetService Properties Configuring BACnet Polling

Configuring BACnet Polling


The BACnet service uses an object poll scheduler to periodically poll1 shadow objects in BACnet/Ethernet and BACnet/IP devices set for polling. A continuously-repeating, consecutive scan is performed by the BACnet poll scheduler. Polling of these objects uses a single process thread in the running station.
Note

In r2.3.5, you can define a poll delay for BACnet devices that cannot keep up with Niagara polling, either at the parent (device) or child shadow object level. Due to token-passing timing issues, this option does not apply to BACnet MS/TP devices. For details, see descriptions for the BACnetDevice engineering property userData, page 3-10, and child objects engineering property userData, page 3-22. Need for this configuration is expected to be rare. Please note that it adds to the overall poll cycle time, but may be necessary under certain circumstances. If the station is enabled for BACnet MS/TP, that is a JACE licensed for bacnetMSTP, a separate (but similar) polling scheduler is used for each enabled BACnetMSTP tab or network. For related details, refer to Appendix F, Niagara MS/TP Support.

Note

The remainder of this section applies only to the main BACnet poll scheduler used for retrieving values from objects in BACnet/Ethernet and BACnet/IP devices. The property sheet for the BACnet service includes Poll and DeviceStatus tabs with properties for configuration and status of both the poll scheduler and device status monitoring/ping mechanism. The following sections apply to the BACnet poll scheduler: About the Poll Scheduler Accessing Poll Scheduler Properties

About the Poll Scheduler


The poll scheduler periodically polls BACnet objects represented by BACnet shadow objects, provided that: The parent (BACnetDevice) object is enabled for polling (status ok). The shadow object resides in a container under that BACnetDevice object. See the next section, Exceptions to Polling.

Each object is polled with a message sent to the BACnet device requesting the shadowed objects current values for properties Present_Value and Status_Flags. The property sheet for each shadow object shows a {P} by these two polled properties (presentValue and statusFlags), which are transient types. The combination of these properties is also reflected at the statusOutput for each object.

1. For all shadow objects not successfully subscribed for COV notifications.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

69

Chapter 6 Configuring BACnet Polling

Configuring BACnetService Properties

In r2.3.4 and later, BACnet shadow objects with a priorityArray input (types AO, BO, MSO, AVP, BVP, MSVP), also have the objects Priority_Array values polled. Remaining properties of a shadow object are mostly on_demand_transient types and foreign_persistent types, are indicated by an {F} on the property sheet. You must issue a fetch command (or an upload command) for the shadow object to refresh these values. Refer to the Common Commands section on page 3-17.

Exceptions to Polling
A BACnet shadow object is not polled under any of the following circumstances: It does not have a priorityArray input, and has successfully subscribed for COV notifications with the remote device. In this case, properties Present_Value and Status_Flags are updated with received COV notifications. (See the next Note.) If the object resides in a PollOnDemand container, and its linked Gx object is not currently being viewed (or in a view cache). See Polling On Demand. If the objects parent (BACnetDevice) object is disabled (outOfService). Typically, this means it has been given a disablePolling command. If polling is disabled (On the Poll, Config tab, pollDisabled is set to True). No BACnet shadow objects are polled in this case.

Polling On Demand

The BACnet service supports use of the PollOnDemand container under any BACnetDevice container. A BACnet shadow object in a PollOnDemand container polls only while a linked Gx object is viewed in a GxPage graphic. Such dynamic polling is automatic, and applies whether the GxPage is being viewed in the JDE or in a Web browser connection. This feature allows the services Poll Scheduler to keep a smaller list of poll always objects. The resulting poll cycle time is reduced for better control response (and also quicker updates when monitoring).
Note

If a BACnetDevice is configured to useCOV (and the device supports SubscribeCOV), child objects configured for useCOV that are placed in PollOnDemand containers operate in the follow manner:

When first being viewed, child objects are polled on the first cycle, and issue a subscription request to the device (COV server). If an object successfully subscribes for COV, it is removed from the polling list, and future updates are from COV notifications while it is being viewed (or in the view cache). If the object cannot successfully subscribe after 3 successive attempts, it remains in the poll list while it is being viewed (or in the view cache). When viewing ends (or the view cache is overwritten) child objects that are subscribed for COV request to unsubscribe from the device (COV server), and become unsubscribed.

For related information, refer to Using COV in Shadow Objects, page 3-18.

610

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Configuring BACnet Polling

PollOnDemand Containers
Icons for the two types of containers appear slightly different in JDE Tree View. The PollOnDemand container shows a diagonal line through it: The PollAlways container shows no diagonal line:

Figure 6-5 PollOnDemand containers for BACnet shadow objects linked to Gx objects.
BACnetDevice object operates like a PollAlways container for any directly contained shadow objects. You can create other PollOnDemand and/or PollAlways containers under the BACnetDevice and move (or cut and paste) shadow objects to them.

Caution

BACnet shadow objects in PollOnDemand containers should only be linked to Gx objects, and not to other control objects (or log-type objects). If the linked Gx objects are in a GxPage container, this provides dynamic system monitoring for a user, including right-click command access. However, when not being polled, the shadow objects output(s) go to an outOfService status. Furthermore, following a station restart, outputs of unpolled objects initialize as 0 if analog, or inactive if binary.

Notes

PollOnDemand behavior is controlled by a child objects immediate parent containera PollOnDemand container somewhere else in the parentage of an object is inconsequential. Linkage to any of the single-input type Gx objects is supported when using shadow objects in a PollOnDemand container. This includes types GxText, GxBoolean, GxDamper, GxFan, GxFloat, and GxInteger. Linkages to multi-input Gx types, such as GxSpectrum and GxTimePlot, are not supported. After viewing linked Gx objects in JDE, polling continues for the associated shadow objects in PollOnDemand containers until that view is removed from the view cache. Typically, this means 4 view changes before polling stops.

Calculating the BACnet Poll Cycle Time

Value/status updates from object polling can be just a few seconds apart or may be a minute or more. The main factors are the number of shadow objects being polled, and if the BACnet ReadPropertyMultiple service is supported by devices. If supported, any learned device will automatically have its Config property readPropertyMultiple set to Truethis results in approximately 60% faster poll of objects in that device (than if just the readProperty service was used). Table 6-1 shows some polling time measurements taken with a station on a BACnet/Ethernet network. In this example, all BACnet shadow objects are in containers to poll always, and all BACnet devices support the ReadPropertyMultiple service.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

611

Chapter 6 Configuring BACnet Polling

Configuring BACnetService Properties

Note

In practice, actual objects-per-second rates are dependent on a number of variables, including the existing network topology and the capabilities of the BACnet devices.
Table 6-1 Example BACnet poll cycle times for BACnet/Ethernet network.

Objects / Sec
32 objects / sec

Poll Time for 125 objects


4 seconds (4000 ms)

Poll Time for 250 objects


8 seconds (8000 ms)

COV Updates

Client-side support for the BACnet SubscribeCOV service means quicker data updates (than polling) for those shadow objects successfully subscribed for COV. Binary and multistate-type shadow objects update the statusOutput (Present_Value, Status_Flags) immediately upon any change. Analog-type shadow objects update the statusOutput upon each Present_Value change equal or greater to the objects COV_Increment value, or upon any change to Status_Flags. For related information, refer to Using COV in Shadow Objects, page 3-18.

Accessing Poll Scheduler Properties


Poll scheduler properties are under the Poll tab of the BACnet service. Properties are grouped under three sub-tabs: Status, Config, and Engineering.
Procedure 6-3 Accessing poll scheduler properties.

Step 1

In the Tree View, expand the stations services folder and right-click the BACnet service node. Choose Go > Properties to open its property sheet. For status properties, click on tabs Poll, Status. A collection of 10 real-time status properties related to polling is shown (Figure 6-6).
Figure 6-6 Poll, Status tab of BACnet service.

Step 2

Step 3

For config properties, click on tabs Poll, Config. This shows the 3 configuration properties related to polling (Figure 6-7).

612

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Configuring BACnet Polling

Status

Poll status properties show accumulated poll statistics since the last station restart, or since a resetStatistics command (see Tip, below). Status properties include:
polledDeviceCount: Total number of BACnet/Ethernet and BACnet/IP devices shadowed in the station. Note that directly-connected BACnet MS/TP devices (if any) are not included. polledObjectCount: Total number of child BACnet shadow objects in the devices

above, minus any inactive ones in PollOnDemand containers. This number varies if PollOnDemand containers are used and GxPages are being viewed and/or closed. polledObjectCount does not vary as BACnetDevices are enabled/disabled for polling (all devices can be disabled without affecting the objectCount).

Note

averagePollExecuteTime: Reflects the average time, in milliseconds, for the object

poll cycle. Equals the totalExecuteTime / executionCycles.


totalPollExecuteTime: Reflects the total time, in milliseconds, that object polling

has operated.
pollExecutionCycles: Total number of poll scheduler cycles. pollOverruns: Number of times the poll cycle took longer than the configured

pollCycleTime (as defined on the Poll, Config tab), within a 10% margin. Note this does not indicate a problem (all objects are polled), merely that cycleTime is set too short. If overruns continue, the pollInterNodeDelay value will likely be at or near 0.
pollStartTime: Shows the date and timestamp for when the BACnet service was last started (station restarted). averagePollIntercycleDelay: Average time, in milliseconds, between successive

starts of the poll cycle since statistics were accumulated. Provides a possible starting point for a target poll cycle time.
pollLateStarts: Another polling statistic. The number of poll cycles that started later than anticipated (going by the pollCycleTime, configured on the Poll, Config tab). pollInterNodeDelay: Shows the idle time (if any), in milliseconds, between polls of individual objects during the last poll cycle. This value ranges from 0 (no delay, poll running as fast as possible) to some positive value. A large value indicates that the pollCycleTime could be adjusted smaller (providing polledObjectCount is static) to provide faster data response.

Tip

In general, the most useful status properties are pollOverruns, polledObjectCount, and averagePollExecuteTime, particularly when setting a median cycleTime. To reset the poll status properties, with the BACnet service property sheet open, select Commands > resetStatistics from the JDE menu bar.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

613

Chapter 6 Configuring BACnet Polling

Configuring BACnetService Properties

Config

Figure 6-7

Poll, Config tab of BACnet service.

Poll config properties are described as follows:


pollCycleTime: Determines the target time, in milliseconds, to complete a poll cycle. The default value is 5000 ms. Typical cycle times range from 5000 ms upwards (although you can set it lower, in general this is not recommended). See the Calculating the BACnet Poll Cycle Time section on page 6-11 for some examples.

If set lower than the actual poll cycle time, the Status property pollOverruns will steadily increment and the pollInterNodeDelay will approach zero (0). This does not mean a problem, however, merely that the poll cannot run any faster.
pollDisplayDots: For debug mode for the BACnet service. The default is False. If set to True, the characters1 BAC IP/Eth Poll appear in the stations Standard

Output window upon each completed execution of the poll cycle.


pollDisabled: For toggling object polling on and off. The default is False (polling

enabled). While set to True, all object polling is stopped.

Engineering

The Poll tab has an Engineering sub-tab with a single property:


pollDebug: For debug usage. Default is False. While set to True, each polled device

appears as a line in the stations Standard Output window, using the format:
BPoll: polling device <deviceName> {<object type>:<instance number>}

For example:
BPoll: polling device BACdev102 {device:102} @85 00:07:E9:B1:32:77 BPoll: polling device BacSup100c {device:100} @85 00:01:03:E9:F9:56 BPoll: polling device station_x {device:99} @85 00:01:F0:00:02:07 (and so on)

Note

Disable polling debug (pollDebug=False) unless you are investigating a particular poll-related problem. It adds system overhead and decreases overall throughput.

1. Prior to r2.3.5, only a B character is sent to Standard Output upon each poll cycle.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

614

Chapter 6

Configuring BACnetService Properties Configuring Device Status/Ping

Configuring Device Status/Ping


The device status monitor (ping mechanism) operates independently from the poll scheduler. Periodically, a ping message is sent to each BACnet device represented by a BACnetDevice object, requesting the device objects System_Status value. The devices response updates the BACnetDevices systemStatus property; this is typically operational (the default). For any response (except non-operational) the statusFlags property for the BACnetDevice object remains at ok.

If a BACnet device does not respond to the device status ping, or responds with non-operational: Its associated BACnetDevice object updates statusFlags to down, Its object shape, plus the shape and outputs of all child objects turns yellow (down), and, A Niagara Device down alarm is generated (Figure 6-8). All on_demand_transient properties for the device object and child objects show down. The device status monitor continues to ping the device. If the status monitor later receives a response from a down BACnet device: Its associated BACnetDevice object updates statusFlags to ok, Object shapes (and child object outputs) are restored from down, and, A Niagara Device up alarm is generated. All on_demand_transient properties for the device object are refreshed.
Niagara alarm record for a BACnet service alarm.

Figure 6-8

Devices object name in the station appears at the end of eventSwid.

Device up or Device down.

BACnetService shown in the proxySwid.

Note

The device status monitor does not ping any device that is currently shown as outOfService in the station, that is, disabled from polling. These devices appear as cyan in the JDE WorkSpace.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

615

Chapter 6 Configuring Device Status/Ping

Configuring BACnetService Properties

Accessing Device Status Monitor Properties


Under the DeviceStatus tab of the BACnet service are three sub-tabs: Status, Config, and Alarm Setup. Each tab holds properties affecting device status.
Procedure 6-4 Accessing device status monitor scheduler properties.

Step 1

In the Tree View, expand the stations services folder and right-click the BACnet service node. Select Go > Properties to open its Property Sheet. For status properties, click on tabs Device Status, Status. Displayed are 5 real-time status properties for device status (Figure 6-9).
Figure 6-9 Device Status, Status tab for BACnet service property sheet.

Step 2

The deviceStatusObjectCount value shows the total number of BACnet devices. This includes BACnetDevice objects that are currently outOfService (disabled for polling), which are not being pinged for device status.

Step 3

For config properties, click on tabs Device Status, Config. Displayed are 3 configuration properties related to device status (Figure 6-10). For alarm setup, click on tabs Device Status, Alarm Setup. The single property notificationClass is available (Figure 6-11).

Step 4

Status

Device Status status properties (Figure 6-9) show statistics that have accumulated since the last station restart, and are described as follows:
deviceStatusAverageExecuteTime: Reflects average time, in milliseconds, for the

device status cycle (deviceStatusTotalExecuteTime / deviceStatusExecutionCycles).


deviceStatusTotalExecuteTime: Reflects the total time, in milliseconds, for device

status monitoring.
deviceStatusExecutionCycles: Total number of device status monitoring cycles. deviceStatusObjectCount: Number of BACnet devices available for status

monitoring. Includes all BACnetDevice objects, regardless of associated link-layer.


deviceStatusStartTime: Date and timestamp for when the BACnet service was last

started (station restart time).

616

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Configuring Device Status/Ping

Config

Figure 6-10

DeviceStatus, Config tab for BACnet service property sheet.

Device Status config properties are described as follows:


deviceStatusPingDelay: Determines the wait time between the ping of one

device and the ping of the next device. Typical values are from 500 to 5000 ms. The complete cycle time of the device monitor approximately equals: (number of devices) x deviceStatusPingDelay.

Note

deviceStatusDisplayDots: For debug use with the BACnet service. The default is False. If set to True, a B character appears in the Standard Output window with each execution cycle of the device monitor. deviceStatusDisabled: For toggling the device status monitor on and off. The

default is False (device status enabled). While set to True, the device status monitor is disabled. However, normal polling of objects, if enabled, continues.

Alarm Setup

Figure 6-11

DeviceStatus, Alarm Setup tab for BACnet service property sheet.

A single property is on the DeviceStatus, Alarm Setup tab:


notificationClass: Determines the assigned notification class for BACnet device

alarms. These alarms may be received whenever the device status monitor is enabled. By default, notification class 0 is used. Any value from 0 to 8388607 is valid, providing a NotificationClass object with that same number exists in the stations NotificationService container.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

617

Chapter 6 Configuring BACnet/IP Properties

Configuring BACnetService Properties

Configuring BACnet/IP Properties


The BACnetIP tab has two sub-tabs: Config and Engineering. Properties apply only if the IP link layer is enabled (first Config property: ipEnable = True). For additional background information on BACnet/IP configuration, including diagrams, refer to Appendix E, Internetworks and BACnet/IP.

Note

Config
Properties on this tab enable BACnet/IP link-layer support, define various operating parameters, and specify the BBMD-related role of the Niagara station (Figure 6-12).
Figure 6-12 BACnet/IP, Config tab for BACnetService.

Typically, key properties on the BACnet/IP Config tab are changed from defaults only when the BACnet service is first configured. Procedures are given in Chapter 1, Getting Started. Refer to the BACnet/IP Considerations section on page 1-11. Config properties are listed here with a brief explanation, default value, and range (if applicable).
ipEnable: Enables or disables all BACnet IP link layer communications. ipNetworkNumber: The BACnet network number associated with this IP link layer.

The default value is 1. Valid range is from 1 to 65534. This number must be unique from any other BACnet network number across an internetwork. If an existing external router resides on this network, use the same network number in use by that router for this network.
subnetMaskString: Defines the working subnet range for the JACE host, using format xxx.xxx.xxx.xxx, where xxx is decimal.

618

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Configuring BACnet/IP Properties

udpPortString: Defines the UDP port monitored for BACnet/IP messaging, both

directed and broadcast. Can be entered using either decimal or hexadecimal format (if hex, requires a 0x prefix, for example 0xBAC0). The default value, 0xBAC0, (47808 decimal) is the defacto BACnet/IP standard. Do not change (unless an existing BACnet/IP network is already configured otherwise). Niagara BACnet 2.203.221 and earlier would always respond (and send to) remote devices on port 0xBAC0, regardless of the UDP port monitored. If you need backwards compatibility with this behavior, you can specify a UDP port for Niagara to always send to, by editing a specific line in the bacnet.properties file, found in the niagara\<release>\nre\lib folder. See Adjunct Configuration: bacnet.properties File, page 6-28.

Note

bacnetIPDeviceType: The BBMD-related role of the Niagara station, either as a:

bbmdBBMD host. foreignDeviceForeign device registered with a BBMD on another IP subnet. noneNeither BBMD or foreign device (default). This is the proper choice if the Niagara host exists on an IP subnet that already has an operating BBMD, or if the installation is not using multiple IP subnets.

remoteBBMDAddress: An operating BBMD for this BACnet network that exists on another (remote) IP subnet. Required if device type is BBMD or a foreign device.

Note

Entry format requires all hexadecimal with colons: xx:xx:xx:xx:yy:yy where xx:xx:xx:xx is IP address and yy:yy is UDP port. For example, if the BBMD has an IP address of 192.168.1.21 and is using the default UDP port (BAC0), its MAC Address is: C0:A8:01:15:BA:C0 You can use the Windows Calculator to convert the IP octets from decimal.

registrationLifetime: (Applies only if the station is configured as a foreign device).

Time period, in seconds, in which the Niagara station will register as a foreign device with the remote BBMD. The station will automatically re-register within this period. The default value is 900 seconds, the valid range is from 300 to 65,535 seconds.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

619

Chapter 6 Configuring BACnet/IP Properties

Configuring BACnetService Properties

Engineering
BACnet/IP Engineering properties apply only if the station is configured to operate as a BBMD (bacnetIPDeviceType is bbmd). This page is divided into two areas: Broadcast Distribution Table (BDT) Foreign Device Table (FDT)

Broadcast Distribution Table (BDT)

This table lists remote BBMDs, and is typically populated as a result of entering a valid IP address in the remoteBBMDAddress property on the Config tab.
Figure 6-13 broadcastDistributionTable, BACnet/IP Engineering tab.

If needed, you can manually add, remove, or modify entries in the BDT. Note that the Distribution Mask property determines if a one-hop or two-hop distribution. To add a new entry, click in the B/IP Address field and enter the remote BBMDs IP address and UDP port in hexadecimal (see Note below), and then click in the Distribution Mask field and enter either FF:FF:FF:FF (for two-hop) or the subnet mask in use for one-hop method. Click the Add button, then Apply button (window bottom). To modify an entry, click it in the table, then edit either property as needed. When done, click Modify button, then the Apply button (window bottom). To remove an entry, click it in the table. Click Remove button, then Apply.

Note

B/IP entries require all hexadecimal format with colons:


xx:xx:xx:xx:xx:xx

For example, to add a BBMD with an IP address of 192.168.1.21 using UDP port BAC0 and a two-hop distribution, the properties would be: B/IP Address: C0:A8:01:15:BA:C0 Distribution Mask: FF:FF:FF:FF You can use the Windows Calculator to convert the IP octets from decimal.

620

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Configuring BACnet/IP Properties

Foreign Device Table (FDT)

This table is populated as BACnet devices (on other subnets) register with the Niagara station/BBMD as a foreign device. Each entry lists the B/IP address (in hex) of the remote device, the registration period (Time To Live in seconds), and the remaining time before the station will purge the entry (providing the device does not reregister).
Figure 6-14 foreignDeviceTable, BACnet/IP Engineering tab.

If needed, you can manually add, remove, or modify entries in the FDT table. You may need to add a device if its incapable of registering itself as a foreign device (likely done through some local configuration at that device). To add a new entry, click in the B/IP Address field and enter the devices address (IP and UDP in hex, see prior Note), and then click in the Time To Live field and enter a registration period, in seconds. See Time To Live, below. Click the Add button, then Apply button (window bottom). To modify an entry, click it in the table, then edit either property as needed. When done, click Modify button, then the Apply button (window bottom). To remove an entry, click it in the table. Click Remove button, then Apply.

Time To Live: The registration period for the device to remain in the stations

BBMD foreign device table, during which period it must reregister to keep from being purged from the table. Devices that externally register typically place a numeric value in this property, such as 1200 (seconds). The default value is infinite (*), meaning that device will never need to reregister with the station, and so will never be automatically purged. In the case of a permanently-installed B/IP device that is incapable of registering as a foreign device itself, * may be the best choice. Impending purge times are displayed in the right-hand Purge Time column of the table. Each device with a numeric Time To Live must reregister before this time to keep from being removed from the FDT. When the device reregisters, the Purge Time value is updated to reflect the new time. Devices with infinite Time To Live (*) have no effective Purge Time.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

621

Chapter 6 Configuring BACnet/Ethernet Properties

Configuring BACnetService Properties

Configuring BACnet/Ethernet Properties


BACnet/Ethernet has only a Config sub-tab with just two properties (Figure 6-15).
Figure 6-15 BACnet/Ethernet tab has only a Config tab with two properties.

ethernetEnable: Enables or disables all BACnet over Ethernet link layer

communications.
ethernetNetworkNumber: The BACnet network number associated with this Ethernet link layer. The default value is 2. Valid range is from 1 to 65534.

This number must be unique from any other BACnet network number across an internetwork. If an existing external router resides on this network, use the same network number in use by that router for this network.

Commands to the BACnet Service


The BACnet service has several commands, available from the JDE menu bar when the services property sheet or BACnetUtility view is displayed (Figure 6-16).
Figure 6-16 Commands to the BACnet service.

622

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Commands to the BACnet Service

BACnet service commands are described briefly below:


dump resetStatistics readBACnetPropertiesFile dumpBACnetPropertiesFile dumpIPTable printLine

dump: Available for every Niagara objectsends debug-level information for that object to the stations Standard Output window. resetStatistics: Resets BACnet service accumulated poll status properties such as

counts (execution cycles, overruns, late starts, etc.) delay times, and elapsed times. Affects both the main Poll scheduler (for BACnet/Ethernet and BACnet/IP) and any enabled BACnetMSTP tabs. See Accessing Poll Scheduler Properties, page 6-12.
readBACnetPropertiesFile: Makes effective any parameters present in the Niagara hosts bacnet.properties file (file must exist in the nre\lib folder). See Adjunct Configuration: bacnet.properties File, page 6-28. dumpBACnetPropertiesFile: Debug command to send the currently effective bacnet.properties settings to the stations Standard Output. For development use. dumpIPTable: A BACnet/IP debug command that lists (to Standard Output) a table of BACnet MAC addresses of known BACnet hosts. An example is shown below.
MAC Address Table: inet:JACENX3/192.168.1.98 mac:C0:A8:01:62:BA:C0 inet:JACENP/192.168.1.102 mac:C0:A8:01:66:BA:C0 Inet Address Table: ipHash:-1062731265 inet:192.168.1.255/192.168.1.255

printLine: Debug usage. Produces a popup dialog (Figure 6-17) in which you can type a line to appear in the stations Standard Output window, for annotation needs.
Figure 6-17 Popup dialog box from printLine command (with default text shown).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

623

Chapter 6 Using Debug Options

Configuring BACnetService Properties

Using Debug Options


The BACnetService includes ten separate debug options, each of which can produce debug-level messages in the stations Standard Output window. By default, each debug option is not enabled (set to False). A lot of BACnet-related information is always sent to Standard Output by the BACnet service (regardless of debug option settings). It is recommended that you read the Standard BACnet Debug Output section first. Typically, you only enable those debug options needed, and only for a short period, while working to understand a BACnet-related issue. The reason for this is that debug operations consume station resources. These resources are normally used to improve performance, such as improved polling times.

Notes

Standard BACnet Debug Output


Before enabling BACnet debug options, it is best to understand what gets sent to the stations Standard Output without any debug options enabled.
Figure 6-18 Standard BACnet debug messages.

The following messages are always sent to Standard Output by the BACnet service: All results from any BACnetUtility command (whoIs, whoHas, learnNetwork, learnDevice, etc.). This is the same text output seen in the utilitys window. All WARNING, TIMEOUT, and ERROR messages related to the operation of the BACnet service. WARNING messages are typically seen as a result of a fetch or upload command for a shadow object, where some requested properties are not known (used) in BACnet object(s). For example, deviceType for an AI:

WARNING: BACnet Read Property Multiple Error: deviceType [/NewJ5b/FirstFloor/BnJACE/Room102]

624

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Using Debug Options

TIMEOUT messages are typically seen for a down BACnet device, such as produced by the ongoing device monitor ping routine. For example:
TIMEOUT: 227 Client 0 00:01:F0:00:02:07 Server 0 00:50:DA:04:E8:6B Transaction Timed out! invokeId 228

ERROR messages occur when the stations BACnet service cannot complete an operation. For example, if you issue a getAlarmSummary for a device that doesnt support this service, a message appears (in part):
In doGetAlarmSummary device.... Transaction Timed out! invokeId 96 TIMEOUT: 96 Client 0 00:01:F0:00:02:07 Server 16 03 ERROR: GetAlarmSummary failed [/NewJ5b/services/BACnetService] tridiumx.bacnet.BACnetException E_BACNET_TIMED_OUT_WAITING_FOR_RESPONSE at tridiumx.bacnet.services.transport.TransactionTag.waitForConfirmation() at tridiumx.bacnet.services.BACnetTransport.sendConfirmedRequest() (plus others similar in nature...)

Various ongoing informational messages, for example:


BACnet Queue event: update unacked alarm table

Debug Option Selections


Debug options are enabled/disabled on the property sheet for the BACnet service, on the General, Engineering tab (Figure 6-19). Debug options can be enabled in any combination. However, be aware that the lower eight (transport, network, ipLink, ethernetLink, mstpnLink n=14) each produce extremely large amounts of output. Output from any debug option is interleaved with Standard BACnet Debug Output.
Figure 6-19 BACnet service Debug Options are on the General, Engineering tab.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

625

Chapter 6 Using Debug Options

Configuring BACnetService Properties

The ten debug selections are described as follows: To decipher this output data, intimate knowledge of the BACnet communications protocol is often needed. Output information is typically useful only to developers.
clientDebugOn: Shows client requests from the station to remote BACnet devices. However, note that client requests related to polling are not included. serverDebugOn: Shows server responses from the station to client requests from

Note

remote BACnet devices.


transportDebugOn: Shows low-level (transport layer) message details on PDUs to

and from remote BACnet devices, including ConfirmedRequests, ComplexAcks, etc. This debug option might be useful in a timeout scenario where the target BACnet device is known to be up.
networkDebugOn: Shows low-level (network layer) message details on PDUs to

and from remote BACnet devices, including address (subnet and device) information. This debug option might be useful in a scenario where BACnet devices are not on the local network (are on the far side of a router).
ipLinkDebugOn: Shows low-level (link layer) message details on the complete PDUs sent and received, in both hexadecimal and ASCII formats. Includes IP address and UDP port information (Example 6-1).
Example 6-1 Example IP Link Debug output (snippet).

lookupInetAddr: C0 A8 01 62 BA C0 <-> ...b.. IP:192.168.1.98 port: 47808 length 30 Packet Sent on port 47808: 81 0A 00 1E 01 0C 00 55 <-> .......U 06 00 01 F0 00 02 07 02 <-> ........ 73 7F 0E 0C 00 00 00 01 <-> s....... 1E 09 55 09 6F 1F <-> ..U.o. Packet Rcvd on port 47808 addr:192.168.1.98, srcPort:47808 81 0A 00 2A 01 20 00 55 <-> ...*. .U 06 00 01 F0 00 02 07 FF <-> ........ 30 7F 0E 0C 00 00 00 01 <-> 0....... 1E 29 55 4E 44 42 80 00 <-> .)UNDB.. 02 4F 29 6F 4E 82 04 00 <-> .O)oN... 4F 1F <-> O. lookupInetAddr: C0 A8 01 62 BA C0 <-> ...b..

Note

By default, IP link-layer debug does not contain the host name for BACnet devices, only their IP address. This provides the most efficient output rate. However, if you require host name data, you can set this in the JACEs bacnet.properties file (at great expense in speed). See Adjunct Configuration: bacnet.properties File, page 6-28.

626

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Using Debug Options

ethernetLinkDebugOn: Shows low-level (link layer) message details on the

complete PDUs sent and received, in both hexadecimal and ASCII formats. See Example 6-2.
Example 6-2 Example Ethernet Link Debug output (snippet).

Packet Sent: 00 01 03 E9 F9 56 F0 00 02 07 00 13 03 01 00 30 2A 0C 00 00 63 19 70 3E 3F Packet Sent: 00 01 03 E9 F9 56 F0 00 02 07 00 20 03 01 08 00 0B 01 29 0E 0C 01 40 00 29 55 4E 91 00 4F 4E 82 04 00 4F 1F Packet Received: 00 01 F0 00 02 07 03 E9 F9 56 00 19 03 01 24 00 0B 01 02 05 2B 0E 0C 01 2A 1E 09 55 09 6F Packet Sent: 00 07 E9 B1 32 77

00 82 0C 91

01 82 02 00

<-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <-> <->

.....V.. ........ ...0*... ..c.p>.. ? .....V.. ..... .. ......g0 )...@.+. )UN..O)o N...O. ........ ...V.... ..$...g. ..+...@. *..U.o. ....2w..

00 82 67 2B 29

01 82 30 1E 6F

00 82 67 40 1F

01 82 FF 00

00 01

mstpnLinkDebugOn: Where n = 1 to 4 according to the corresponding MS/TP network. Shows low-level (link layer) message details on MS/TP frames sent and received, in both hexadecimal and ASCII formats. See Example 6-3.
Example 6-3 Example MSTP Link Debug output (snippet).

Frame 01 00 00 04 83 B8 04 00 Frame 01 04 00 00 1F Frame 01 0C E9 F9 00 80 6F 1F Frame 01 20 E9 F9 02 00

rcvd from 103 DER false 30 BB 0E 0C 00 00 <-> 1E 29 55 4E 44 40 <-> 50 4F 29 6F 4E 82 <-> 4F 1F <-> sent to 103 DER true 02 03 BC 0E 0C 00 <-> 05 1E 09 55 09 6F <-> <-> sent to 103 DER true 00 55 06 00 01 03 <-> 56 02 05 16 0E 0C <-> 00 68 1E 09 55 09 <-> <-> rcvd from 103 DER false 00 55 06 00 01 03 <-> 56 FF 30 15 0C 0C <-> 00 67 19 70 3E 91 <->

..0..... ...)UND@ ..PO)oN. ..O. ........ .....U.o . ...U.... ..V..... ...h..U. o. . .U.... ..V.0... ...g.p>.

Refer to Appendix F, Niagara MS/TP Support, for more information about BACnet MS/TP in Niagara.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

627

Chapter 6 Adjunct Configuration: bacnet.properties File

Configuring BACnetService Properties

Adjunct Configuration: bacnet.properties File


Starting in Niagara Release 2.3 (r2.3.3), several BACnet-related setup properties became available only by editing a text file named bacnet.properties, which resides on the Niagara host in its niagara\<release>\nre\lib folder. This was done to prevent a database schema change for various Niagara 2.3 builds, which would otherwise be required if new properties were modifiable on the BACnet services property sheet. When r2.3.4 was released, changes were numerous enough for a schema change, and these properties (or their equivalents) were moved to the BACnet services property sheet. At the time of the r2.3.5 update to this document, very few BACnet setup properties still require editing of the bacnet.properties file. Example 6-4 shows the default release 2.3.5 bacnet.properties file, containing four properties with explanations. For a related details on bIPAlwaysSentToPort, see the BACnet/IP config property udpPortString:, page 6-19.
Example 6-4 Contents of bacnet.properties file, showing effective default values.

########################################################### # # bacnet.properties # # BACnet properties file # This file contains properties to configure the BACnet # service, that are not included in the property sheets # of the various node objects. # ########################################################### # Niagara versions 2.203.221 and earlier would always respond on port 47808 # (0xBAC0), and always to the remote device's port 47808 as well, regardless of # what UDP port was chosen to listen on. This was fixed in 2.203.222, and in # 2.3 and later releases. In order to provide backward compatibility with # products that may depend upon this earlier behavior, this flag can be set to # force Niagara to always send to a specific port. # Default value: -1 (no always send port) # Typical value: 47808, or 0xBAC0 bIPAlwaysSendToPort=-1 # The 2.5 release of Niagara does not print the host name in # information, because it is a very time-consuming operation # host name from the IP address. If you wish to display the # debug printouts, set this flag to true. # Remember that this significantly slows down the processing # Default value: false bIPDisplayHostName=false IP debug to look up the host name in IP of IP packets.

# By default, any station running the BACnet service uses values found in its # hosts license file (nre\lib\license.properties) to expose as description # and location properties in the BACnet Device object (server object) that # represents the station. The lines used in the license file are as follows: # # customerName=<text string> (used as description) # customerSite=<text string> (used as location) # # If desired, you can override either (or both) of these exposed property text # strings with other text strings by uncommenting (remove leading #) in the # lines below and entering the desired text string immediately after the =: # #description= #location=

628

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Chapter 6

Configuring BACnetService Properties Adjunct Configuration: bacnet.properties File

Notes

As with other Niagara properties files, lines with a leading # character denote comments used to describe the parameter, as used in the example above. The BACnet service also has two related commands: readBACnetPropertiesFileMakes effective any changes made in the hosts bacnet.properties file since the station last started, or since this command was last issued. dumpBACnetPropertiesSend the currently effective bacnet.properties settings to the stations Standard Output window.

Editing bacnet.properties
You can follow Procedure 6-5 to edit and add a bacnet.properties file in a JACE. This procedure makes use of the Host > Edit File feature in the Admin Tool, and works with any JACE platform.
Procedure 6-5 Editing the bacnet.properties file.

Step 1 Step 2

Copy the text lines shown in Example 6-4 (or whatever source) to a new text file. Make the desired changes in the parameter values, and copy the entire contents of the file to the Windows clipboard. Save the file locally as bacnet.properties for future reference, using the path:
D:\niagara\<release>\nre\lib\bacnet.properties

Step 3

Step 4

Open the Admin Tool and connect to the target Niagara host (from the menu bar): Admin Tool > File > Open. Type in the necessary host address, and then host user name and password. With the host visible in the Admin Tool, select from the menu bar: Admin Tool > Host > Edit File > BACnet Properties. This opens an edit window for bacnet.properties. If the JACE already has a bacnet.properties file, you will see its contents in the edit window. You can edit as desired from what you already copied from Example 6-4, or add additional updated information if needed. In the edit window, select Edit > Paste to copy the clipboard contents from Step 2. Click File > Save to create the bacnet.properties file on the remote host, and then close the edit window. The file is created in the nre/lib folder, as needed, on that host. If necessary, you can make future edits to the remote hosts bacnet.properties by simply opening the host in the Admin Tool, reselecting the BACnet Properties file, and then make (and save) any changes.

Step 5

Note

Step 6 Step 7

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

629

Chapter 6 Adjunct Configuration: bacnet.properties File

Configuring BACnetService Properties

Current properties

Apart from the bIPAlwaysSentToPort property already explained, at the time of this manual these other entries are valid in bacnet.properties:
bIPDisplayHostName=true (or false) Applies to BACnet/IP debug usage only. The effective default (no entry) is false. This allows the most efficient BACnet/IP debug to Standard Output, but with only host IP addressesand not host names.

If you require host names as well as IP addresses in debug output (ipLinkDebugOn), but at the expense of much slower response, set this value to true. See Debug Option Selections, page 6-25, for more information on BACnet debug.
description=<string value>

Overrides whatever customerName value is in the hosts license file for usage in the stations Device object property Description. Overrides whatever customerSite value is in the hosts license file for usage in the stations Device object property Location.

location=<string value>

630

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

APPENDIX

Troubleshooting
This appendix explains some troubleshooting techniques that apply to the BACnet service. The following main sections are included: Go/No-Go Communications Checklist Objects Not Polling Checklist Object Color and Status Debug and Standard Output

Go/No-Go Communications Checklist


Use the following checklist when troubleshooting BACnet communications from a JACE station. Only new installations typically require all of these checks.
Table A-1 Go/No-Go Checklist for BACnet service communications.

Check
Is the Niagara host licensed for the BACnet service?

Method
Check that the JACE is licensed. With the JACE open and selected in the Admin Tool, select the Installation tab, then View License. The features line must include bacnet. If a JACE-4/5 requiring MS/TP support, the features line must include an additional bacnetMSTP entry. For further MS/TP details, see Prepare the JACE Host, page F-3.

Is the BACnet service configured for the correct link layer type? If BACnet/Ethernet is used, is the host (PC) properly configured?

Supported BACnet link-layer types include Ethernet and/or IP, and if a JACE-4/5, also MS/TP. For basic BACnet service properties, see Configuring Essential Station Properties, page 1-11. If MS/TP, also see Configure Essential MS/TP Link-Layer Properties, page F-7. If BACnet/Ethernet is used in an engineering PC workstation, see BACnet Over Ethernet Considerations, page C-2.

Is the Niagara host assigned to a unique address on the BACnet network?

The BACnet address for any device is determined by the Device ID of its contained Device object. For a Niagara station, this appears as a Config property of its BACnet service. See Configuring Essential Station Properties on page 1-11.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

A1

Appendix A Objects Not Polling Checklist

Troubleshooting

Objects Not Polling Checklist


Use the following checklist when troubleshooting BACnet shadow objects that do not appear to be polling, even though BACnet communications appear working.
Table A-2 BACnet Integration object Polling Checklist.

Check
Is BACnet (client) polling enabled?

Method
With the station opened in JDE, expand the services folder and right-click on the BACnet service. Select Go > Properties. Then click tabs Poll, Config. The property disabled must be set to False. With the station opened in JDE, double-click on the parent container for the BACnetDevice objecttypically, this is the BACnetTemp container. This displays the device object in the Workspace. A device enabled for polling appears gray; a disabled device appears cyan. Right-click on the disabled device and select enablePolling. In the Tree View, see if the object is in a PollOnDemand container: If so, it will appear with cyan output color whenever its linked Gx object is not being viewed in JDE or from a Web browser.

Is polling enabled for the parent (BACnetDevice) object?

Is the object in a PollOnDemand container?

Is the poll cycle taking longer than anticipated?

Right-click on a static shadow object and select pollRenew. This should cause an immediate update of the objects statusOutput (presentValue and statusFlags), regardless of how many objects are being polled. See Configuring BACnet Polling on page 6-9

Object Color and Status


Color of objects in the JDE is useful in determining object status. This is true with BACnet shadow objects, which have five possible colors:

Gray (status ok) Red (status inAlarm) Orange/Dark Yellow (status fault) Cyan/Light Blue (status outOfService) Yellow (status down)

In addition, color of outputs on BACnet shadow objects can vary from black on white background to other colors. In all but one case, an objects output color reflects its object color (meaning that its output status is the same as its object status). See the Note on page A-5 for the sole exception.

Gray

Gray object color means status ok (Figure A-1). This is the color seen when a BACnet shadow object is created from the BACnetUtility, after BACnet objects have been learned. If the output is linked to another object in the station, its output value seen in Monitor Mode is typically black (normal). By default, BACnet shadow objects copied from the Local Library also show this color (are status ok).

A2

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix A

Troubleshooting Object Color and Status

Figure A-1

Gray object color is status OK.

Notes

Shadow objects and their statusOutputs change from the gray (ok) color to yellow (down) whenever the device status ping marks the parent device down, or when a non-operational response is received. Objects appear as in Figure A-8. Refer also to Configuring Device Status/Ping, page 6-15. In previous Niagara releases, when the parent (BACnetDevice) object goes down, child BACnet shadow objects retain the last known value and status (typically ok, meaning gray object color). However, the BACnetDevice object itself changes color to yellow (down), as shown in Figure A-7.

Red

Red object color means status inAlarm. BACnet shadow objects become this color when presentValue meets the objects configured alarm setup (high or low limits if analog, alarmState if binary). The statusFlags property shows inAlarm and the statusOutput also becomes red, to indicate an alarm condition.
Figure A-2 Red object color is status inAlarm.

Orange/Dark Yellow

Orange/dark yellow object color means status fault. Analog type objects (AI, AO) become this color when the presentValue goes below minPresentValue or above maxPresentValue. The statusFlags property shows fault and the statusOutput also becomes orange, to indicate a fault.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

A3

Appendix A Object Color and Status

Troubleshooting

Figure A-3

Orange object color is status fault.

Cyan/Light Blue

Cyan/light blue object color means status outOfService. BACnet shadow objects show this color under these circumstances: If a parent (BACnetDevice) object, whenever it is commanded to disablePolling (provided it was previously status ok). See Figure A-4. If a child BACnet object, whenever it is set to this state by writing a True to the outOfService property (providing the object was previously status ok). Outputs of an object set to outOfService are also cyan. See Figure A-5. If an object is in an alarm or fault state, however, its object color (and outputs) remain red or orange, respectively, even when set to outOfService.

Figure A-4 BACnetDevice set to disablePolling is cyan (outOfService).

Figure A-5

Cyan object color and outputs means status outOfService.

A4

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix A

Troubleshooting Object Color and Status

Note

A BACnet shadow object in a PollOnDemand container will show outputs as cyan (outOfService) yet remain gray (status ok) whenever it is not currently polled by the JACE (Figure A-6). Polling occurs only when its linked Gx object is viewed in the JDE or a Web browser connection. See Polling On Demand on page 6-10
Figure A-6 Cyan output (only) occurs for inactive objects in a PollOnDemand container.

Yellow

Yellow object color means status down. If the device status monitor (ping) is enabled, a BACnetDevice object will show as down (yellow) whenever the associated BACnet device does not respond to the device status ping (Figure A-7). Only BACnetDevices that are enabled for polling (status ok) are pinged by the device status monitor. If commanded to pollingDisabled, a device is not pinged.
Figure A-7 Yellow BACnetDevice object means the BACnet device is down.

Note

All child shadow objects (and their outputs) are also yellow (down) in this case. See Figure A-8. Also, for all objects, down is the normal object status if the station is opened offline.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

A5

Appendix A Debug and Standard Output

Troubleshooting

Figure A-8

Yellow object color (status down) occurs when the parent device is down or whenever the station is opened offline.

Debug and Standard Output


The BACnet service displays numerous messages in the stations Standard Output. Using the Admin Tool, observe the stations Standard Output (without enabling any of the special BACnet debug options). If you are having problems with the BACnet integration, you will typically see some related messages (Figure A-9).
Figure A-9 Standard Output can provide clues for BACnet-related problems.

Note

If you want, you can set further debug options on the General, Engineering tab of the BACnet services property sheet. Refer to the the Using Debug Options section on page 6-24 for more information. You can also set the BACnet services poll scheduler and device status mechanisms to post a debug character in Standard Output for each execution cycle. Each cycle is indicated by a B, as shown in Figure A-10 below. Enable or disable these characters from the property sheet for the BACnet service: Poll, Config tab (displayDots property). DeviceStatus, Config tab (deviceStatusDisplayDots property).

A6

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix A

Troubleshooting Debug and Standard Output

Figure A-10 displayDots posts a B for each poll cycle and/or device status ping cycle.

BACnet Troubleshooting Tips


Because each BACnet integration is unique, there is no set procedure to use when using Standard Output to troubleshoot BACnet issues. However, the following tips may prove useful:

If the station is running other device integrations, disable their debug settings (assuming only BACnet service messages are needed). Reduce the scope of BACnet client polling, as needed, by issuing disablePolling commands to the appropriate BACnetDevice objects. Enable specific BACnet debug options only if prepared to collect (and parse through) large amounts of data. This is especially true for the protocol layer-specific debug options (transport, network, and link options). Refer to the the Debug Option Selections section on page 6-25 for more information. Dont leave BACnet debug options, if any, enabled unless you are using this feature to troubleshoot. Debug options require additional station resources that are better left for normal operation. In the case of errors, it can be helpful to copy and save Standard Output. Do this by clicking on Freeze and then blocking the text of interest. Then click Copy to put the text on the Windows clipboard. Paste the output in Notepad or any other text editor and save, if needed.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

A7

Appendix A Debug and Standard Output

Troubleshooting

A8

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

APPENDIX

BACnet PICS
This appendix provides the PICS (Protocol Implementation Conformance Statement) for the Niagara Framework, with the following main sections:

PICS BACnet Conformance Class Supported PICS BACnet Functional Groups Supported PICS BACnet Standard Application Services Supported PICS Standard Object-Types Supported Segmentation Capability PICS Data Link Layer Option Networking Options PICS Character Sets Supported BIBBs Compatibility (BACnet Interoperability Building Blocks)

BACnet Protocol Implementation Conformance Statement


Vendor Name: Tridium, Inc. Product Family: Niagara Framework, including Vykon Web Supervisor, Vykon

BACnet Supervisor, JACE-NP-1, JACE-NP-2, JACE-4XX, JACE-5XX at Release 2.3.4XX or 2.3.5XX.


Description: This product family provides bi-directional communication between the Tridium Niagara Framework, and a BACnet system operating at BACnet Conformance Class 3, over Ethernet media or over MS/TP.

PICS BACnet Conformance Class Supported


Class 1 Class 2 Class 3 Class 4 Class 5 Class 6 complete complete complete partial partial partial

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

B1

Appendix B BACnet Protocol Implementation Conformance Statement

BACnet PICS

PICS BACnet Functional Groups Supported


HHWS PCWS partial partial

PICS BACnet Standard Application Services Supported


Application Service
ReadProperty ReadPropertyMultiple ReadRange (trend log only) WriteProperty WritePropertyMultiple ConfirmedEventNotification UnConfirmedEventNotification AcknowledgeAlarm GetAlarmSummary Who-Has I-Have Who-Is I-Am SubscribeCOV ConfirmedCOVNotification UnconfirmedCOVNotification

Initiate Requests
yes yes no yes yes yes yes yes yes yes yes yes yes yes no no

Executes Requests
yes yes yes yes yes yes yes yes yes yes yes yes yes no yes yes

PICS Standard Object-Types Supported


Object-Type
Analog Input Analog Output Analog Value Binary Input Binary Output Binary Value Schedule (exported as read only) Calendar (exported as read only) Trend Log (exported as read only) Multistate Input Multistate Output Multistate Value Device

Supported
yes yes yes yes yes yes yes yes yes yes yes yes yes

Dynamically Dynamically Creatable Deletable


no no no no no no no no no no no no Not applicable no no no no no no no no no no no no Not applicable

B2

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix B

BACnet PICS BACnet Protocol Implementation Conformance Statement

Segmentation Capability
Feature
Segmented Request Segmented Response

Supported
yes yes

Window size
any any

PICS Data Link Layer Option


ISO 8802-3, 10BASE5 ISO 8802-3, 10BASE2 ISO 8802-3, 10BASET ISO 8802-3, Fiber BACnet / IP - Annex J MS/TP master (JACE only) yes yes yes yes yes yes

Networking Options
Router, Clause 6 - Ethernet IP-Ethernet, Ethernet-MS/TP, Ethernet IP-MS/TP BACnet Broadcast Management Device (BBMD) yes yes

PICS Character Sets Supported


ANSI X3.4 yes

BIBBs Compatibility (BACnet Interoperability Building Blocks)


Data Sharing
DS-RP-A, B DS-RPM-A, B DS-WP-A, B DS-WPM-A, B DS-COV-A DS-COVU-A

Alarm & Event Management


AE-N-A, B AE-ACK-A, B AE-ASUM-A, B

Scheduling
SCHED-B

Device & Network Management


DM-DDB-A, B DM-DOB-A, B NM-RC-A

Trending
T-VMT-B

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

B3

Appendix B BACnet Protocol Implementation Conformance Statement

BACnet PICS

B4

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

APPENDIX

BACnet PC Notes
This appendix provides configuration details for running the Niagara BACnet service on a PC. This configuration is not necessary for any JACE controller, which is shipped from the factory with the appropriate communications adapters and drivers.
Note

BACnet is not typically licensed to run on a Web Supervisor (a station that runs on a job-owned PC). However, a Vykon System Integrator may need to run the BACnetService on a company-owned PC for job configuration, maintenance, or demonstration purposes. Also, a BACnet Supervisor product is now available. For equivalent information, please refer to the Niagara BACnet Supervisor Reference. The following main topics are contained: Installing the BACnet Service BACnet Over Ethernet Considerations

Installing the BACnet Service


The Niagara BACnetService can run on a PC station using a link-layer type of either Ethernet and/or IP, the same as on a JACE controller. However, BACnet over Ethernet on a PC requires a special device driver for low-level network access.
Procedure C-1 Installing the BACnet service at a PC station, using the installed JDE.

Step 1

In the station on the PC, add the BACnet service, if not already installed. Refer to the Installing and Configuring the BACnet Service section on page 1-8. In the BACnetService, specify the unique BACnet Device ID (Instance Number) for the PC, and configure the link-layer types to be Ethernet and/or IP link layer. Refer to the Configuring Essential Station Properties section on page 1-11.
a. b.

Step 2

If Ethernet link layer, follow instructions in the next section, BACnet Over Ethernet Considerations. If IP link layer, refer to the the BACnet/IP Considerations section on page 11.

Step 3

Follow instructions in the Verifying Communications section on page 1-13.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

C1

Appendix C BACnet Over Ethernet Considerations

BACnet PC Notes

BACnet Over Ethernet Considerations


If you have a Niagara PC or Web Supervisor that is licensed for the BACnet service, and you will be using it for BACnet over Ethernet, the drivers.properties file in its niagara\<release>\nre\lib directory must have an entry for the device name of the Ethernet adapter (as it is known your PCs operating system). In Niagara r2.301.430 or later (r2.3.5), a setAdapter utility greatly simplifies this. Simply follow the few steps in the next section, Using setAdapter.exe. If you are using Niagara r2.3.4 or earlier (any build prior to r2.301.430), jump ahead to the section Manually Editing driver.properties.
Notes

If at some point you modify this entry in drivers.properties again, you must restart any running station for the BACnetService to use it. This configuration applies to the host (PC), and not the Niagara station. If you install a later 2.x Niagara build on your Niagara engineering PC, copy the edited drivers.properties file to the new niagara\<release>\nre\lib folder. Otherwise, BACnet/Ethernet link-layer communications will not work.

Using setAdapter.exe
Procedure C-2 Using setAdapter.exe to edit drivers.properties.

Step 1 Step 2 Step 3

At the Web Supervisor / Niagara engineering PC, stop any currently running station. Open a Niagara console window (Start > Programs > Niagara (build) > Console). At the command prompt, type: setAdapter and press ENTER. This returns a list of all real Ethernet adapters in the PC (typically only one). At the enter number of choice prompt, type the appropriate number for the Ethernet adapter used for BACnet communcations, then press ENTER. The utility automatically edits the drivers.properties file with the correct device name, for example:
ethernet.deviceName=\\Device\\{C37783-84DC-430E-B3B6-25AE81E77F88}

Step 4

and also saves the file.


Step 5

Close the Niagara console and restart the station.

C2

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix C

BACnet PC Notes BACnet Over Ethernet Considerations

Manually Editing driver.properties


The following two topics explain how to proceed: Determine Device Adapter Name Edit drivers.properties

Determine Device Adapter Name

Depending on the operating system used on your PC, there are two different methods to determine the Ethernet adapter device name. Windows NT method Windows 2000 or XP Pro method

Windows NT
The Ethernet device adapter name under Windows NT is a short character string.
Procedure C-3 Determining the Ethernet device name under Windows NT.

Step 1 Step 2

Open a command prompt (MS-DOS) window. Type ipconfig and press ENTER. Your Ethernet adapter name and IP configuration appear, as shown in Figure C-1.
Figure C-1 Ethernet adapter device name in a command prompt window.

Ethernet adapter name. In this example, the name is El90x1.

Notes

If multiple adapters are installed, you must select the proper one. Be careful to note differences between letters and numerals. In this example, the second character is a letter l (el), and not a number 1 (one).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

C3

Appendix C BACnet Over Ethernet Considerations

BACnet PC Notes

Windows 2000 or XP Pro


In Windows 2000 or XP Pro (Professional), the Ethernet device adapter name is a long character string in hexadecimal format. Apart from appearing in the Windows registry, this string is not found with normal system utilities, such as the Windows Device Manger. However, Niagara includes a special utility that you can use to find and copy this string.
Procedure C-4 Determining Ethernet adapter device name in Windows 2000/XP Pro.

Step 1 Step 2 Step 3

Stop any station running on the PC. Open a Niagara Console window. Type showAdapters, and press ENTER. This utility displays both physical and virtual network adapters (Figure C-2).
Figure C-2 Both physical and virtual adapters appear in the showAdapters utility.

Physical adapters have a manufacturer name and model number. Typically, the first adapter listed is a physical adapter.

The adapter device name is the entire character string between quotes (" ").

Step 4

Select the physical adapter that will be used for BACnet over Ethernet communicationsuse the windows scroll bar if necessary. In most cases, the first adapter listed will be a physical adapter (have an associated manufacturer and model number). If multiple physical adapters exist, you will need to select the one to be connected to the BACnet network.

Step 5

Highlight the adapter names value, by dragging the mouse over all characters shown between the quotation marks (" "), as shown in Figure C-3.

C4

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix C

BACnet PC Notes BACnet Over Ethernet Considerations

Figure C-3

Highlight the adapter name, right-click the title bar, and select Edit > Copy.

Step 6

With this string highlighted, right-click on the title bar and select Edit > Copy. The adapter name string is now copied to the Windows clipboard. Close the Niagara Console, and follow the next procedure, Edit drivers.properties

Step 7

Edit drivers.properties
After finding the Ethernet adapter device name, verify that the Niagara build has the proper entry in the niagara\<release>\nre\lib\drivers.properties file.
Procedure C-5 Editing the drivers.properties file.

Step 1 Step 2

Using Notepad, open the drivers.properties file. Edit (or add, if missing) the Ethernet device name line with the proper adapter name. The proper syntax is:
ethernet.deviceName=\\Device\\<Ethernet device adapter name>

For example, if a Windows NT system, this line might look like:


ethernet.deviceName=\\Device\\El90x1

If a Windows 2000 /XP Pro system, this line might look like:
ethernet.deviceName=\\Device\\{B2996882-D086-4532-B6F5-D82A950570AA}

Note

If a Windows 2000/XP Pro system, use CNTRL-V to paste the adapter name string immediately behind the leading ethernet.deviceName= portion.

Step 3

Save and close the drivers.properties file.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

C5

Appendix C BACnet Over Ethernet Considerations

BACnet PC Notes

C6

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

APPENDIX

Niagara bacnetx Modules


This appendix explains the Niagara BACnet extension (bacnetx) modules, which are located in the tridiumx/bacnetx folder of the Local Library.
Figure D-1 Extensions to Niagara BACnet are in the bacnetx folder of tridiumx.

About bacnetx Modules


The bacnetx folder contains extension modules that provide special-purpose functions not required by most BACnet integrations. This allows development of future modules independent of the core bacnet module (similar to the modules in the londevices folder and the core lonworks module). No additional license requirements exist for bacnetx modulesthe license.properties file must contain just the standard bacnet feature. Currently, the bacnetx folder contains only two modules, each as separate JARs: ndio (bacxNdio)Used to expose Ndio objects in a JACE-4 directly as BACnet objects (BACnet server operation). notifier (bacxNotifier)Provides special BinaryValue shadow objects for monitoring Notifier panels (BACnet client operation).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

D1

Appendix D ndio (bacxNdio)

Niagara bacnetx Modules

ndio (bacxNdio)
This module applies only to a JACE-4 controller with integral I/O, when you need to expose I/O points (Ndio objects) directly as BACnet objects. To use this feature, you must install both the bacnet and the bacxNdio module in the JACE-4 (in addition to the ndio module). The bacxNdio module is relatively small: approximately 12Kb, versus 475Kb for bacnet. A BACnet Supervisor (or Web Supervisor) also requires a bacxNdio module. This NT version of the bacxNdio module is approximately 22Kb.

Notes

Using the bacxNdio Module


Apart from the following steps, the bacxNdio module requires no configuration.
Procedure D-1 Using the bacxNdio module.

Step 1

Using the Admin Tool, install the bacxNdio module in any JACE-4 in which the bacnet module is also installed. After the JACE-4 reboots and its station is restarted, open the station in the JDE and expand its services folder (to verify the BACnetNdioService does not already exist). In the JDE, open the Local Library, and use the Tree View to expand the ndio JAR under the tridiumx/bacnetx folder. Right-click on the BACnetNdioService and select Copy. Paste the BACnetNdioService into the JACE-4 stations services folder. Save the JACE-4 station database (Backup SNS) and then reboot the JACE-4. After the host reboots and the station is restarted, you can expose Ndio objects directly as BACnet objects, using each objects Config property foreignAddress. Ndio primitive objects closely resemble standard Niagara control objects in linkable properties, Config properties, commands, and behavior. Table D-1 lists the different Ndio object types, and what BACnet object types they expose as (server operation).
Table D-1 Ndio objects types expose as certain BACnet objects.

Step 2

Step 3

Step 4 Step 5 Step 6

Ndio source object


Ndio0to10VInput, NdioHighSpeedCounterInput, NdioResistiveInput, NdioThermistorType3Input

Exposed as BACnet object type Niagara Std. Equivalent


Analog_Input AnalogInput (AI)

Analog_Output Ndio0to10VOutput1, Ndio0to20MAOutput1 (future use) NdioBinaryInput NdioBinaryOutput


1.

AnalogOutput (AO) BinaryInput (BI) BinaryOutput (BO)

Binary_Input Binary_Output

AnalogOutput type Ndio objects only available in JACE I/O Expansion Modules.

D2

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix D

Niagara bacnetx Modules notifier (bacxNotifier)

Note

Assign unique foreignAddress numbers among all Ndio objects within any group of standard Niagara equivalent object types. For example, Ndio0to10Vinput, NdioHighSpeedCounterInput, NdioResistiveInput, and NdioThermistorType3Input objects all count as AnalogInput objectseach requires a unique foreignAddress. Refer to Instance Number Rules, page 4-4, for more information.

notifier (bacxNotifier)
This module applies to any BACnet job that includes Notifier fire system panels. It includes a special BinaryValue shadow object that provides Event_State polling. The bacxNotifier module became available in Niagara Release 2.2 and later. To use this feature, you must install both the bacnet and the bacxNotifier module. The bacxNotifier module is very small (13.2Kb or less).

Notes

The NotifierBinaryValue object is the sum total of the bacxNotifier module. It works with the standard Niagara BACnet service (BACnetWSService if BACnet Supervisor, or BACnetService if JACE controller). The learnDevice command does not automatically create NotifierBinaryValue objects for a Notifier panelyou will need to add these objects manually.

Note

Using the bacxNotifier Module


To use the bacxNotifier module, follow Procedure D-2.
Procedure D-2 Using the bacxNdio module.

Step 1

Using the Admin Tool, install the bacxNotifier module in any Niagara host in which the bacnet module is also installed. After the station is restarted, open it in the JDE. Use the Tree View to expand the notifier JAR under the tridiumx/bacnetx folder. Expand the objects container to reveal the NotifierBinaryValue object. Copy and paste, as needed, NotifierBinaryValue objects from the Local Library into appropriate containers under a BACnetDevice object (representing a Notifier panel). Refer to Adding a Child Object, page 2-16, for details on manually adding objects.

Step 2 Step 3

Step 4

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

D3

Appendix D notifier (bacxNotifier)

Niagara bacnetx Modules

NotifierBinaryValue
The NotifierBinaryValue object is nearly identical to the BACnetBinaryValueLite object, but with an additional eventState output that displays the current BACnet Event_State (alarm status) value (Figure D-2). Unlike with a normal BACnetBinaryValue object, the BACnet Poll Scheduler continuously polls the value of the target objects Event_State property, in addition to the normal Present_Value and Status_Flags properties.
Figure D-2 NotifierBinaryValue object has both a statusOutput and an eventState output.
Present_Value, Status_Flags and Event_State are continuously polled. NotifierBinaryValue object

BACnetBinaryValueLite (normal) object. Event_State can be fetched or uploaded, but is not polled.

The eventState output value appears in text using the Niagara EventStateEnum descriptors, as either:

normal fault offnormal high_limit low_limit unknown

This output can be linked to a GxText object for display in a GxPage, or fed into a Program object for other control logic purposes. The bacxNotifier module was originally developed before Niagara client support for BACnet multistate objects. It is possible that a Notifier panel can be better integrated using these standard objects (BACnetMultistateValue, BACnetMultistateInput, etc.) than using by using the bacxNotifier module. If integrating a Notifier panel, you should investigate the makeup of its BACnet objects to get a better understanding of how to engineer the best solution. For details on internal properties of a NotifierBinaryValue object, refer to the BACnetBinaryValue, page 3-43, ignoring any that are not in Lite objects.

Notes

D4

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

APPENDIX

Internetworks and BACnet/IP


The BACnet standard defines an internetwork as a set of two or more (BACnet) networks connected by (BACnet) routers. This appendix explains topics relating to BACnet internetworks and Niagara station configuration. Also provided are BBMD-related details that apply only to a BACnet/IP network. The following main topics are discussed: BACnet Network Numbers Internetwork = BACnet Routers BACnet/IP and BBMDs Example Internetwork Diagrams

BACnet Network Numbers


In pre-2.3.4 releases, the Niagara BACnet service could be enabled for only one link layer type, either BACnet/IP or BACnet/Ethernet. Network association was implicit. The station was simply a device on its local BACnet network (by BACnet convention, network 0). The range for BACnet network numbers is 165535. However, the station could find and/or learn BACnet devices on other networks. An internal router table was built, based upon messages received from the global I-Am messages received from other devices (and routers) on remote networks. A BACnet service command let you print this router table to the stations Standard Output. Starting in Niagara r2.3.4, BACnet network awareness is explicityou must declare the network number for any link-layer tab that you enable in the BACnet service. If a station has multiple BACnet link-layers (tabs) enabled (for example, both BACnetIP and BACnetEthernet), a unique network number is required for each. The station automatically performs router functions between these networks. If installing a Niagara station on an existing BACnet internetwork (one or more BACnet routers already exist), you need to know all assigned network numbers, and enter them (as appropriate) on any enabled link-layer tab in the BACnet service. Find the existing network number information in the configuration setup of routers.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

E1

Appendix E Internetwork = BACnet Routers

Internetworks and BACnet/IP

Internetwork = BACnet Routers


The Niagara BACnet service now provides a view of the router table, which lists all external BACnet routers known to the station. Included is the ability to modify, add, or remove entries representing BACnet routers. Refer to Router Table, page 6-5. Typically, you should not need to edit this table, which is automatically populated when you perform a Who-Is or learnNetwork command from the BACnetUtility. Internetwork Rules BACnet Router Functions

Internetwork Rules
When implementing a BACnet internetwork there are several rules that must be followed:
1.

Rule: There must be only one message path between any two BACnet devices on an internetwork. No communication loops are allowed. Example: You should not configure multiple Niagara stations on the same LAN with both BACnet/IP and BACnet/Ethernet enabled.

2.

Rule: A BACnet router must exist between two different BACnet networks (different network numbers) for BACnet messages to pass between the devices on the two networks. This applies to any link-layer type(s). Concept: A BACnet router can be a single-purpose device, or an application layer device (controller) that also includes router functionality, such as with Niagara stations r2.3.4 and higher. If the station in a Niagara host has support enabled for multiple link-layers, it automatically acts as a router between those 2 (or more) BACnet networks to which it is directly attached. For example, if BACnet/Ethernet, MS/TP1, and MS/TP2 are all enabled in a JACE station, it operates as a BACnet router between those 3 networks. If BACnet/IP, BACnet/Ethernet, and MS/TP1 are enabled, the station operates as a BACnet-to-BACnet/IP router between those 3 networks, and so forth. A Niagara station does not act as a BACnet/IP router, which is required on any internetwork with more than one BACnet/IP network.

Note

3.

Rule: Within any given internetwork, each BACnet network must have unique network number, from 1 to 65534. Concept: Each link-layer tab that is enabled in the Niagara BACnet service corresponds to a specific BACnet network.

If establishing a new BACnet internetwork, the default network numbers that appear on a stations BACnet service tabs can be used. For example, BACnet/IP = net 1, BACnet/Ethernet = net 2, and (if a JACE-4/5), MS/TP1 = net 11, MS/TP2 = net 22, and so forth.

E2

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix E

Internetworks and BACnet/IP BACnet/IP and BBMDs

4.

If adding a JACE on an existing BACnet internetwork, you must specify the established BACnet/IP network number and/or BACnet/Ethernet network number currently in use. If a JACE with one or more enabled MS/TP ports, you must also specify a previously unused network number for each MS/TP (RS-485) port. Rule: Every BACnet object, including the Device object in each BACnet device, must have a unique numeric object_identifier (within all other objects of that same object type), internetwork-wide. Valid values for this identifier range from 0 to 4194302.

Concept: BACnet devices respond to a Who-Is broadcast messge with an I-am message that includes each Device objects unique numeric object_identifier. If you receive duplicate I-am messages (multiples showing same device, by number), it means either that more than one device has been assigned that same identifier (number), or that a message loop exists.

BACnet Router Functions


A full listing of all BACnet router functions is extensivesee the BACnet specification for complete details on routers. From a general perspective, BACnet routers are required to pass BACnet messages between different BACnet networks. This applies to all directed messages as well as broadcast messages. Usually, a BACnet router is used to join networks of different media/link-layer types, for example a router with RS-485 MS/TP port(s) and an Ethernet-BACnet/IP port. For some examples, see Example Internetwork Diagrams, page E-7.

BACnet/IP and BBMDs


Starting in Niagara r2.3.4, Niagara BACnet/IP support expands with BBMD-hosting capability. If a station is configured for BBMD operation, you can review (and if necessary, modify) the broadcast distribution table common to all BBMDs on the B/IP network, as well as the foreign device table used in the Niagara station. The following sections discuss BBMD-related topics: About BBMDs Niagara BBMD Configuration Tips

About BBMDs
Use of BBMDs (BACnet broadcast management device) is the answer to a single B/IP network that needs to span across multiple IP subnets. Each IP subnet with BACnet/IP devices requires one (and only one) BBMD. An installation with BBMDs may not be an internetwork, but just have a single B/IP network.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

E3

Appendix E BACnet/IP and BBMDs

Internetworks and BACnet/IP

A BBMD may be a device operating solely as a BBMD, or more typically, include BBMD functions in addition to other application/controller duties. This is the case with a Niagara r2.3.4 station running the BACnet service with BACnet/IP enabled, and configured with property bacnetIPDeviceType set to bbmd. Refer to Configuring BACnet/IP Properties, page 6-18, for where to find these properties. The following BBMD topics are explained: Why and What a BBMD Does Foreign Device Table

Why and What a BBMD Does

A BBMD is used to support delivery of BACnet broadcast messages, such as Who-Is and Who-Has. As a rule, globally broadcast messages are inherently blocked by standard IP routers, which are used to connect separate IP subnets. Note this issue does not exist for any directed message between devices on different subnets, such as a common ReadProperty requestnot a broadcast message. The BBMD resolves this issue by acting as a broadcast manager for its subnet, working in coordination with other peer BBMDs. Each other IP subnet that contains BACnet/IP devices has one BBMD. Each BBMD stores a table with the IP address and distribution mask of all BBMDs, itself included. This is called the BBMDs BDT (broadcast distribution table), and is identical in each BBMD for that entire B/IP network. When a global broadcast message is sent, it is automatically received by all devices on its local subnet, including the BBMD. (Local devices reply as needed to the broadcast device, without BBMD involvement.) The local BBMD forwards the broadcast message to the other subnets, using one of two methods (as defined for each remote subnet): One-Hop Two-Hop

One-Hop: The BBMD sends the message using a directed broadcast, whereby the

IP router for the destination subnet broadcasts the message on its local subnet. The router must support directed broadcasts, otherwise the two-hop method must be used.
Two-Hop: The BBMD sends the message to its peer BBMD on the remote subnet, whereby that BMMD broadcasts the message on its local subnet.

Note that replies to BACnet broadcast messages do not require BBMD involvement, as these are directed messages back to the particular B/IP device that generated the message (that is, the destination IP address is specific to that one device).

Foreign Device Table

In a case of an IP subnet where only a few (or perhaps just one) B/IP device exists, a local BBMD may be considered excessive for BACnet broadcast message support. An alternative for that subnet is for each B/IP device to register as foreign device with a particular BBMD on a remote subnet. Once registered, the device is added to that BBMDs FDT (foreign device table). It then becomes that BBMDs responsibility to deliver global BACnet broadcast messages to that remote device.

E4

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix E

Internetworks and BACnet/IP BACnet/IP and BBMDs

Because this scheme is sometimes used for B/IP devices that are not permanent, it was designed with a mandatory registration lifetime feature. When any B/IP device registers as a foreign device with a BBMD, it must specify its Time-to-Live value, in seconds. It is then expected to re-register within this period, else the BBMD will remove (purge) it from its FDT. This prevents unneccesary broadcast delivery attempts to part-time participants. The FDT in any BBMD reflects the current list of its registered foreign devices, along with each devices Time-to-Live value and calculated purge time. If the Niagara station is configured as a BBMD, you can view this table on the BACnet services property sheet (BACnet/IP, Engineering tab). Refer to Foreign Device Table (FDT), page 6-21, for information on using this feature. The foreign device term implies no stigmait is purely BBMD-centric. The most expedient configuration for a Niagara station may well be as a foreign device, providing its local IP subnet has no BBMD and other B/IP devices (if any) are currently each registered as foreign device with a remote BBMD. Unlike a BBMDs broadcast distribution table, which is identical in each BBMD, the foreign device table in each BBMD is unique to that BBMD.

Notes

Niagara BBMD Configuration Tips


The following BBMD configuration tips are grouped into two categories: Existing BACnet/IP Network New BACnet IP Network

Existing BACnet/IP Network

If you have an existing BACnet/IP network that spans IP subnets, chances are that it has at least one existing BBMD. Unless the host for the Niagara station is located on that same IP subnet as an existing BBMD1, you must choose one of the following: Configure As BBMD Configure As Foreign Device

Configure As BBMD
Typically this is best if the local subnet is receiving other new B/IP devices, and/or existing B/IP devices on this subnet are not currently supported by a BBMD. You should determine if the router for the local subnet supports directed broadcasting.
Procedure E-1 Configure Niagara station as BBMD.

Step 1

On the BACnet/IP, Config tab of the BACnet services property sheet, set the property bacnetIPDeviceType to bbmd. Refer to page 6-19.

1. If the Niagara host is being installed on an IP subnet with an existing BBMD for that BACnet/IP network, you are done. Leave bacnetIPDeviceType = none.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

E5

Appendix E BACnet/IP and BBMDs

Internetworks and BACnet/IP

Step 2

For the next property, remoteBBMDAddress, enter the BACnet MAC address of any known operating BBMD for this B/IP network (on another subnet). Refer to page 6-19 for details on syntax when entering a B/IP MAC address. Click Apply at the bottom of the BACnet/IP, Config tab. Perform a whoIs command from the BACnet services BACnetUtility. On the BACnet/IP, Engineering tab of the BACnet services property sheet, examine the BDT in the top half of the property sheet. The remote BBMD you entered should appear in the BDT, as well as other BBMDs (if existing). If an entry for the host of the running Niagara station does not already appear in the BDT, add it. Refer to Broadcast Distribution Table (BDT), page 6-20, for syntax details. If the router for the local subnet supports directed broadcasting, enter the local hosts subnet mask (in hex) in the Distribution Mask field. Otherwise, if the router does not support directed broadcasting, or you are not sure, enter FF:FF:FF:FF as the Distribution Mask.

Step 3 Step 4 Step 5

Step 6

Step 7

Click Apply at the bottom to make changes effective. This should update all other BBMDs on the B/IP network with the same BDT information. Perform a whoIs command from the BACnetUtility. If the BBMD configuration was successful, you should see devices from other subnets respond.

Step 8

Configure As Foreign Device


Typically this is best when a remote subnet BBMD exists and the local subnet has only the Niagara station as a B/IP device, or if other B/IP devices on the local subnet are currently registered as foreign devices.
Procedure E-2 Configure Niagara station as foreign device.

Step 1

On the BACnet/IP, Config tab of the BACnet services property sheet, set the property bacnetIPDeviceType to foreignDevice. Refer to page 6-19. For the next property, remoteBBMDAddress, enter the BACnet MAC address of a known operating BBMD for this B/IP network (on another subnet). This is the BBMD the station will attempt to register with as a foreign device. Refer to page 6-19 for details on syntax notes when entering a B/IP MAC address. For the last property, registrationLifetime, either accept the default 900 seconds, or enter another value from 300 to 65,535 seconds. Click Apply at the bottom of the BACnet/IP, Config tab. The station attempts to register with the remote BBMD at the remoteBBMDAddress. Perform a whoIs command from the BACnetUtility. If the foreign device registration was successful, you should see devices from other subnets respond.

Step 2

Step 3

Step 4

Step 5

E6

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix E

Internetworks and BACnet/IP Example Internetwork Diagrams

New BACnet IP Network

If you are configuring the Niagara station while installing B/IP devices for a new B/IP network, there are probably no existing BBMDs. In this case, you would typically follow Procedure E-1 Configure Niagara station as BBMD. This would allow B/IP devices on remote subnets to register with the station as foreign devices. However, you would skip Step 2 to specify a remoteBBMDAddress. You would also not see any other remote BBMDs when you followed Step 5.

Example Internetwork Diagrams


Figure E-1 shows an internetwork with 2 BACnet routers and 4 BACnet networks.
Figure E-1 Four physical networks, 2 routers.

BACnet Node BACnet Router Network 2 B/Eth

A
10 Network 11 MS/TP 11 39 70 71 99

40 Network 22 MS/TP

41

68

Network 8 ARCNET

In the example above, routers A and B join together three different media and link-layer types: BACnet over Ethernet (network 2), BACnet MS/TP (networks 11 and 22), and BACnet ARCnet (network 8). Note that each BACnet node has a unique Device ID number (shown inside node). Note also that router A could actually be a JACE-4/5 licensed for MS/TP, as shown in Figure E-2.
Figure E-2 BACnet Ethernet to MS/TP router functions provided by station in JACE-4/5.

Network 2 B/Eth JACE-4/5 with two MS/TP trunks. 10 Network 11 MS/TP 11 39

8 A
70

40 71 99 Network 22 MS/TP

41

68

Network 8 ARCNET

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

E7

Appendix E Example Internetwork Diagrams

Internetworks and BACnet/IP

For an Ethernet LAN, there may be two separate BACnet networks sharing the same mediaBACnet over Ethernet and BACnet/IP, as shown in Figure E-3.
Figure E-3 Same physical Ethernet LAN, router joins two BACnet networks.

BACnet Node BACnet Router

6
Network 1 B/IP

Network 2 B/Eth

Again, note that each BACnet node has a unique Device ID number (shown inside node). Note also that this router function could actually be provided by a Niagara station, as shown in Figure E-4.
Figure E-4 BACnet Ethernet to BACnet/IP router functions provided by Niagara station.
JACE controller (or BACnet Supervisor) with both BACnetEthernet and BACnet/IP enabled.

10

6
Network 1 B/IP

Network 2 B/Eth

In this case, you must be especially careful that no other router exists between the BACnet Ethernet and BACnet/IP networksif the Niagara station detects this illegal (loop) configuration, the routing functions performed by the station are stopped. This condition is indicated on the property sheet for the BACnet service on the General, Status tab, whenever the property routingEnabled is shown as False.

E8

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix E

Internetworks and BACnet/IP Example Internetwork Diagrams

BACnet/IP

BACnet/IP networks can be more involved, with devices designated as BBMDs and foreign devices, plus standard TCP/IP (IP) routers. Note that BBMDs are used to avoid having separate B/IP networks for each subnetthis would require a BACnet/IP router to exist on each subnet (yet even more complexity). Figure E-5 shows an example internetwork that includes an Ethernet/IP backbone. The B/IP network shown spans multiple IP subnets. Use of BBMDs provides BACnet broadcast message delivery through IP routers.

Figure E-5

Internetwork that includes single B/IP network spanning multiple IP subnets, plus other BACnet networks.

BACnet Node BACnet Router IP Router BBMD BACnet Foreign Device subnet 192.168.1 Network 1 B/IP

9
subnet 192.168.5

11

10 8

Network 8 ARCNET 40 41 69

7 14

subnet 192.168.3

A
20 Network 11 MS/TP 21 39 70 71 99

15

Network 22 MS/TP

3
subnet 192.168.7

4
Network 2 B/Eth

Note that on subnet 192.168.1, there is no BBMD. Both BACnet/IP nodes on that subnet (Device IDs 7, 8) are registered as a foreign device with a remote BBMD. Note also that on the physical Ethernet segment used by subnet 192.168.7, there are both BACnet/IP devices (Device IDs 2 and 3) and BACnet over Ethernet devices (Device IDs 4, 5, and 9). Router C provides communications between these two BACnet networks. With the exception of router B (B/IP to B/ARCNET), all BACnet routing and BBMD functions can be performed by Niagara stations. On subnet 192.168.3, router A functions (B/IP to MS/TP) and BBMD functions can be performed by a JACE-4/5 with its BACnet service enabled for BACnet/IP and BACnetMSTP1 and 2. On subnet 192.168.5, BBMD functions can be performed by any Niagara station with BACnet/IP enabled. On subnet 192.168.7, router C functions (B/IP to B/Eth) and BBMD functions can be performed by any Niagara station with both BACnet/Ethernet and BACnet/IP enabled.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

E9

Appendix E Example Internetwork Diagrams

Internetworks and BACnet/IP

Figure E-6 shows an a similar internetwork with these functions provided by Niagara stations, as previously described.
Figure E-6 Similar internetwork with Niagara stations providing BBMD and routing functions.
Niagara station with B/IP enabled

BACnet Node BACnet Router IP Router BBMD BACnet Foreign Device subnet 192.168.1 Network 1 B/IP

9
subnet 192.168.5

11

10 8
Niagara station with B/Eth and B/IP enabled

Network 8 ARCNET 40 41 69

7 14

subnet 192.168.3

JACE-4/5 with two MS/TP trunks, also B/IP enabled. 20 Network 11 MS/TP 21 39

6 16 15
70 71 99 Network 22 MS/TP

subnet 192.168.7

4
Network 2 B/Eth

E10

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

APPENDIX

Niagara MS/TP Support


This appendix covers BACnet MS/TP (master-slave/token-passing) support provided in the Niagara BACnetService. BACnet MS/TP is often used in lower-cost unitary controllers and other application-specific devices. MS/TP devices are networked using the EIA-485 physical layer, where the term RS-485 is also used. The following main topics are explained ahead: Niagara MS/TP Overview Configuring for BACnet MS/TP Engineering Considerations for MS/TP

Niagara MS/TP Overview


In Niagara r2.3.4 and later, direct support for BACnet MS/TP devices is available for JACE-4 and JACE-5 series controllers1. You can attach a network of BACnet MS/TP devices to an RS-485 port on a JACE-4/5, and use the same familiar BACnet client shadow objects to represent device and application data.
Figure F-1 BACnet MS/TP support via RS-485 port on JACE-4/5.

JACE-5
HE AR TB EA T Rx D TxD Rx RS D RS PO 2 RT 32 1 TxD 232 PO /RS RT 4 2 85 DA ETH 10 ER 0 NE T LO N TA Rx D TxD

General I/O

Lighting Control Some defined number of BACnet MS/TP devices per network (see Networks and Device Limits, page F-2).

RS-485
BACnet MS/TP Field Bus

VAV Controllers

HVAC Control

1. Niagara BACnet MS/TP support is available only for embedded JACEs with the VxWorks operating system.
Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F1

Appendix F Niagara MS/TP Overview

Niagara MS/TP Support

Typically, the BACnetService in the JACE station is also enabled for BACnet/IP and/or BACnet/Ethernet. The station provides BACnet router support between the BACnet MS/TP network(s) and the Ethernet-connected BACnet network(s). The following additional overview topics apply to BACnet MS/TP in Niagara: MS/TP Boundaries Station Engineering Considerations

MS/TP Boundaries
Boundaries for BACnet MS/TP integrations in Niagara are summarized in the following sections: Licensing Networks and Device Limits

Licensing

BACnet MS/TP is a separately-licensed option on a JACE host, with a required feature entry of bacnetMSTP in the JACEs license file. Additional lines in the license file can specify other MS/TP trunk and/or device limits. The JACE also requires general BACnet licensing, however, this is typically standard for all JACEs. For further details, see Licensing for BACnet MS/TP, page F-4.

Networks and Device Limits

Each BACnet MS/TP network requires a separate JACE-4/5 RS-485 port, which can support some number1 of MS/TP BACnet devices. Both master and slave-type MS/TP devices are supported (and count) equally. If a standard JACE-403, no more than 27 BACnet devices can be shadowed in the station database. Moreover, a total of 27 networked devices (of any type) are supported. This limit applies across all possible drivers and communications ports, for example, LonWorks, Modbus, and BACnet (and BACnet MS/TP). Beyond this 27 total, operation is not assured, and technical support may become unavailable. An extended JACE-403 (and license upgrade) is also available, which removes device count limits. For more information, please contact your Niagara sales channel. Depending on the number of RS-485 ports available on a particular JACE-4/5 model, up to 4 MS/TP networks are supported. See RS-485 Port Guide, page F-12. All BACnet MS/TP devices on the same network must use the same communications baud rate, configurable in the Niagara station at either 9600, 19.2Kb, 38.4Kb, or 76.8Kb. For various performance reasons, it is recommended that all BACnet MS/TP devices on the same network also be made by the same manufacturer.

Note

1. The actual number of BACnet MS/TP devices supported per trunk depends on the devices electrical RS-485 loading characteristics, in addition to corresponding entries in the JACEs license file. See Licensing for BACnet MS/TP, page F-4, for more information.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

F2

Appendix F

Niagara MS/TP Support Configuring for BACnet MS/TP

Station Engineering Considerations


Few differences apply to engineering a Niagara station that includes BACnet MS/TP network(s), as the same BACnet client shadow objects are used. However, there are some engineering considerations listed here, and explained in detail in later sections: Maximum device limit (per MS/TP trunk) is strictly enforced by the Niagara BACnetService. If this device limit is exceeded on an MS/TP trunk, some devices cannot be monitored in the Niagara station. Similar device restrictions apply in a standard JACE-403 (27 maximum of any kind), and possibly across all BACnet link-layer types (depending on the specific installed license file). The whoIs and learnNetwork commands in the BACnetUtility can discover master MS/TP devices, but not slave MS/TP devices. By BACnet design, slave devices are not permitted to generate messages, including I-am. For any MS/TP slave device, you manually copy and paste a BACnetDevice for it, and then enter its known network number, MAC address, and Device ID number. For more details, see Working with Slave Devices, page F-18.

The JACE station uses separate polling threads for each BACnet MS/TP network, and another (combined) polling thread for BACnet/Ethernet and BACnet/IP. This isolates poll-response issues from the different link-layer types, maximizing update efficiency. Be aware, however, that performance of any MS/TP network can be greatly affected by the configuration of its devices. For related details, see Engineering Considerations for MS/TP, page F-13.

Configuring for BACnet MS/TP


Configuring a JACE-4/5 for BACnet MS/TP can be divided into two areas: Prepare the JACE Host Configure Essential MS/TP Link-Layer Properties

Prepare the JACE Host


Before a JACE-4/5 can talk to BACnet MS/TP devices, it must be specially licensed and have an entry (referencing a low-level MS/TP driver) in its drivers.properties file. Also, Niagara Release 2.3.5, including the bacnet module, must be installed. There is no separate tridiumx module (JAR file) for MS/TP BACnet. The Niagara bacnet module, and BACnetService therein, contains all required components. Licensing for BACnet MS/TP Verifying drivers.properties Installing the BACnet module

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F3

Appendix F Configuring for BACnet MS/TP

Niagara MS/TP Support

Licensing for BACnet MS/TP


Caution

Use the Admin Tool to open the JACE-4/5 host and verify the needed entries exist. From the Installation tab, select View License.
Do not attempt to edit the license file. If you make any changes to the license file, your JACE-4/5 station will not operate! Contact Tridium if you need any changes made to your license, so that you may be sent a proper license.

To allow BACnet MS/TP operation upon station startup, the license.properties file in the JACE-4/5 is checked for the following line:
features=coreRuntime;<features>;<features>;bacnet;bacnetMSTP;

where: <features> are other licensed features for the JACE. Note that the order of the features in the feature line is not important.
checked

Starting in Niagara r2.3.5 (build 2.301.508 or later), 3 additional lines are in the license.properties file, and if present, define other limits, as follows:
numberOfBACnetDevices=n

where: n is the total number of BACnet devices, across all BACnet link layers, that are supported in its station. For a standard JACE-403 this may be up to 27, or (27 - maxLonDevices). If this line is absent, there is no defined limit.
numberOfBACnetMSTPTrunk=n

where: n is the maximum number of MS/TP trunks that can be enabled on this JACE, where the maximum value is 4. If this line is absent, the default is 1.
numberOfDevicesPerMSTPTrunk=n

where: n is the maximum number of devices supported on any one MSTP trunk. If this line is absent, the software-enforced limit is 124. Physically, this limit is enforced by the electrical RS-485 loading characteristics of MS/TP devices, e.g.: 31 (full-load), 62 (half-load), and 124 (quarter-load) maximum.
Note

Niagara software limits for BACnet are specified within the hosts license only. Example F-1 shows an example portion of a JACE-512 license file, created to support a total of 300 BACnet devices, of which up to 248 can be MS/TP devices networked on 2 MS/TP trunks (RS-485 ports) on the JACE.
Example F-1 Example license portion, 2 MS/TP trunks, allowing quarter-load devices.

features=coreRuntime;<features>;<features>;bacnet;bacnetMSTP; numberOfBACnetDevices=300 numberOfBACnetMSTPTrunks=2 numberOfDevicesPerMSTPTrunk=124

In this case, for either trunk to actually support 124 devices, all installed MS/TP devices must be (electrically speaking) quarter-load devices. Otherwise, an RS-485 trunk with this number of devices would not operate correctly if there were full-load or half-load types.
Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

F4

Appendix F

Niagara MS/TP Support Configuring for BACnet MS/TP

Verifying drivers.properties
The drivers.properties file on the JACE-4/5 must include the following line:
driver.mstp=tridium.nre.vxworks.mstp.VxWorksMstpDriver

This line references the low-level driver used for Niagara BACnet MS/TP communications. This entry exists in JACE-4/5s starting around the Niagara r2.3.4 time framehowever, you should check to make sure. Use Procedure F-1 to verify this exists in the JACE-4/5s drivers.properties file.
Procedure F-1 Editing the drivers.properties file.

Step 1 Step 2

With the Admin Tool, open the JACE-4/5 host and select the Installation tab. Click Edit drivers.properties. The edit window for drivers.properties appears. Look for this line:
driver.mstp=tridium.nre.vxworks.mstp.VxWorksMstpDriver

Step 3

Step 4

If not present: a. Enter the line exactly as shown in Step 3, at the end of the file. b. From the edit windows menu bar, select File > Save. Close the edit window for drivers.properties. If you added this line, you need to reboot the JACE-4/5 for it to become effective. You may wish to do this as part of installing the bacnet module, if the JACE requires it as an addition or upgrade. If the JACE-4/5 already has the Niagara r2.3.5 release installed, including the bacnet module (and if a JACE-4 with I/O, the bacxNdio module), reboot the JACE now.

Step 5 Step 6

Installing the BACnet module

For any JACE-4 or JACE-5, you must install all needed modules. If the JACE-4/5 already has the same Niagara r2.3.5 NRE and bacnet module installed that you are using on your Web Supervisor/Niagara Engineering PC, you can skip this section. You may receive updated BACnet module files as: (for JACE-4 and JACE-5) bacnet-<release>.jar.nt (for JACE-NX, JACE-NP and Web Supervisor) You can follow this procedure to install all BACnet modules.

bacnet-<release>.jar.jace
Procedure 7 Installing the necessary Niagara modules.

Step 1

Make station backups of any existing stations to have modules installed or upgraded, saving databases to XML. For procedures, see the Niagara JDE Users Guide. On your Web Supervisor/Niagara engineering PC, copy the nt jar file to the Niagara modules subdirectory, for example, D:\niagara\<release>\nre\modules

Step 2

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F5

Appendix F Configuring for BACnet MS/TP

Niagara MS/TP Support

Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes BACnet components available to the Supervisor PC and Local Library.
Step 3 Step 4

Close and restart the JDE to load updated module(s) on your PC. On your Web Supervisor/Niagara engineering PC, copy the nt jar file (again) to the Niagara subdirectory you use to store JACE-NX/NP modules, for example,
D:\niagara\<release>\nt

Remove the .nt portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-NX or JACE-NP.
Step 5

On your Web Supervisor/Niagara engineering PC, copy the jace jar file to the Niagara subdirectory you use to store JACE-4/5 modules, for example,
D:\niagara\<release>\emb

Remove the .jace portion from its filename, so it is now bacnet-<release>.jar This makes the module available for installation on a remote JACE-4 or JACE-5.
Step 6

Using the Admin Tool, open the JACE-4/5 host and select Installation tab, Installation Wizard. In the Select Distribution Directory dialog box, select emb. Click Install. In the Niagara Remote Installation dialog box, click the radio button for Configure Modules Only. Click Next. In the Configure Modules dialog box, scroll down to find the row for the bacnet module and click in the Upgrade/Add column beside it. A red check mark appears besides bacnet module in Upgrade/Add.
Note

Step 7 Step 8 Step 9

Step 10

If installing in a JACE-4, also select (upgrade/add) the bacxNdio module. This allows Ndio objects in the JACE-4 to be exposed as BACnet objects.

Step 11 Step 12 Step 13

Click Next. In the Database Backup dialog box, select the database to be backed up. Enter a valid, administrative-level station user name and password. Click Next to continue. Click Finish.

Step 14 Step 15

In the summary dialog box, click OK to continue. A dialog box displays each task as it is performed. Typically, this process takes a couple of minutes. Step 16 When the installation is complete, click OK.

F6

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix F

Niagara MS/TP Support Configuring for BACnet MS/TP

Configure Essential MS/TP Link-Layer Properties


The BACnetService property sheet has four tabs that apply to MS/TP networks, BACnetMSTP, BACnetMSTP2, BACnetMSTP3, and BACnetMSTP4 (Figure F-2). Each MSTP tab has three sub-tabs: Status, Config, and Engineering.
Figure F-2 BACnetService property sheet, with 4 MSTP main tabs (currently apply only to JACE-4/5 station).

Four MSTP tabs. Each has three sub-tabs, Status, Config, and Engineering.

Note

When first configuring a station, you need to assign a unique device ID on the BACnet Services General, Config tab. This will be the JACE stations BACnet Device ID (identifier) across however many BACnet networks (link-layers) are enabled in the BACnet service. For BACnet/IP and BACnet/Ethernet configuration details, see the appropriate sections of this document. The following topics apply to initial BACnet MS/TP configuration:

BACnetMSTP tab Config properties Status properties Engineering property Remaining MSTP tabs RS-485 Port Guide Example MS/TP Configuration

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F7

Appendix F Configuring for BACnet MS/TP

Niagara MS/TP Support

BACnetMSTP

For BACnet MS/TP, the first tab BACnetMSTP is always used, regardless of the total number of MS/TP networks (1, 2, 3, or 4). Each BACnetMSTP(N) tabs contain Config properties for that MS/TP network (and its separate polling mechanism). Global Config Properties (BACnetMSTP tab only) Config properties (for each BACnet MS/TP network)

Global Config Properties (BACnetMSTP tab only)


The first two properties on the BACnetMSTP, Config sub-tab apply globally for Niagara communications to all JACE-connected MS/TP networks.
Figure F-3 BACnetMSTP tab, Config properties.

Global properties mstpMaxMaster and mstpMaxInfoFrames are on the first (BACnetMSTP) tabs Config sub-tab.

All other Config properties apply only to that selected MS/TP networkmstpNEnable through mstpNpollDisabled

mstpMaxMaster: Specifies the highest allowable address for master nodes on the

network. The default (and highest) value is 127. Allowable range is from 1 to 127. Visible as a property of the stations Device object. Affects token-passing operation. If master devices (apart from the JACE) are MAC-addressed contiguously starting at 1, it may be best to set this to one-higher than the highest addressed master device.
mstpMaxInfoFrames: Specifies the maximum number of messages (frames) the

station will send before it passes the token. The default (and lowest) value is 1. Allowable range is from 1 to 100. Visible as a property of the stations Device object. Polling efficiency may be increased by setting this higher, say to 10. However, anything more than 2 may not actually increase efficiency, depending on how responsive the networked devices are. Communications using default values for mstpMaxMaster and mstpMaxInfoFrames are possible, but various configurations may be optimized with different values. In addition, equivalent settings in other devices may affect operation, and there may be advantages to reviewing the MAC address scheme for all networked devices. For related information, see Engineering Considerations for MS/TP, page F-13.

Note

F8

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix F

Niagara MS/TP Support Configuring for BACnet MS/TP

Config

Remaining properties on the BACnetMSTP Config tab apply to the first MS/TP network that you are configuring. Properties on remaining MSTP tabs (2, 3, and 4) are identical except for mstp number (N), such as mstp2Enable, mstp2Address, etc. Use the remaining MSTP tabs (in order) only if you have more than one MS/TP network, otherwise leave their properties at defaultsespecially mstpNEnable.
mstpNEnable: Used to enable /disable all communications to the MS/TP network, meaning the one connected to the RS-485 port associated with mstpNCommPort.

While set to False (default), no communications are attempted. If previously used, all shadow objects in the station associated with this network show Down (yellow).
mstpNNetworkNumber: The BACnet network number associated with devices on

this MS/TP network. Default values are 11, 22, 33, and 44 for BACnetMSTPN 14. The valid range is from 1 to 65534. Must be unique among all BACnet networks on the jobs BACnet internetwork. The JACE station acts as a router between this network and other BACnet networks (from other enabled link-layers in the BACnetService, for example). Consider all default values for network numbers as random, to which you must reassign accordinglyno duplicate BACnet network numbers (across all link-layers) should exist in the entire BACnet installation!

Note

mstpNAddress: The BACnet MAC address for the JACE-4/5 station, in decimal.

Default is 0. Valid range is 0 to 127 (BACnet range for master devices). Generally, it is recommended that you leave the mstpNAddress at 0, and also verify that no other MS/TP device on this network uses this same address. If there is ever a lost token, the device with the lowest MAC address regenerates the token, which in this case would be the JACE station. Exceptions to this advice may exist, see Exception Cases, page F-16.

Note

The MAC address of most other BACnet MS/TP devices on the network is likely set by an onboard DIP switch.
mstpNCommPort: JACE software comm port number for this network. Each

associates with a particular physical RS-485 port on the JACE-4 or JACE-5. Default value is COMN, (for example, mstp3CommPort=COM3), which is often not correct. See RS-485 Port Guide, page F-12. Consider all default values as placeholders, to which you must edit to the correct COMN value. Note that a valid RS-485 port is recommendedan RS-232 port with external RS-232 to RS-485 adapter can be used, but introduces another variable for possible issues.

Note

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F9

Appendix F Configuring for BACnet MS/TP

Niagara MS/TP Support

mstpNBaudRate: Communications transmission speed for that network. Default

(all MSTP tabs) is baud_9600. Options are baud_19200, baud_38400, baud_76800. Must match comm rate of all other BACnet MS/TP devices on the network.
mstpNpollCycleTime: Target cycle time, in milliseconds, to complete one poll of

objects for that MS/TP network. Polled objects will not update any faster than this. Default is 5000 ms (5 seconds). Note that typically, a poll cycle will take much longer than thishowever, there is no harm in leaving the default value. Poll statistics for that MS/TP network (Status sub-tab) will show overruns and possibly late starts. After some run time, you may wish to adjust this upwardspossibly a value slightly greater than the mstpNaveragePollInterCycleDelay, shown on the Status tab for that MS/TP network.
mstpNpollDisplayDots: For debug mode. Default is False. If set to True, the

following characters are sent to Standard Output upon poll cycle competition. BAC MSTPN Poll (where N is 14, according to MS/TP trunk number)
mstpNpollDisabled: For debug mode. Default is False. While set to True, Niagara polling of the BACnet MS/TP network stops, and all polled values remain frozen. However, input writes and commands to client objects are still processed, devices on the network are still pinged for device status (providing deviceStatusDisabled =False), and server operations to devices are unaffected (much different than mstpNEnable).

Status

Each BACnetMSTP(N) tab has a Status sub-tab that shows current Niagara poll statistics for that MS/TP network (Figure F-4). Device and object counts also display.
Figure F-4 BACnetMSTP(N) Status tab.

The following read-only status properties are available:


mstpNpolledDeviceCount: Number of BACnetDevice objects associated with that MS/TP network. Note that even devices currently disabled for polling are included. This count is part of the total BACnet device count (bacnetDeviceCount, page 6-3). mstpNpolledObjectCount: Number of BACnet shadow objects currently in the poll list for that MS/TP network. If PollOnDemand containers are used, only objects that are currently being viewed (or that are in the view cache) are included.

F10

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix F

Niagara MS/TP Support Configuring for BACnet MS/TP

mstpNaveragePollExecuteTime: Average time, in seconds, accumulated for object

poll cycles. Equals the (mstpNtotalPollExecuteTime / mstpNtotalExecutionCycles).


Note

The BACnetServices command resetStatistics clears all accumulated count and time values to zero (0), and resets the mstpNpollStartTime. This applies to all BACnetMSTP(N) Status properties, plus equivalent main Poll, Status properties.
mstpNtotalPollExecuteTime: Total number of seconds for accumulated statistics. mstpNtotalExecutionCycles: Total number of accumulated poll cycles. mstpNpollOverruns: Accumulated number of times the poll cycle took longer than the configured mstpNpollCycleTime. Note this does not indicate a problem (all objects are polled), merely that the cycle time may be set too short. mstpNpollStartTime: Date and timestamp for the start of all accumulated statistics. mstpNaveragePollInterCycleDelay: Average time, in milliseconds, between successive starts of the poll cycle since statistics were accumulated. Provides a possible starting point for a target poll cycle time. mstpNpollLateStarts: Accumulated number of times the poll cycle has started later

than anticipated, going by the configured mstpNpollCycleTime.

Engineering

Each BACnetMSTP(N) tab has an Engineering tab with a single property:


mstpNpollDebug: For debug usage. Default is False. While set to True, each polled

object appears as a line in the stations Standard Output window, using the format:
BPxMy: polling object <objectName> {<object type>:<instance number>}

where x = MSTP trunk number (14) and y = polling thread number (01). For example:
BP1M1: polling object Space_Humidity {analog_value:102} BP1M0: polling object Microset_Room_Temp_ {analog_value:101} BP1M1: polling object Current_Heating_SP {analog_value:100} (and so on)

Note

Disable polling debug (pollDebug=False) unless you are investigating a particular poll-related problem. It adds system overhead and decreases overall throughput. BACnetService tabs BACnetMSTP2, 3, and 4 should be used only if that number of MS/TP trunks are licensed in the JACE-4/5 host. Use them in order. For example, if the JACE is licensed for 3 MS/TP trunks, use tabs BACnetMSTP, BACnetMSTP2, and BACnetMSTP3. Config properties on these remaining tabs are explained in the previous section, Config, page F-9. Properties on the Status and Engineering tabs are also explained in previous sections.

Remaining MSTP tabs

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F11

Appendix F Configuring for BACnet MS/TP

Niagara MS/TP Support

RS-485 Port Guide

Table F-1 provides a hardware-to-software port guide for RS-485 ports on various JACE-4 and JACE-5 models. Use this to set the mstpNCommPort properties.
Table F-1 Hardware-to-software COM port guide.

JACE model
401, 403

Physical Port
RS-485 3-wire (no integral modem) RS-485 3-wire (has integral modem) RS-485 3-wire Port 1

mstpnCommPort
COM2 COM1 COM3 COM4 COM5 COM6 COM2 COM3 COM4

Notes
RJ-45 is RS-232 and is COM1, not recommended for usage. RS-232 RJ-45 port is unusable.

402, 4041

RS-485 3-wire Port 2 RS-485 3-wire Port 3 RS-485 3-wire Port 4

511 512
1.

RS-485 3-wire RS-485 3-wire Port 1 RS-485 3-wire Port 2

RS-232 Port 2 is unusable.

Be aware that while four (4) BACnet MS/TP networks are possible with some JACE models, performance may be slow depending on a number of factors.

Note

Using an RS-232 port with external RS-485 adapter is possible, but not recommended. Also, MS/TP trunk license limits still count (as if RS-485).

Example MS/TP Configuration

In this example, a JACE-512 is licensed for 2 BACnet MS/TP networks. The first network contains 30 MS/TP devices all communicating at 19.2Kb, and is attached to RS-485 port 1 on the JACE-512. The second network contains 12 devices communicating at 9600 baud, and is attached to RS-485 port 2 on the JACE-512. Across both networks, all devices are master devices, with each MAC-addressed contiguously (on their respective network) starting at address 1.

Table F-2 Example BACnet MS/TP configuration for JACE-512 with 2 MS/TP networks.

BACnetMSTP Property
mstpMaxMaster mstpMaxInfoFrames mstp1Enable mstp1NetworkNumber mstp1Address mstp1CommPort mstp1BaudRate mstp1pollCycleTime mstp1pollDisplayDots mstp1pollDiabled

BACnetMSTP2 Property
mstp2Enable mstp2NetworkNumber mstp2Address mstp2CommPort mstp2BaudRate mstp2pollCycleTime mstp2pollDisplayDots mstp2pollDiabled

Value
31 10 True 3 0 COM3 baud_19200 5000 False False

Value
True 4 0 COM4 baud_9600 5000 False False

F12

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix F

Niagara MS/TP Support Engineering Considerations for MS/TP

In this particular case, BACnet network numbers 1 and 2 are already in use by other BACnet link layers, but network numbers 3 and 4 were available. After configuring the BACnetMSTP tabs above and connecting the physical trunks to the JACEs RS-485 ports, a whoIs command is given from the stations BACnetUtility. Devices from both networks respond (all are master devices). If a learnNetwork command is given, BACnetDevice objects will be created in the BACnetTemp folder that reflect the assigned network numbers and whatever Device ID instance numbers have been assigned. Figure F-5 shows an example.
Figure F-5 BACnetTemp workspace after learnNetwork with MS/TP networks.

Engineering Considerations for MS/TP


The following engineering considerations apply to BACnet MS/TP in Niagara: Token Passing and Related Operation MS/TP Network Configuration Guidelines Recommended MS/TP Learn Tips Working with Slave Devices

Token Passing and Related Operation


BACnet MS/TP uses a token-passing scheme to control network access from devices. A single token is passed among master nodes (such as a JACE station), which allows each master node to initiate one or more messages (frames). Slave nodes do not receive the token, but both master and slave nodes transmit data frames in response to requests from master nodes. A master node may initiate a frame only when it holds the token. After sending at most max_info_frames, and waiting for any expected replies, a master node passes the token to the next (higher addressed) master node.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F13

Appendix F Engineering Considerations for MS/TP

Niagara MS/TP Support

When a request that expects a reply is sent to a node, the sender waits for the returned reply before passing the token. If the responding node is a master, it may return either the reply or a reply postponed frame. The latter means the node will reply later, when it receives the token. How This Affects Operation MS/TP Network Configuration Guidelines

How This Affects Operation

Typically you want the JACE station to be configured as the lowest-addressed master node, which by default, it is (mstpNAddress = 0). You also want other master devices to be MAC-addressed contiguously starting at 1, so that the highest-addressed master device is 31 (assuming all devices on the 31-maximum network are master devices). This promotes token-passing efficiency. Also, in the JACE station, you typically want a value for the property mstpMaxMaster, to be equal to the highest addressed master device (or perhaps highest addressed device + 1, where the + 1 will permit discovery of a new master device, if added). Again, assuming a maximum network of 31 master devices, this would mean an mstpMaxMaster value of 32. Also, you would want this same Max_Master property value (32) configured in the MS/TP device that is highest addressed, in this case, the device with address 31. This way, this device would not continue polling for a master all the way up to 127 before the token is finally given to the first master (address 0), typically the JACE station. Furthermore, increasing the property value of mstpMaxInfoFrames in the JACE station is not guaranteed to increase the number of polling values received each token hold, particularly with other master devices.

Dividing Network Scenarios


In a case where an existing BACnet MS/TP network of more than 31 devices (or whatever the effective maximum) needs to be integrated into Niagara, you must divide the network into groups of 31 devices or lesseach must be a separate network under the JACE (or, if another RS-485 port is not available, another JACE). When doing this, be aware that the Config property mstpMaxMaster is global to all connected MS/TP networks under a JACE (up to 4). If possible, try to put equal (or roughly) equal amounts of master devices on each network. The value of this property should be determined by the network with the most master devices.

MS/TP Network Configuration Guidelines


This section attempts to capture some of the important considerations in configuring a BACnet MS/TP trunk for use by Niagara. The performance of Niagaras BACnet MS/TP driver can be greatly affected by the configuration of the MSTP trunk. Information is divided into two sections: Things to Check Best Practices

F14

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix F

Niagara MS/TP Support Engineering Considerations for MS/TP

Note

Poorly-configured trunks can perform orders of magnitude more slowly than well-configured trunks. In addition, poorly-configured trunks can cause the Niagara learn mechanism to fail due to behavior of devices on the trunk. If possible, you should investigate the answers to the following questions:
1.

Things to Check

Is the Max_Master property of the BACnet device(s) on the trunk configurable? Determine this by opening the property sheet of the BACnetDevice object to the Engineering tab, and changing the value of the maxMaster property. When applied, this change is written to the device. If the device accepts the write, the value will remain the same. If not, the value will revert to the previous value. Also, note that it may be necessary for you to clear the JDEs view cache before confirming thistypically 6 new JDE views (displays) are required.

2.

How many Master devices are on the network? Only master devices can initiate BACnet messages. Slave devices can only respond to requests. If an MS/TP device does not respond to a Who-Is with an I-Am, it is likely a slave device. The device vendors documentation should indicate whether it is a master or slave, or if this is configurable.

3.

How quickly does the token cycle around the devices? The best way to measure this is with an MS/TP trunk analyzer. Outside of this, (if necessary) you can roughly measure by performing the following:
a. Set the JACE stations BACnet MS/TP MAC address (mstpNAddress) to

be the highest of all devices on that trunk.


b. Disable all BACnet polling and device status ping (done through service

properties mstpNpollDisabled, pollDisabled, deviceStatusDisabled), and also disable any other BACnet writes.
c. Observe the orange/yellow and green LEDs for the JACE RS-485 port.

The green (receive) LED should be blinking almost constantly. The orange/yellow (transmit) LED should blink once per token cycle, as we pass the token on to our next peer. This should be the regular frequency. Typical token pass times are around 20ms for each device, so by multiplying the number of Master devices, you can calculate an approximate prediction for the token cycle time.

4.

How stable is the token passing on the network? Are there frequent instances of lost or duplicated tokens? Typically, this is most likely if there are different vendors devices on the same MS/TP trunk, but it can also occur with a completely homogeneous trunk. The occurrence of token-passing errors is best detected by using an MS/TP analyzer. Outside of this, a simple estimate whether things are okay can be made (again) observing JACE RS-485 port status LEDs, with the address set as before (1.a).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F15

Appendix F Engineering Considerations for MS/TP

Niagara MS/TP Support

If the token cycle is regular, the orange/yellow (transmit) LED will flash at the token cycle frequency. When there is a token-passing error, the flash pattern of the transmit LED (and possibly the receive LED) will change. With the JACE at the highest MAC address, it may go long periods without ever receiving the token, so the transmit LED might not flash for a while. This would be a strong indication that there are some type of token-passing errors.

Best Practices

In general, you should follow these practices:


1.

Whenever possible, BACnet MS/TP trunks should contain only devices from one vendor. This is simply a recommendation to reduce the likelihood of incompatibility between different vendors implementation of BACnet MS/TP. All MS/TP master devices should be MAC addressed consecutively starting at zero (0). For optimum performance, there should not be any gaps between MAC addresses, as these gap addresses will be scanned for the existence of newly added master nodes. Token problems can occur during this poll for master sequence, because devices are waiting for a full timeout for a response from a potential device, and other devices might jump in. The JACE station should be at MAC address zero (0), property mstpNAddress. This allows the JACE to be the first device to recover a lost token. In the presence of token-passing errors, it also allows the JACE to be more likely to remain in the token-passing loop during the bus-recovery process. The highest master node should have its Max_Master property set to the highest master node address possible on the network. This will be equal to that nodes MAC address. If you will be potentially adding devices to the trunk, it may be desirable to set the Max_Master property a few numbers (or one) higher than its address, to allow for easy discovery of a new device as when added. However, leaving the Max_Master set at 127 (default for most MS/TP devices) will slow token passing, as this node will periodically scan all addresses up to Max_Master for the existence of a newly added Master node.

2.

3.

4.

Exception CasesCertain exception cases may exist, where it might be better to configure the network differently. If other BACnet MS/TP devices do not allow configuration of the Max_Master property, it may be better to put the JACE station at the highest address. The JACEs Max_Master property is configurable, and can be set to its own address to truncate the scan range for new master nodes. Do this only if the token-passing is stable. If the JACE station is at the high end of the address range on an unstable trunk, it may be periodically excluded from the token passing whenever bus instabilities occur. This can cause data loss in polling, nuisance device status alarms, and can cause network and device learns to fail prematurely.

Caution

F16

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix F

Niagara MS/TP Support Engineering Considerations for MS/TP

Recommended MS/TP Learn Tips


Because BACnet MS/TP communications are typically much slower than with Ethernet-connected BACnet devices, it may be worthwhile to note the following when initially learning BACnet MS/TP devices:
1.

If learning multiple networks (to create BACnetDevice objects), it may be best to enable only one BACnetService link-layer tab at a time. This will not prevent devices on remote networks from being learned, but it will isolate only those devices on the one local network. You can then cut and paste (or move) those learned devices to another container you have specially made to group devices by network (before you start using the learnDevice command). Also, the instance limits option in a learnNetwork may also be useful to isolate devices on a particular network, providing some Device-object instance numbering scheme was used.

2.

When using the learnNetwork command, leave the Learn device contents option cleared (default). This advice generally applies to all BACnet link-layer types, but especially so for MS/TP networks. After you learn the master devices (containers) with this command, you can more selectively learn the types of child objects in each device with the learnDevice command, including instance limits to select object types and/or instance number ranges. Note that your entered limits remain effective during the JDE session, so if desired, you can learn all of the devices the same way. Be aware that slave devices cannot be discovered with learnNetwork or whoIs. See the next section Working with Slave Devices.

3.

When using the learnDevice command, the option Use lite objects is often the best choice for most BACnet MS/TP devices. Typically, these are simple devices, and objects in them are implemented without optional properties. Find out for a specific object type by manually copying a full child object in the workspace of the BACnetDevice, setting its instance number, and then performing an upload (from the property sheet of the object, select from the menu bar: Commands > upload). For example, you could do this for a BACnetBinaryInput object set to Instance Number 1. After the object upload, expand the status bar to see the Status Line History window, where you can look for Read failed...unknown property entries for alarm-related properties (or for a binary object, activeText and inactiveText).

4.

If there are identically-configured devices, you can learn the contents of one device (as needed using the learnDevice command), and then copy-and-paste the contents (Select All in the Workspace Editor) into a like learned (but still empty) device. After pasting in copied contents, issue an uploadAll command at the BACnetDevice to ensure child objects have current values. Alternatively, you can just copy and paste an entire learned BACnetDevice container. However, with this method you then need to re-enter proper device address values (only device ID Instance Number if a master device, upon applying it should receive network number and MAC address automatically).

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F17

Appendix F Engineering Considerations for MS/TP

Niagara MS/TP Support

Then for the copied BACnetDevice object, in addition to issuing an uploadAll command, you would also want to rename it.

Working with Slave Devices


BACnet MS/TP slave devices do not respond to broadcast messages such as Who-Is, therefore they cannot be discovered by the BACnetUtilitys whoIs and learnNetwork commands. You must manually add a BACnetDevice object for each slave device. When adding a BACnetDevice object for a slave, you must know three things:
1. 2. 3.

Its unique Device object identifier (Instance Number). Its network number (should correspond to the mstpnNetworkNumber). Its MAC address, in hexadecimal. (If you know its address in decimal, you can simply use the Windows calculator to convert to hex.) Device object instance number of 173. Network number 4 (example, from assignment for mstp2NetworkNumber). MAC address 162 decimal (A2 in hex).

For example, on your second MS/TP network you have a slave device as follows:

After copying a BACnetDevice object from the Local Library into your station (or a copy of another BACnetDevice object, even for a slave device previously learned), open its property sheet to the Config tab and enter these values (Figure F-6).
Figure F-6 Enter Device instance number, network number, and MAC address (in hex).

After applying these values, with this property sheet still displayed, select from the menu bar Commands > upload. This should upload other properties from the slave device, such as vendorName and modelName (Figure F-7).

F18

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

Appendix F

Niagara MS/TP Support Engineering Considerations for MS/TP

Figure F-7

Verify slave device object by seeing other Device object properties uploaded.

This verifies communication to the slave device. You can now select the device in the BACnetUtility to perform a learnDevice command, to automatically create child shadow objects in the station database.

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

F19

Appendix F Engineering Considerations for MS/TP

Niagara MS/TP Support

F20

Niagara Release 2.3.5 BACnet Integration Reference Published: April 26, 2004

INDEX

A
abbreviations, BACnet objects 3-16 Abort button, in learn 1-17, 2-2, 2-8 Acknowledged Transitions 2-14, 3-21 Alarm State 2-14 Alarms BACnet device (service type) 6-15 generating BACnet 5-1 receiving BACnet 5-7 AnalogInput shadow object 3-26 to 3-29 AnalogOutput shadow object 3-30 to 3-32 AnalogValue shadow object 3-33 to 3-34 AnalogValuePriority shadow object 3-35 to 3-37 APDU properties BACnetDevice 3-10 station 6-4 ASHRAE xii, xiv

commands 6-22 Debug properties 6-24, A-6 DeviceStatus properties 6-16 General properties 6-3 Poll properties 6-12 BACnet user (allowing write access) 4-8 BACnet workstation 1-7 bacnet.properties file 6-28 editing 6-29 read command 6-23 BACnet/Ethernet xii, 6-22 BACnet/IP xii, 1-11, 6-18 BACnetDevice object 1-18, 2-15, 3-5 to 3-14 useCOV 3-14 BACnetService commands 6-22 property sheet 6-1 to 6-27 BACnetTemp 1-18, 2-6, 2-13 BACnetUtility 1-16, 2-1 to 2-14 action buttons 2-2

B
BACnet xii BACnet client xii, 3-1 to 3-48 BACnet log objects 4-3, 4-9 to 4-12 collection time differences 4-11 BACnet MS/TP xii, F-1 to F-19 BACnet router 1-4, 1-15, 6-5 BACnet server xii, 4-1 to 4-9 BACnet service (Niagara) xii, 6-1 to 6-30 BACnet/Ethernet properties 6-22 BACnet/IP properties 6-18

getAlarmSummary command 2-13 learnDevice command 2-9 learnNetwork command 1-16, 2-6 opening 2-1 output options 2-2 status line history 2-2 whoHas command 2-5 whoIs command 2-3 bacnetx modules D-1 bacxNdio D-2 bacxNotifier D-3 BBMD xii, 1-6, 1-12, 6-19, 6-20, 6-21, E-3 to E-7

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

Index-1

Index

broadcast distribution table 6-20, E-4 configuration tips E-5 foreign device table 6-21, E-4 in network diagrams E-9, E-10 remote address 1-13, 6-19 BinaryInput shadow object 3-38 to 3-39 BinaryOutput shadow object 3-40 to 3-42 BinaryValue shadow object 3-43 to 3-44 BinaryValuePriority shadow object 3-45 to 3-47

readProperty 3-17 readPropertyMultiple 3-17 upload 3-17 BACnet service 6-22 BACnetDevice object disablePolling 3-7 downloadAll 3-7 enablePolling 3-7 fetch 3-7 getAlarmSummary 3-7 readProperty 3-7

C
cache, View 6-11 calculating poll cycle time 6-11 child objects xiii, 2-6, 3-15 to 3-24 AnalogInput 3-26 AnalogOutput 3-30 AnalogValue 3-33 AnalogValuePriority 3-35 BinaryInput 3-38 BinaryOutput 3-40 BinaryValue 3-43 BinaryValuePriority 3-45 MultistateInput 3-48 MultistateOutput 3-51 MultistateValue 3-54 MultistateValuePriority 3-56 NotifierBinaryValue D-4 writable input types 3-3 client xii clientDebugOn 6-26 color of objects and outputs A-2 commands BACnet child object download 3-17 fetch 3-17 pollRenew 3-17

readPropertyMultiple 3-7 upload 3-7 uploadAll 3-7 Common properties for child objects 3-20 Commonly Used Terms xii communications link layer C-2 troubleshooting A-1, D-3, E-9, E-10 verifying 1-13 confirmed COV 1-5 conformance, BACnet PICS B-1 COV 1-5, 3-16, 6-8, 6-10, 6-12 strategy notes 3-19 subscribing objects 3-18 cyan object color A-4 cycleTime property 6-14

D
Debug, using A-6 description property 3-20 device adapter name Windows 2000 C-4 Windows NT C-3 Device object xiii Device Status/Ping 3-23, 6-15 disablePolling command 3-7
Niagara Release 2.3.5 Published: April 26, 2004

Index-2

BACnet Integration Reference

Index

displayDots property 6-14, 6-17, A-6, F-10 download command 3-17 downloadAll command 3-7 driver.properties 1-12, C-3, C-4, C-5 drivers.properties F-5 dumpIPTable command 6-23

I-Have message 2-5 inAlarm A-3 instance limits xiii, 2-10, 2-11, 2-13 Instance number 3-5, 3-16, 4-3 internetwork xiii, 1-4, 1-7, 1-14, 2-8, 3-8, 6-18, 6-22, E-1 to
E-8

IP 1-11, C-5

E
enablePolling 1-19, 2-6, 2-15 enablePolling command 3-7 endTime property 4-11, 4-12 error messages 6-25 Ethernet link layer PC setup C-2 eventEnable property 3-22 eventState property 3-21, D-4 extensions bacxNotifier D-3 Ndio D-2 extensions, bacnetx D-1

J
JACE-4 F-1 Ndio objects D-2 JACE-5 F-1 JDE xiii

L
learnDevice 2-9 Learning a BACnet network 1-15 learnNetwork 1-16, 2-6 license A-1, D-1 for MS/TP in JACE-4/5 F-4 link layer C-2

F
fault A-3 fetch command 3-2, 3-7, 3-17 foreign device 1-12, 6-19, 6-21, E-4, E-6 foreignAddress property 4-3, 4-5, D-2 full objects xiii, 3-3

linkDebugOn 6-26, 6-27 Lite objects xiii, 2-6, 2-10, 3-3 tip for usage 3-3, F-17 Local Library 2-15, 3-4, F-18 log objects, BACnet 4-3, 4-9 to 4-12

M G
getAlarmSummary 2-13, 3-7 MAC address 1-13, 3-8, F-9, F-18 manually adding BACnet shadow objects 2-14, 3-4, F-18 MS/TP F-1 to F-19 configuration guidelines F-14

I
I-Am message 2-4
Niagara Release 2.3.5 BACnet Integration Reference

JACE preparation F-3 licensing F-4

Published: April 26, 2004

Index-3

Index

Niagara overview F-1 properties F-7 slave devices F-18 token passing F-13 mstpMaxInfoFrames property F-8, F-14 mstpMaxMaster property F-8, F-14 Multistate object notes 3-24 MultistateInput shadow object 3-48 to 3-50 MultistateOutput shadow object 3-51 to 3-53 MultistateValue shadow object 3-54 to 3-55 MultistateValuePriority shadow object 3-56 to 3-58

P
PC notes C-1 to C-5 PICS, BACnet B-1 ping mechanism 6-15 Poll Scheduler 6-9 Polling 3-2 calculating cycle time 6-11 MS/TP F-10 troubleshooting A-2 PollOnDemand 1-6, 1-8, 6-10 pollRenew command 3-17

N
name 2-5, 2-14, 4-7 Ndio 4-7, D-2 network number, about E-1 networkDebugOn 6-26 notificationClass property 3-22, 6-16 Notifier D-3 NotifierBinaryValue object D-4 notifyType property 3-22

presentValue property 3-2, 3-21 priorityArray property 3-2 property sheet, showing polled values 6-9 Protocol Implementation Conformance Statement B-1

R
readBACnetPropertiesFile command 6-23 readProperty command 3-7, 3-17 readPropertyMultiple command 3-7, 3-17 readPropertyMultipleSupported 3-10, 3-13, 3-14

O
object identifier, object ID xiii, 2-5, 2-14, 2-16 object name 2-5, 2-14, 4-7 Object status A-2 objectIdentifier property 3-21 objectName property 3-21 objectType property 3-20 on_demand_transient properties 3-2 one-hop (BBMD) E-4 orange object color A-3 outOfService 1-19, A-4 outOfService property 3-21

red object color A-3 reliability property 3-21 resetStatistics command 6-23 rewriteDelay property 3-25, 6-8 routers BACnet 1-4, 1-15, 6-5, E-2, E-7 IP (TCP/IP) E-4, E-9 routingEnabled property 6-3 RS-485 F-1 JACE port guide F-12

S
server xii

Index-4

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

Index

serverDebugOn 6-26 shadow objects xiii, 2-14, 3-1 shape information BACnet log objects 4-11 BACnet shadow (child) objects 3-16 BACnetDevice objects 3-5 slave MS/TP devices F-18 Standard Output 6-24, A-6 startTime property 4-11, 4-12 status device status/ping 6-16 of object 3-20, A-2 polling 6-13 service 6-3 statusFlags property 3-2, 3-20 SubscribeCOV 1-5, 6-12 strategy notes 3-19 subscribing objects 3-18 systemStatus 3-6, 3-8

communications A-1, D-2, E-7 debug and Standard Output A-6 object color A-2 polling A-2 two-hop (BBMD) E-4

U
UDP port 1-12, 1-13, 6-19 unsubscribing objects from COV 3-18 upload 2-15, 2-16 upload command 3-2, 3-7, 3-17 uploadAll command 3-7 UserAdmin, BACnet user 4-8 UTC 1-6, 6-8

V
verifying BACnet communications 1-13

T
table BACnet routers 6-5 broadcast distribution (BBMD) 6-20 foreign device (BBMD) 6-21 time synchronization 1-6, 6-8 timeDelay property 3-22 timeout messages 6-25 token passing, MSTP F-13 Trend Log object 4-9, 4-10 tridiumx folder 2-15, 2-16 Troubleshooting A-1 to A-7

W
Warning messages 6-24 whoHas 2-5 whoIs 2-3, 2-15, 6-7 writable input objects 3-3 write access 4-8 writePropertyEnabled 1-19, 3-10, 3-13, 3-14 writePropertyMultipleSupported 3-14

Y
yellow object color A-5

Niagara Release 2.3.5 BACnet Integration Reference

Published: April 26, 2004

Index-5

Index

Index-6

BACnet Integration Reference

Niagara Release 2.3.5 Published: April 26, 2004

You can help make this manual even better!


Please help us make our documentation as useful as possible. Use this form to advise us of errors, descriptions that are not clear, or provide any other helpful information. Mail this form to: Tridium, Inc. 3951 Westerre Parkway, Suite 350 Richmond, Virginia 23233 Attention: Tridium Documentation Team Or fax it to us at: (804) 747-5204 Or e-mail your comments to us at: [email protected] Thank you for taking the time to help us improve our documentation!

Documentation Comment Form


Document Title: Document Version:
BACnet Integration Reference Niagara Release 2.3.5

Page #

Problem Found or Suggested Change

Your Name: Your Company:

You might also like