Sie sind auf Seite 1von 436

Technical Document

NiagaraAX-3.x User Guide

May 1, 2007
NiagaraAX User Guide
Copyright © 2007 Tridium, Inc.
All rights reserved.
3951 Westerre Pkwy., Suite 350
Richmond
Virginia
23233
U.S.A.

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.
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.
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
contained herein. Information and specifications published here are current as of the date of this publication and are subject to
change without notice.
The release and technology contained herein may be protected by one or 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 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. Mozilla and Firefox are trademarks of the Mozilla Foundation. Echelon, LON,
LonMark, LonTalk, and LonWorks are registered trademarks of Echelon Corporation. Tridium, JACE, Niagara Framework,
NiagaraAX and Vykon are registered trademarks, and Workbench, WorkPlaceAX, and AXSupervisor, are trademarks of Tridium Inc.
All other product names and services mentioned in this publication that is known to be trademarks, registered trademarks, or
service marks are the property of their respective owners.The software described herein is furnished under a license agreement and
may be used only in accordance with the terms of the agreement.
CONTENTS

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Document Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

About NiagaraAX Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1


Well designed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
The Niagara Framework solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
About control systems integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
About Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3
About Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3
About common networking and Internet protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3
About programming for non-programmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3
About embedded systems capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
About distributed systems capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
About component software design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
About Niagara software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
About Baja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–5
About APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
javax.baja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
com.tridium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
About Niagara building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
About modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
About module characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7
About jar files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7
About module versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7
About module directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
About module benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
About components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–9
About slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–10
Slot type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Slot name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Slot definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
About master/slave components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–11
About point components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–11
About component naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–12
Escaped names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
About palettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–13
About presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–13
About presentation modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–13
About presentation xml (px) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–13
About presentation design philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–14
About presentation media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–14
About stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–15
About BOG files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–16
About ORDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16

NiagaraAX-3.x
i
User Guide
May 1, 2007

Examples of ORDs: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–17


About schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–17
Types of schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–17
Types of space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–18
Types of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–18
About views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19
About lexicons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19

About Workbench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1


Tour of the Workbench GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
About Workbench window controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
About the side bar panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
About side bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–3
About the side bar title bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–3
Types of side bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–3
About the bookmark side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–4
About the help side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–4
About the nav side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–5
Types of nodes in the nav side bar tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
About the nav side bar toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–7
About the palette side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–7
About the palette side bar toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
About the jobs side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
About the bound ords side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–9
About the widget tree side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–9
About the properties side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–10
About the view pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–10
About the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–11
About the menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–12
About the toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–12
About the locator bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–13
About the view selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–14
Types of popup menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–14
About the nav side bar popup menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
About the wire sheet popup menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–15
About the property sheet popup menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–15
Px Editor popup menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
Types of data–presentation controls and options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–16
Table controls and options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–17
Batch editing (or batch processing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–17
Chart controls and options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–18
Customizing the Workbench environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–19
Creating Additional Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–19
Creating tabs in the view pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–19
Types of Workbench options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–20
General Workbench options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–21
Alarm console options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–21
Alarm portal options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–22
Bajadoc options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–22
Text editor options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–22
Lexicon editor options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–23
Px editor options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–23
Wiresheet options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–24
Lexicon options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–24

Data and Control Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1


About control points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Types of control points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Other control components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
About data value categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2

NiagaraAX-3.x
ii
User Guide
May 1, 2007

About point types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2


About point Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
About point inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
About point actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
About override actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
About set (Fallback) action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Modifying default actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
About point facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
Accessing and editing facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
Facets importance for Enum points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
Effect of facets on point actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Effect of facets on proxy points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–9
About point extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–9
Extension process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–9
Types of point extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–10
About the proxy extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–10
About control extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–11
Types of control extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–11
About alarm extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–12
Types of alarm extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12
About history extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–13
Types of history extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
About control triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
How triggers are used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–15
About related objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–15
About point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–15
Types of status flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–15
Priority of status indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–16
How status flags are set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–16
Simple control point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–16
Propagate Flags status option (linked Math and Logic objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–17
Proxy point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
About “isValid” status check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–18
About proxy points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
Location of proxy points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–19
How proxy points are made . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–19
Proxy points versus simple control points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–23
ProxyExt properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–23
About writable points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
About the priority scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–24
Priority input scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
Priority linking rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–25
Priority level conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–25
About minimum On and Off times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–25
About composites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
Some composite examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–26
Point-level composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
Folder-level composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
Composite issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3–29

Driver architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1


What are networks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Where are networks located? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
About Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Network component hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
About network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
About device components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
About device extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
About the Driver Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4

NiagaraAX-3.x
iii
User Guide
May 1, 2007

Driver Manager New and Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4


New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5
Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5
Common network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5
Network status properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
About network Alarm Source Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
About Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–7
Monitor properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–7
Monitor considerations by driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
About Tuning Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
Tuning Policy properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
Tuning Policy considerations by driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–9
About poll components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–9
Poll scheduler operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
Poll component properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–11
Additional network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–11
About communication components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
About driver-specific properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
About the Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
Device New Folder and New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–13
New Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–13
All Descendants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Device Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–15
Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–15
Device “gang” edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–15
About Device Discover, Add and Match (Learn Process) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–16
About Learn toggle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–17
Add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–17
Match (Device) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–18
Manager table features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–19
Table options menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–19
Column resorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–19
Common device components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–19
Device status properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–20
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Device Alarm Source Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–20
Device address properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–21
Poll Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–21
Driver-specific device slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–21
Virtual Gateway component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–21
About virtual component spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–21
About virtual gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Types of device extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
About the Points extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–25
About the Histories extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–25
About the Retry Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–26
About the Alarms extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–26
Alarms extension properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
About the Schedules extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–27
About the Point Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–28
Points New Folder and New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–28
New Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–29
New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Point Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–30
Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Proxy point “gang” edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–31

NiagaraAX-3.x
iv
User Guide
May 1, 2007

About Point Discover, Add and Match (Learn Process) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–32


Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–35
About other Points views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–36
About Histories extension views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–37
History Import Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–37
History Import New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–38
History Import Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–38
About History Import Discover, Add and Match (Learn Process) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–39
History Export Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–41
History Export New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
History Export Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
About History Export Discover, Add and Match (Learn Process) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–43
About Schedules extension views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44
Schedule Import Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–45
Schedule Import New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–45
Schedule Import Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–45
About Schedule Import Discover, Add and Match (Learn Process) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–47
Schedule Export Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–48
About the Niagara Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–49
NiagaraNetwork component notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–50
About the Fox Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–50
About History Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–51
Niagara Station Manager notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–54
Station Learn and Discover notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–54
Station Add notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–54
NiagaraStation component notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–55
About station status properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–55
About client connection properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–55
About server connection properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–55
About station “provisioning” extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–55
About the Bql Query Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–56
About Bql Query Find filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–56
About Bql Query Match filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–57
About Bql Query Save, Load, and Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–58
Niagara proxy point notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–59
Proxy of a proxy, other candidates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–59
Link control and Niagara proxy points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–59
Station Alarms notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–60
Station Schedules import/export notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4–60
Niagara schedule import/export default configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–61
Schedule Export Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–61

Field Bus Integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1


Port and protocol variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Ethernet-connected driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Serial-connected driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Special-port driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Learn versus New devices and points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Serial tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Serial tunnel overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Client side (PC application) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3
Installing the serial tunnel client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3
To install the serial tunnel client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3
Serial tunnel client configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Serial tunnel client installation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–5
Station side (TunnelService) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–5
Configuring the serial tunnel server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–5
To configure the station for serial tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–5
About serial tunnel connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

NiagaraAX-3.x
v
User Guide
May 1, 2007

Serial tunneling usage notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–7


Tunneling client messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–7

About Histories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1


Types of History Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
About the history service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
About the history extension manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–3
About history service property sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–3
History service actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–3
About the audit history service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–3
About the log history service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–4
Types of history space views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–5
About the chart builder view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–6
About Time Zones and the Chart Builder view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
About the database maintenance view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
About the nav container view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–9
Types of history views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–9
Types of history data fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–10
About the history chart view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–10
About the history table view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–10
About the collection table view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–11
About the history summary view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–11
About the history editor view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–12
About the history process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
About delta logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–14
Add history extensions to a component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–15
Configure history extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–16
About history names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–17
Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6–18
About editing history data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–19

About alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1


Alarm examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1
Overview of the alarming process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
About alarm sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–3
About alarm extensions and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–3
About alarm extension properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–3
About alarm instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–6
About notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–6
About the alarm service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–6
About memory alarm service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–7
Common alarm controls and indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
Types of alarm service views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–9
About alarm extension manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–9
Types of extension manager display features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–10
About the Instructions Manager view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–11
About the alarm class summary view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–12
About the alarm database maintenance view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–13
About the Alarm details dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14
Types of alarm database maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14
About alarm service property sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–15
About alarm class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–15
About alarm escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–16
About alarm class properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–16
About alarm class mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–17

NiagaraAX-3.x
vi
User Guide
May 1, 2007

Types of alarm recipients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–18


About the console recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–19
About the alarm console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–19
Types of alarm details view dialog boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
About the station recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–22
About the email recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–23
About the lineprinter recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7–23

About Presentation XML (Px) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–1


About Px views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–2
Px views as slot properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–2
About the New Px View wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–3
About Px files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–3
Shared Px files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
About Px viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
About Px Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–5
About the Px Editor Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–6
View Source XML dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–6
About Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–7
Widget layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
Types of panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
Widget painting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–9
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–9
About widget properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–10
Animating Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
Data binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–10
Types of bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–11
Types of binding properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–12
About bound label bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–13
About value bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–13
Types of Converters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–13
About spectrum bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–14
About setpoint bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–14
About increment setpoint bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–15
About spectrum setpoint bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–15
About action bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–15
About table bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–15
About field editor bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–16
Relative and absolute bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–16
About Px target media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–17
About Web Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–17
Default Wb Web Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–17
Basic Wb Web Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–18
Default Hx Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–18
Basic Hx Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–19
Px Editor workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–19
About the Make Widget wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–19
Make Widget wizard: examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–21
Create a bound label widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–21
Create a widget using a palette kit module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–23
Create a widget with a Workbench view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–26
Create a widget using a component properties option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–28
Create an action widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–30
Create a Time Plot widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–32
Create a Chart widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–34
About the Nav file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–36

NiagaraAX-3.x
vii
User Guide
May 1, 2007

Nav file elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–37


About the Nav File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–38
Nav File Editor source objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–39
Nav File Editor result tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–39
Nav File Editor buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–39
About Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–40
About the reporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–40
Types of report components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–41
About the ReportService component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–41
About the ExportSource component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–41
About the EmailRecipient component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–42
About the ComponentGrid component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–42
About the ReportPane component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–43
About the SectionHeader component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–43
About the Grid Table view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–44
About the Grid Label Pane view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–44
About the Grid Editor view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–46
About the Report Edit Row and Edit Column dialog boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–46
About the ReportPx file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8–47

About Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–1


Security model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–1
Categories and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–2
Users and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–2
About built-in users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–3
About authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4
Permissions and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4
About permission levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–5
Component permission levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–5
File permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–6
History permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–7
UserService security notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–7
About user audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–7
AuditHistoryService configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–7
AuditHistory content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–7
Multi-station security notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–8
Domain-wide cookies authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–9
To configure domain-wide cookies authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–9
Alarm ack permission notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–9
UserService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–9
UserService properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9–10
UserManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9–10
User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–11
Lockout notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–12
PermissionsBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9–13
Show Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–13
Permissions abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–13
Access permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
CategoryService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–14
CategoryManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9–15
Category properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–16
Category caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–16
CategoryBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9–16
Show Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–16
CategorySheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9–17

About Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–1


About the scheduling model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–1
Schedule component categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–1
Schedule component views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–2

NiagaraAX-3.x
viii
User Guide
May 1, 2007

Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–2
Save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–2
Schedule component links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–2
Weekly schedule links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–2
Trigger schedule links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–3
Schedule special events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–3
Schedule exports and imports (master/slave) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–3
About weekly schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–3
Types of weekly schedule components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–4
About the BooleanSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
About the EnumSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
About the NumericSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
About the StringSchedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
Weekly schedule output processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–4
Out slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–4
Out Source slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–5
Next Time and Next Value slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–5
Weekly Scheduler view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–5
Weekly Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–5
Special Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–7
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–10
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–12
About calendar schedules (holidays) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–13
CalendarSchedule Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–13
Calendar Scheduler view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–13
Adding calendar events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–14
Right-click menus and other controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–15
Calendar day selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–15
Date selection notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–15
Date range selection notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–16
Week and day selection notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–16
Custom selection notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–17
CalendarSchedule slots and other notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–17
About trigger schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–18
Trigger Scheduler view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–18
Adding trigger events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–19
Adding trigger event times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–19
Right-click menus and other controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–20
TriggerSchedule slots and other notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–21
Trigger Missed slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–21
Using schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–21
Adding a schedule or calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–21
To add a component from the schedule palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–21
To copy an existing, saved (configured) schedule component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–22
Configuring schedules and calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–22
Configuring weekly schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–22
To configure a weekly schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–22
To configure a weekly schedule’s properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–22
To configure the weekly (normal) schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–22
To add and configure special events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–23
To review a weekly schedule’s configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–23
Configuring calendar schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–23
To configure a calendar schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–23
Configuring trigger schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–24
To configure a trigger schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–24
Linking schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–24
Linking weekly schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–24
To link a weekly schedule using the wire sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–24
To link a weekly schedule using the Nav tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–25
Linking trigger schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–25
To link a trigger schedule using the wire sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–25
To link a trigger schedule using the Nav tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–25
Importing schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–26
Importing NiagaraAX schedules or Bacnet Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10–26

NiagaraAX-3.x
ix
User Guide
May 1, 2007

To import a NiagaraAX schedule or BACnet Schedule or Calendar . . . . . . . . . . . . . . . . . . . . . . . . . 10–26

About Workbench tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–1


Types of Workbench Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–1
Alarm portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–2
Bacnet service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–4
Color chooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–4
Lexicon editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–5
Lexicon Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11–5
Lexicon Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11–5
Lexicon display options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11–6
Lonworks service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–6
Credentials manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–7
New driver wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–8
New module wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–8
New station wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–9
License request dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–9
Resource estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–10
Todo list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–10
Workbench job service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–11
Workbench service manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–11

Performing Workbench tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–1


Starting and exiting Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–1
To start Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–1
To close a Workbench window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–1
To exit Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2
Getting started with stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2
To open a platform using Workbench GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2
To connect to a platform using Workbench GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2
To close a platform using Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–3
To disconnect from a platform using Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–3
To start a station using Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–3
To stop a station using Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–3
To open a station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–4
To close a station using Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–4
To connect to a station using Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–4
To disconnect from a station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–5
Using the side bar pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–5
To open the side bar pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–5
To open the bookmarks side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–5
To open the help side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–5
To open the nav side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To open the palette side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To close a side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To close the side bar pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To vertically resize a side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To restore a side bar to a previous size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To maximize a side bar: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
Using bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To add a bookmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6
To manage bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–7
To edit a bookmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–7
To remove a bookmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–7

NiagaraAX-3.x
x
User Guide
May 1, 2007

Using the help side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–7


To search for topics in the help side bar: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–7
Using the nav side bar (tree) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–8
To refresh a nav side bar tree node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–8
To Go Into a nav side bar tree node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–8
Using the jobs side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–8
To view job details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9
To cancel a job from the jobs side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9
To dismiss a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9
Using the palette side bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9
To open a palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9
To close a palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9
To create a palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–10
To add a new component to a palette (PaletteFile.palette) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–10
To add a new component to a palette (module.palette) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–10
To copy a component to a palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–11
Using the view pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–11
Editing components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–11
Selecting a component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–11
To select a component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–12
To select multiple components in the nav tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–12
To select a multiple components in the wire sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–12
Viewing a component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–12
To select a component view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–12
To reorder components (in a component container) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–12
To create a composite view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–13
Working with components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–13
To add a new component (property sheet, nav side bar, or wire sheet view) . . . . . . . . . . . . . . . . . . 12–14
To delete a component (property sheet, nav side bar, or wire sheet view) . . . . . . . . . . . . . . . . . . . . . 12–14
To rename a component (property sheet, nav side bar, or wire sheet view, slot sheet) . . . . . . . . . . 12–14
To duplicate a component (property sheet, nav side bar, or wire sheet view) . . . . . . . . . . . . . . . . . . 12–14
To paste a component (property sheet, nav side bar, or wire sheet view) . . . . . . . . . . . . . . . . . . . . . 12–15
To drag a component to the property sheet, nav side bar, or wire sheet (left–click method) . . . . . 12–15
To drag a component to the property sheet, nav side bar, or wire sheet (right–click method) . . . 12–15
Editing component data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–15
Using the property sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–16
To add an extension to a component property sheet view: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–16
To add a component facet: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–16
To remove a component facet: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–16
Using the wire sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–16
To pin a slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–17
To paste a component onto the wire sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–17
To drag a component to the wire sheet (left–click method) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–17
To drag a component to the wire sheet (right–click method) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–17
Using the slot sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–18
To add a new slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–18
To delete a slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–18
Using the link sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–18
To delete a link using the link sheet view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–18
To edit a link using the link sheet view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–18
Using alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–19
Creating alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–19
To set up alarm conditions for a control point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–19
Routing alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–19
To add an alarm class to the alarm service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–19
To add a console recipient to the alarm service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–19
To add a station recipient to the alarm service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–20
To add an email recipient to the alarm service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–20
Managing alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–20
To acknowledge alarms from the alarm console view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–20
To acknowledge alarms from the alarm portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–21
To delete alarm records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–22
Using the Px Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–22

NiagaraAX-3.x
xi
User Guide
May 1, 2007

Making widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–22


To make a new widget using the Make New Widget wizard: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–22
Binding widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–22
To bind a value to a widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–23
Editing widget properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–23
To edit a widget property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–23
Animating widget properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–23
To animate a widget property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–23
Using the Nav File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–24
Creating a new Nav file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–24
To create a new nav file: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–24
To delete nav file (Delete Key): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–24
To delete nav file (popup menu): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–24
To rename a nav file: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–24
Editing a Nav file in the Nav File Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–25
To open a nav file in the Nav File Editor: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–25
To add nodes to a nav file using the Nav File Editor: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–25
To delete nodes from a nav file: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–25
To edit the node hierarchy (tree structure) in a nav file: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–26
To edit nodes in a nav file: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–26
Working with modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–26
To create a new module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–26

Component Guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–1


Component Reference Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–1
Components in alarm module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–1
Components in backup module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–4
Components in baja module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–5
Components in bajaui module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–9
Components in chart module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–12
Components in control module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–12
Components in converters module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–14
Components in crypto module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–14
Components in devkit module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–14
Components in driver module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–14
Components in email module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–18
Components in file module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–19
Components in fox module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–21
Components in gx module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–21
Components in help module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–21
Components in history module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–21
Components in kitPx module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–24
Components in ldap module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–26
Components in net module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–26
Components in niagaraDriver module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–27
Components in program module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–28
Components in pxeditor module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–28
Components in rdb module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–29
Components in rdbDb2 module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–29
Components in rdbOracle module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–29

NiagaraAX-3.x
xii
User Guide
May 1, 2007

Components in rdbSqlServer module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–29


Components in report module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–29
Components in schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–30
Components in serial module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–31
Components in timesync module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–31
Components in tunnel module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–32
Components in web module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–33
Components in workbench module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–33

Plugin Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14–35


Types of plugin modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–35
Plugins in alarm module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–35
Plugins in backup module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–37
Plugins in chart module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–37
Plugins in devkit module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–38
Plugins in driver module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–39
Plugins in email module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–40
Plugins in help module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–40
Plugins in history module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–41
Plugins in html module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–42
Plugins in ldap module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–46
Plugins in niagaraDriver module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–46
Plugins in program module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–47
Plugins in pxEditor module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–49
Plugins in raster module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–49
Plugins in rdb module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–49
Plugins in report module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–50
Plugins in schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–50
Plugins in timesync module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–51
Plugins in wiresheet module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–51
Plugins in wbutil module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–53
Plugins in workbench module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–54

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–1
In this appendix (introduction) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–1
About keyboard shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–1
Types of menu bar items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–2
About the File menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–2
About the Edit menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–4
About the Search menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–5
About the Bookmarks menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–6
About the Tools menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–6
About the Window menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–6
About the Px Editor menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–7
About the History Ext Manager menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–8
About the Help menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–8

NiagaraAX-3.x
xiii
User Guide
May 1, 2007

Types of popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–8


About the nav side bar popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–9
About the wire sheet popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–9
About the property sheet popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–10
About the Px Editor popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–10
About the history extension manager popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–11
About the Todo list popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–11
About the point manager popup menu items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–11
Types of edit commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–12
Types of toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–13
Standard toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–13
Slot Sheet toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–14
Px Editor toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–14
About the history extension manager toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–14
About the history editor toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–15
About the Todo list toolbar icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–15
Types of console commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–15
Niagara shell commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–16
nre (station) commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–16
wb (Workbench) commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–17
plat (platform) commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–17
SVG Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–18

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B–1

NiagaraAX-3.x
xiv
User Guide
CONTENTS

Preface
Document Change Log

Document Change Log


Updates (changes/additions) to this NiagaraAX User Guide document are listed below.
• Updated: May 1, 2007
Edited “About Workbench” to add new information throughout to reflect user interface changes that
are the result of NiagaraAX-3.1 and AX-3.2 enhancements.
Edited “Driver architecture” to add sections about NiagaraAX-3.2 virtual points feature, including
“About virtual gateways”, “About virtual component spaces”, and others.
Edited “About Histories” to add coverage of new History charting features (Hx view charting, Time
Zone handling improvements, zoom feature improvements) and other enhancements provided in
NiagaraAX-3.1 and AX-3.2.
Edited “About alarms” to add sections describing NiagaraAX-3.2 feature, Alarm Escalation (“About
alarm escalation”). Added section on Alarm Instructions (“About the Instructions Manager view”).
Added section “About Reporting” in “About Presentation XML (Px)” to describe the Reporting fea-
ture available in NiagaraAX-3.2. Added information regarding enhanced charting capabilities.
Edited “About Security” to add section “Alarm ack permission notes”.
Edited “About Scheduling”—made minor changes, corrections, and updates.
Edited “Performing Workbench tasks” to correct one alarm database maintenance procedure and
make editorial corrections.
Edited “Component Guides” to add component descriptions for VirtualComponent, VirtualGate-
way (new baja components with the NiagaraAX-3.2 virtual points feature). Also added component
descriptions for ComponentGrid, EmailRecipient, ExportSource, ReportPane, ReportService, and
SectionHeader, (components in the NiagaraAX-3.2 report module).
Edited “Plugin Guides” to add coverage of views related to the report component and the alarm In-
structions Manager: GridTable, GridLabelPane, ComponentGridEditor, AlarmExtManager.
• Updated: January 19, 2007
Applied “new look” formatting to print (PDF) version of this document, reducing total page count
yet adding “sidehead” white space to most pages (useful for note taking on printed pages).
Edited “Plugin Guides” chapter to provide more consistent section overviews (useful for navigation
in both html and pdf output) and a content summary of “Types of plugins” at beginning of chapter.
• Revised: August 1, 2006
Various new components and views added in the “Component Guides” and “Plugin Guides” sec-
tions, mostly related to the driver module containing the FileNetwork. Other minor edits and notes
related to NiagaraNetwork provisioning (see “NiagaraStation component notes”).
• Revised: April 4, 2006
Minor typographical fixes only.
• Revised: December 7, 2005
Added new sections in “Field Bus Integrations” section: “Port and protocol variations” on page 5-1
and “Serial tunneling” on page 5-2. Added component descriptions for SerialHelper, TunnelService,
SerialTunnel, and TunnelConnection in “Component Guides”.
Reversed order of this change log to put newest changes at top.
• Revised: October 31, 2005
Removed obsolete references to Raster Editor in “Component Guides”, and “Plugin Guides”.
Added procedures in “Performing Workbench tasks” sections “Using the palette side bar” (to create
and edit palettes) and “Working with modules” (to create a module).

NiagaraAX-3.x
xv
User Guide
May 1, 2007

Edited section “New module wizard” in the “About Workbench tools” section.
Edited description of property “Time Delay” in the “About alarm extension properties” section to
note this property does not apply to status transitions to (or from) Fault.
• Revised: September 28, 2005
Edited graphics and callouts to standardize resolution, size, & layout in “About NiagaraAX Frame-
work”, “About Workbench”.
Edited links in “Component Guides” and “Glossary”
Added information about the Jobs palette to “About Workbench” and to “References”.
Edited “About the Window menu” and “About the locator bar”sections.
Added section “About the point manager popup menu items”.
• Revised: September 15, 2005
Edited and corrected broken links to online help, including links in “About Workbench tools”,
“About Security”, and “Component Guides”.
• Revised: August 31, 2005
Edited, added content, and renamed sections in “About Workbench tools”.
Added “Batch editing (or batch processing)” section.
Added “About the Todo list popup menu items” section to “Types of popup menu items”.
Added “About the Todo list toolbar icons” section to “Types of toolbar icons”.
• Revised: August 23, 2005
Added “Types of files” section to the “About ORDs” section.
Edited and added content to “About Workbench tools” section.
Added new procedures to “Using the palette side bar” section.
Added content to sections in the “Customizing the Workbench environment” section.
• Revised: August 17, 2005
Added new sections to “Customizing the Workbench environment”.
Edited and added sections to “About Workbench tools”.
• Revised: August 3, 2005
Added new sections: “About schemes”, “Types of schemes”, “Table controls and options”, “Chart
controls and options”, “About the History Ext Manager menu”, “About the history extension manag-
er popup menu items”, “About the history extension manager toolbar icons”, “Niagara shell com-
mands”, “nre (station) commands”, “wb (Workbench) commands”, “plat (platform) commands”.
Edited sections “About alarms” and “About Histories” to replace redundant text with references to
single description location. Added or corrected missing or incorrect property descriptions. Edited
“Plugin Guides”, “Component Guides”, “References” to augment references, correct missing or in-
accurate descriptions and update links.
• Revised: July 13, 2005
Added section “About delta logging” and edited section “Add history extensions to a component”.
• Published: June 24 2005
Added Copyright and Trademarks section to preface. Made minor changes in the “Component
Guides” and “Plugin Guides” sections, especially for the BackupService and BackupManager.
• Draft: June 15 2005
Added components to and edited some components in the following sections: “Components in kitPx
module”.
• Draft: June 8 2005
Added components to and edited some components in the following sections: “Components in
alarm module”, “Components in baja module”, “Components in bajaui module”, “Components in
history module”.
• Draft: June 6 2005
Provided more details about using the alarm class mapper in “About alarm class mapping”. Updated
alarm console and alarm portal screens in “Types of Workbench options” section. Added, removed
and updated information in the “Components in alarm module” section.
• Draft: June 1 2005
“Data and Control Model” section had various minor changes after a technical review, including
many updated screen captures. The section “Types of status flags” on page 3-15 shows default status
colors, in addition to describing them.
“Types of alarm service views” section edited to add property sheet view–in order to include descrip-
tion of “capacity” property. “About alarm class mapping” section added. Updated “About the alarm
database maintenance view” section updated to reflect new database editing option. Corrected de-
scription of “capacity in “About the history summary view” section.
• Draft: May 25, 2005 (Initial change log)
“Data and Control Model” section “About point actions” on page 3-3 was expanded to cover the re-
cent “set” (Fallback) action for writable points, including new sections “About override actions”,

NiagaraAX-3.x
xvi
User Guide
Chapter 3 –
May 1, 2007

“About set (Fallback) action”, and “Modifying default actions”. Various minor changes were also
made in other Data and Control Model sections.
“About alarms” section was reorganized and updated. Additional information added in the following
sections: About alarm extension properties, About alarm extension manager, About the alarm data-
base maintenance view, About the lineprinter recipient. The About memory alarm service section
was added. Various minor changes were also made in other About alarms sections.

NiagaraAX-3.x
3-xvii
User Guide
Chapter 3 –
May 1, 2007

NiagaraAX-3.x
3-xviii
User Guide
CHAPTER 1
About NiagaraAX Framework
Software frameworks provide a platform to allow businesses to more easily build their end-product
offerings. Tridium’s patented Niagara Framework® is targeted at solving the challenges associated with
managing diverse smart devices, unifying their data, and connecting them to enterprise applications.
Examples of smart devices include: monitoring and control systems, sensors, metering systems, and
embedded controls on packaged equipment systems.
framework, n. something composed of parts fitted together and united; a structural frame; a basic
structure (as of ideas); in object-oriented programming, a reusable basic design structure, consisting of
abstract and concrete classes, that assists in building applications.
Niagara Framework, n. a universal software infrastructure that allows companies to build custom, web-
enabled applications for accessing, automating, and controlling smart devices in real time over the
Internet.
NiagaraAX is the third generation of Tridium's Niagara Framework. This Java–based software
framework provides an infrastructure to enable systems integrators and developers to build device–to–
enterprise solutions, and Internet–enabled control and monitoring products. The Framework integrates
diverse systems and devices (regardless of manufacturer or communication protocol) into a unified
platform that can be easily managed in real time over the Internet (or intranet) using a standard web
browser. The Framework also includes a comprehensive toolset that enables non-programmers to build
rich applications in a drag-and-drop environment.
NiagaraAX is fully scalable, meaning that it can be run on platforms spanning the range from small,
embedded devices to enterprise class servers. Niagara is being successfully applied in energy–services,
building–automation, industrial–automation and M2M applications today.

Well designed
The Niagara Framework addresses the challenges of automation, control and device to enterprise
connectivity of real time systems. NiagaraAX, and its derivative products, offer compelling value to both
end users and partners. For OEM and reseller partners, the Niagara Framework solves several key
challenges present in all control-related industries:
• High development costs associated with the foundation or infrastructure layer of software that com-
municates with devices and manipulates the data from them.
• The need to transform information from real-time control processes into a homogeneous structure
enabling advanced product and service applications.
• Integration of legacy systems to enable companies to easily migrate their existing customers to new
technologies and product offerings.
Partners who adopt the Niagara Framework as their infrastructure eliminate substantial engineering
effort and are able to focus on their core competencies of application development and marketing. These
companies gain competitive advantage in their markets from lower development costs and quicker time-
to-market for their specific products, applications and value-add services.
End users of Niagara benefit from:
• Being able to preserve existing investments in control and monitoring devices as they move to new,
standards-based technologies.
• Being able to access and control all of their diverse systems through a standard web browser.
• Combining information from different systems to support better overall management of their enter-
prise assets.
• Being able to specify interoperable systems and applications from multiple vendors, thereby reduc-

NiagaraAX-3.x
1–1
User Guide
The Niagara Framework solution Chapter 1 – About NiagaraAX Framework
About control systems integration May 1, 2007

ing the potential for vendor lock-in.


Niagara is designed to address the following specific technical challenges:
• Platform independence - NiagaraAX works with a wide variety of operating systems and hardware
platforms.
Unification of diverse systems - NiagaraAX integrates heterogeneous systems, protocols, and field-
buses into normalized components.
Distributed architecture - NiagaraAX supports a highly distributed architecture. It successfully
combines Internet/IT technology with the services necessary to implement real-time, peer-to-peer
automation applications.
• Programming for non-programmers - NiagaraAX provides an environment and comprehensive
toolset to enable domain experts to create sophisticated applications without writing code.
• Extensibility - NiagaraAX provides an extensible component model and rich library of open APIs to
enable programmers to extend and enhance the Framework and build their own unique applications
and products
• Support for embedded systems - NiagaraAX can be embedded in small low cost devices

The Niagara Framework solution


The following section describes how the Niagara framework addresses these challenges:
• About control systems integration
• About Java
• About common networking and Internet protocols
• About programming for non-programmers
• About embedded systems capabilities
• About distributed systems capabilities
• About component software design

About control systems integration


Using the Niagara Framework, control systems integration means:
1. connecting devices on a common communications media
2. modeling those devices in software
3. programming applications to use the information in those devices
Before a device, such as a chiller, VAV box, or temperature sensor, can be used, information from those
devices must be pulled into the Niagara software.
Niagara then models those devices and their data types in software through the common object model.
This usually entails simplifying the device’s data types to make them easier to manipulate and control
through the software.
The Niagara common object model is then used to build applications, with the goal being to provide non-
programmers a means to program the system easily without developing raw code. The Niagara common
object model is similar to a programming language in that there are a few key concepts that are used, but
the real power is in the reusable libraries of applications and collections of objects that are available. Once
you understand the key concepts and you can put them to work, you can use Niagara objects to build
control system solutions quickly and efficiently.
The Niagara common object model, shown in Figure 1-1, allows the Niagara Framework to:
• provide two-way communication between devices and the Internet
• send real-time device information across the Internet
• control devices in real-time across the Internet.

NiagaraAX-3.x
1-2
User Guide
Chapter 1 – About NiagaraAX Framework The Niagara Framework solution
May 1, 2007 About Java

Figure 1-1 Niagara common object model

About Java
All of the Niagara software is written in Java, which means that it is platform independent. Prior to Java,
most software was written and compiled for a particular machine or operating system. If that software
needs to run on some other processor, the program has to be compiled again. Java, on the other hand,
compiles once. NiagaraAX software runs on embedded JACE controllers using the QNX operating
system and the IBM J9 Java Virtual Machine (JVM), and runs on Microsoft Windows desktop operating
system platforms, as well as Linux and Solaris using the HotSpot JVM.
About Virtual Machines
It is possible to compile code once and run it on any platform due to a layer of software that exists between
the machine and the software called the Java virtual machine (JVM). The Niagara framework uses the Java
VM as a common runtime environment across various operating systems and hardware platforms. The
core framework scales from small embedded controllers to high end servers. The framework runtime is
targeted for J2ME compliant VMs. The user interface toolkit and graphical programming tools are
targeted for J2SE 1.4 VMs.
There are a number of different virtual machines for different platforms on which the NRE is running,
but the NRE itself, and all of its modules, are the same regardless of platform. The VM is responsible for
defining how the software works with a given set of hardware-how it talks to a lonWorks adapter, how it
talks to the communications port, how it interacts with the operating system, among other tasks.

About common networking and Internet protocols


Niagara is designed from the ground up to assume that there will never be any one “standard” network
protocol, distributed architecture, or fieldbus. Niagara's design goal is to integrate cleanly with all
networks and protocols. The Niagara Framework standardizes what's inside the box, not what the box
talks to.
The Niagara software suite implements a highly efficient adaptation of the JavaBean component software
model and Internet technologies to provide true interoperability across a wide range of automation
products. The Niagara object model can be used to integrate a wide range of physical devices, controllers,
and primitive control applications including lonMark profiles, BACnet objects, and legacy control points.
The architecture supports future enhancements by allowing legacy systems to be brought forward, where
they can readily adopt new standards, solutions, and applications.
Enterprise-level software standards include Transmission Control Protocol/Internet Protocol (TCP/IP),
eXtensible Markup Language (XML), Hyper Text Transfer Protocol (HTTP), and others. These
standards provide the foundation on which to build solutions that allow information to be shared
between the control system and the enterprise information system.

About programming for non-programmers


Most features in the Niagara Framework are designed for dual use (for programmers as well as non-
programmers). These features are designed around a set of Java APIs to be accessed by developers writing
Java code. At the same time, most features are also designed to be used through high level graphical
programming and configuration tools. This vastly increases the number of users capable of building
applications on the Niagara platform.

NiagaraAX-3.x
1-3
User Guide
The Niagara Framework solution Chapter 1 – About NiagaraAX Framework
About embedded systems capabilities May 1, 2007

About embedded systems capabilities


NiagaraAX is one of the only software stacks designed to run across the entire range of processors from
small embedded devices to server class machines. Niagara is targeted for embedded systems capable of
running a Java VM. This excludes some very low-end devices that lack 32-bit processors or have only
several megabytes of RAM, but opens up a wide range of processor platforms.
To speed time to market for partners designing smart devices, Tridium has developed a reference design
processor core. Known as the Niagara Processor Module (NPM), this platform can be licensed from
Tridium and makes it possible to quickly develop NiagaraAX-based products.

About distributed systems capabilities


The framework is designed to provide scalability to highly distributed systems composed of tens of
thousands of nodes running the Niagara Framework software. Systems of this size span a wide range of
network topologies and usually communicate over unreliable Internet connections. Niagara is designed
to provide an infrastructure for managing systems of this scale.

About component software design


Niagara uses an architecture centered around the concept of “Component Oriented Development.” A
component is a piece of self-describing software that can be assembled like building blocks to create new
applications. A component–centric architecture solves many problems in Niagara:
• Data normalization
Components provide a model used to normalize the data and features of different types of protocols
and networks so that they can be integrated seamlessly.
• Graphic development tools
Applications can be assembled with components using graphical tools in the Niagara Workbench.
This allows new applications to be built without requiring a Java developer.
• Application visibility
Components provide unsurpassed visibility into applications. Since components are self-describing,
it is very easy for tools to look at how an application is assembled, configured, and to determine what
is occurring at any point in time. This provides great value in debugging and maintaining Niagara
applications.
• Software reuse
Components enable software reuse. NiagaraAX supports custom development and extension of the
framework. Niagara components are extensible and go beyond data and protocols to unify the entire
development environment.

About Niagara software architecture


There are four layers to the Niagara software architecture. The bottom layer, as shown in Figure 1-2 is the
host platform, either a JACE controller or a PC. The next layer is the Java virtual machine (JVM). The
JVM provides a layer between the hardware and its operating system and the Niagara software, known as
the Niagara run-time environment (NRE). On top of the NRE are the Niagara modules.

Figure 1-2 NiagaraAX software architecture

NiagaraAX software subsystems are illustrated in Figure 1-3 and the software processes and protocols are
shown in Figure 1-4.

NiagaraAX-3.x
1-4
User Guide
Chapter 1 – About NiagaraAX Framework About Baja
May 1, 2007 About Niagara software architecture

Figure 1-3 NiagaraAX major software subsystems

Figure 1-4 NiagaraAX software processes and protocols

About Baja
The core framework built by Tridium is designed to be published as an open standard. This standard is
being developed through Sun's Java Community Process as JSR 60. This JSR is still an ongoing effort, but
it is important to understand the distinction between Baja and Niagara.
Fundamentally Baja is an open specification and the Niagara Framework is an implementation of that
specification. As a specification, Baja is not a set of software, but rather purely a set of documentation.
The Baja specification will include:
• Standards for how Baja software modules are packaged
• XML schema for the component model;
• The component model and its APIs
• Historical database components and APIs
• Alarming components and APIs
• Control logic components and APIs
• Scheduling components and APIs
• BACnet driver components and APIs
• lonWorks driver components and APIs
Over time many more specifications for features will be added to Baja. But what is important to
remember is that Baja is only a specification. Niagara is an implementation of that specification.
Furthermore you will find a vast number of features in Niagara, that are not included under the Baja
umbrella. In this respect Niagara provides a superset of the Baja features.

NiagaraAX-3.x
1-5
User Guide
About Niagara building blocks Chapter 1 – About NiagaraAX Framework
About APIs May 1, 2007

About APIs
The API (Application Programming Interface) defines how software engineers access the capabilities of
software like the Niagara Framework. Workbench is the Niagara API — and using the Niagara
Workbench, you can create and edit the control logic for your job site.
Many features found in Niagara are exposed through a set of Java APIs. In the Java world, APIs are
grouped together into packages, which are scoped using DNS domain names. Software developed
through the Java Community Process is usually scoped by packages starting with “java” or “javax.” It is
important to understand the two types of APIs related to the Niagara framework:
• javax.baja
• com.tridium
javax.baja
The APIs developed for Baja (see “About Baja” on page 1-5 for more about Baja) are all grouped under
javax.baja. These are APIs that will be part of the open Baja specification and may be implemented by
vendors other than Tridium. Using these APIs guarantees a measure of vendor neutrality and backward
compatibility.
com.tridium
Software developed by Tridium which is proprietary and outside of the Baja specification is grouped
under the com.tridium packages. The com.tridium packages contain code specific to how Niagara imple-
ments the Baja APIs. The com.tridium code may or may not be documented. If com.tridium APIs are
publicly documented then Tridium encourages developers to use them, but does not guarantee backward
compatibility. Undocumented com.tridium APIs should never be used by developers.
Note: Tridium has developed some APIs under javax.baja even though they are not currently part of the Baja
specification. These are APIs that Tridium feels may eventually be published through Baja, but are
currently in a development stage.

About Niagara building blocks


This section describes some of the fundamental building blocks of the Niagara framework. It is important
to understand these concepts and associated terminology in order to fully benefit from the use of the
NiagaraAX Workbench. Concepts discussed in this section include the following:
• Modules
Modules are the most basic unit of software in NiagaraAX. For more details about modules, see
“About modules” on page 1-6.
• Components
Components are the primary building blocks of the NiagaraAX framework. For more details about
components, see “About components” on page 1-9.
• px
For more details about px., see “About presentation xml (px)” on page 1-13.
• stations
For more details about stations., see “About stations” on page 1-15.
• ORDs
For more details about ORDs, see “About ORDs” on page 1-16.
• Views
For more details about views, see “About views” on page 1-19.

About modules
Modules are the smallest units of software in the Niagara architecture.
Major releases of the Niagara software are distributed along with a set of release modules, but as new
modules are made available for that release of Niagara, they may be distributed as independent revisions
within that release.
Figure 1-5 shows a partial list of modules, as displayed in the nav side bar pane.

NiagaraAX-3.x
1-6
User Guide
Chapter 1 – About NiagaraAX Framework About modules
May 1, 2007 About module characteristics

Figure 1-5 Module listing in the nav side bar tree

Note: Don’t confuse modules with components. Components are used to build Niagara implementations, while
modules make up the Niagara software itself. Refer to “About components” on page 1-9 for more infor-
mation about components.
The following sections describe module characteristics and benefits.

About module characteristics


All modules:
• are composed of a single Java ARchive (JAR) file compliant with PKZIP compression
• contain an XML manifest
• are independently versioned and deployable
• state their dependencies on other modules and their versions
About jar files
JAR files are the standard mechanism for distributing Java modules. JAR stands for “Java archive.” A JAR
file (.jar) is basically a compressed package whose components can be viewed with WinZip or other
archive viewing tool. Do not attempt to unzip a JAR file—it will not work. JAR files are the add-ins that
are plugged into the software to give additional functionality. Inside the JAR file are the compressed
software; its documentation; in some cases, examples or pre-canned applications; and libraries.
Some modules, such as the lonWorks module, are distributed as multiple JAR files because there are so
many different lonWorks devices. The core protocol is packaged in a JAR file called lonWorks.jar. There
are individual JAR files for each LON device manufacturer (for example, lon_mfgName.jar). Every JAR
file or module is versioned independently.
About module versions
Niagara’s versioning system allows you to check to make sure that you have the latest available module
for your system. Versions are specified as a series of whole numbers separated by a period, for example
"1.0.42". To understand which version of a module is more recent, simply observe the module version
number. For example, 2.3.42 is later than 2.3.35 because 2.3.42 > 2.3.35.
Figure 1-6 shows modules listed, by name, with the version number and file name, as viewed in the
Workbench software manager.

Figure 1-6 Module descriptions viewed in the software manager

Niagara versioning uses the following set of conventions:


• Versions are specified using a base four-part version with optional patch versions.
• The first number specifies the specification revision. This number starts at one and is incremented
each time the specification of the module is incremented. It is used with Baja modules to track the
Baja specification version.
• The next two numbers specify a major Niagara release.
• The fourth number specifies a build number. A build number starts at zero for each major release
and increments each time all the software’s modules are built.
• Additional numbers may be specified for code changes made off a branch of a specific build. These
are usually minor changes and bug fixes.

NiagaraAX-3.x
1-7
User Guide
About modules Chapter 1 – About NiagaraAX Framework
About module benefits May 1, 2007

Every module has two versions. The first is the "bajaVersion" which maps the module to a Baja specifi-
cation version. If the module is not published under the Baja process then this value is "0". Secondly every
module declares a "vendor" name and "vendorVersion". The vendor name is a case insensitive identifier
for the company who developed the module and the vendorVersion identifies the vendor's specific
version of that module.
Tridium's vendorVersions are formatted as "major.minor.build[.patch]:
• Major and minor declare a feature release such as 3.0.
• The third number specifies a build number. A build number starts at zero for each feature release
and increments each time all the software modules are built.
• Addition numbers may be specified for code changes made off a branch of a specific build. These are
usually patch builds for minor changes and bug fixes.
So the vendorVersion "3.0.22" represents a module of build 22 in Niagara release 3.0. The vendorVersion
"3.0.45.2" is the second patch of build 45 in release 3.0.
About module directory structure
Every module is managed in its own directory structure. Figure 1-7 shows an example of a directory for
the alarm module.

Figure 1-7 Module directory structure

All of the source code that is used to build the module’s jar file is located under the "src" directory. During
the build process the "libJar" directory is used to build up the image, which will be zipped up for the
module's jar file.

About module benefits


Modular software development provides several benefits, including the following:
• Improves tracking deployment and versioning
Modular development assists in tracking the deployment and versioning of Niagara features and re-
leases. For example, if a new driver is available to be added to NiagaraAX Framework, it can be pack-
aged, delivered, and added in as a single module or with multiple modules, using the NiagaraAX
software manager, as shown in Figure 1-8. Refer to the Platform Guide section “Software Manager”
for more information about managing modules.

NiagaraAX-3.x
1-8
User Guide
Chapter 1 – About NiagaraAX Framework About components
May 1, 2007 About module benefits

Figure 1-8 Software manager view

• Requires less space on JACE


Niagara’s modular development allows you to save space on your JACE by only installing the mod-
ules that you need and choose for that JACE.
• Requires less space on the workstation
When you install NiagaraAX, you can choose the modules that you want to install with your appli-
cation and omit any modules that you do not need. Later, if want to add additional modules you can
do so with the Software Manager (as shown in Figure 1-8).
• Create new modules
Software developers can use the tools in NiagaraAX to create new modules and deploy them using
the New Module Wizard, as shown in Figure 1-9.
Refer to “New module wizard” on page 11-8 for more details about the New Module Wizard.

Figure 1-9 New module wizard

About components
A component is the primary building block that you use to engineer an application using NiagaraAX
Workbench. As described in the “About component software design” on page 1-4, components provide
many advantages for the application developer.
Components differ from modules in that components compose a Niagara implementation whereas
modules compose the Niagara software itself.
The following sections describe characteristics of components:
• About slots
• About master/slave components
• About point components

NiagaraAX-3.x
1-9
User Guide
About components Chapter 1 – About NiagaraAX Framework
About slots May 1, 2007

About slots
Niagara components are defined as a collection of “slots.” You can see all the slots that make up a
component by viewing the “slot sheet” as shown in Figure 1-10. Slots have the following types of
attributes:
• Slot type
• Slot name
• Slot definition
• Flags
• Facets

Figure 1-10 Slot sheet for a single component

Slot type
There are three types of slots:
• Property
Property slots represent a storage location of another Niagara object.
• Action
An action is a slot that specifies behavior that may be invoked either through a user command or by
an event. Actions provide the capability to provide direction to components. They may be issued
manually by the operator or automatically through links. Actions can be issued by right–clicking on
the component.
• Topic
Topics represent the subject of an event. Topics contain neither a storage location, nor a behavior.
Rather a topic serves as a place holder for a event source.
Slot name
Every slot is identified by a name that is unique within its Type. Slot names must contain ASCII letters or
numbers.
Slot definition
Slots are either frozen or dynamic. A frozen slot is defined at compile time within a Type's Java class. That
means that frozen slots are consistent across all instances of a specified Type – they don’t change.
Dynamic slots may be added, removed, renamed, and reordered during runtime – they can change. The
power of the Niagara Framework is in providing a consistent model for both frozen (compile time) slots
and dynamic (runtime) slots.
Flags
Slots have flags that allow modification of an object’s presentation or behavior. For example, “read–only”,
“operator allowed”, and “hidden”, are some of the slot flags that may be used to restrict the presentation
or behavior of an object.
Facets
Facets contain meta data – or additional data about an object. For example, “units of measurement” is a
type of facet. Facets may be viewed in the slot sheet and edited from a component property sheet, as
shown in Figure 1-11.

NiagaraAX-3.x
1-10
User Guide
Chapter 1 – About NiagaraAX Framework About components
May 1, 2007 About master/slave components

Figure 1-11 Editing facets from the property sheet

About master/slave components


Master components can be defined so that persistent properties are copied to slave components when
they are changed. This allows you to change a property in one component that automatically updates the
components that are linked to it as slaves. In this way a master component can update slave components
in all the other stations in a system.

About point components


In any NiagaraAX station, all real-time data is normalized within the station database as points, a special
group of components. Figure 1-12 shows several types of control points, as listed in the control module
palette in Workbench.

Figure 1-12 Point types

Each type of point may be used for different purposes in Workbench. When you engineer a job you may
want to name a point, as shown in Figure 1-13 (a NumericWritable point named CondSetpoint). Points
may be named and renamed but they retain their initial point type characteristics and their characteristic
icon color.

Figure 1-13 Numeric writable point named

Points serve as a type of shell in NiagaraAX, to which you may add point extensions. These extensions
allow you to select only those functions that you need and thereby limit your point properties to just those
that are necessary for your current application.

NiagaraAX-3.x
1-11
User Guide
About components Chapter 1 – About NiagaraAX Framework
About component naming May 1, 2007

Figure 1-14 Adding point extensions

For detailed information about points and point extensions, refer to “Data and Control Model” on page
3-1.

About component naming


In a NiagaraAX station, components should be properly named using the following set of rules:
• Only alphanumeric (A-Z, a-z, 0-9) and underscore (_) characters are used—spaces, hyphens, or oth-
er symbols characters (e.g: %, &, ., #, and so on) are illegal in component names. For further details,
see the next section “Escaped names”.
• The first character in the name must be a letter (not a numeral).
• Name must be unique for every component within the same parent component. Workbench auto-
matically enforces this rule, via a popup error dialog.
• Naming is case-sensitive—for example, zone21 and Zone21 are unique names.
Note: Case differences among names affect “name sorts” in table-based views, which order by ASCII
code sequence, that is capital letters (A-Z) first, lower case (a-z) following.
To convey multiple-word names without using spaces, naming “conventions” such as “CamelCase” and/
or underscores are often used, as needed. Examples of such component names are:
• Floor1 or Floor_1
• ReturnAirTemp or Return_Air_Temp
• Zone201_SAT or Zone_201_SAT

Escaped names
Workbench does allow you to name components “improperly,” such as with spaces or other non-alpha-
numeric characters, without any warning. Further, various NiagaraAX drivers have “learn” features to
automate the creation of points, some of which (by default) may also have such “improper” names—
reflective of the “native name” of the source object. For example, a BACnet proxy point might have the
default name “Zone 6 RH%” that matches the actual (native) BACnet object’s name.
In any case, be aware that the “actual” component name has all illegal characters “escaped” using a “$”
character, along with the ASCII code for that character, in hexadecimal. The proxy point mentioned
above, for example, will have the name “Zone$206RH$25”, where the $20 escapes the space and the $25
escapes the %. You can see these escaped names in the slot sheet of the component’s parent container. Or,
with the component selected, look at its ord (shortcut Ctrl + L) to see its actual name.
For the most part, this “escaped name” scheme is transparent to users. Whenever the name is displayed
to the user, say in the Nav side bar, property sheet, wire sheet, or a point manger, the component’s name
is “unescaped” by replacing the code (say, $20) with the actual ASCII character (say, a space). This way,
the user sees “Zone 6 RH%” and so on. This is the component’s “display name.”
In some cases, escaped names lead to confusion. You should avoid them if possible (rename using rules—
see “About component naming”). For example, if you add history extensions to escaped-named points,
you see those escape codes listed for source points when accessing the History Ext Manager (although
associated histories use the display names). Or, if you are building Px pages and manually typing in ords
in Px widgets, you probably know source points by “display names” only. If you manually type in an ord
without the actual (escaped) name, the widget binding fails with an error.
Note: If this sounds too complicated, remember that “drag and drop” operations resolve escaped names without
problems—for example, drag any point onto a Px page to get its proper ord.

NiagaraAX-3.x
1-12
User Guide
Chapter 1 – About NiagaraAX Framework About presentation
May 1, 2007 About palettes

About palettes
The palette provides a hierarchical view of available components. You may copy a component from the
palette and paste it where you need it — on a wire sheet, property sheet, Px View, or in the palette nav
side bar pane. For more information about using the palette side bar, refer to “About the palette side bar”
on page 2-7.

About presentation
The NiagaraAX framework provides a powerful presentation architecture based on XML and the Niagara
component model.
Presentation is a term that is used to describe how Niagara provides visualization of information across
different types of media. The terms information, visualization, and media may comprise the following:
• information
• real–time data
• historical data
• configuration data
• alarm data
• scheduling data
• graphical data
• textual data
• visualization
• bitmap and vector graphics
• text documents
• tables
• charts
• input controls (text fields, check boxes, trees)
• media
• desktop web browsers (HTML, CSS, JavaScript)
• workbench (Niagara stack)
• pdf
• printed pages
• svg
• handhelds
• cell phones

About presentation modules


Niagara’s presentation architecture is based on many modules and their associated public APIs:
• baja
The baja module defines the core component model upon which Niagara subsystems are built. This
document describes enhancements to the baja component model which will be used by the presen-
tation stack.
• gx
The gx module provides an API for drawing 2D graphics to a device. The gx module deals with draw-
ing primitives: color, strokes, gradients, vector geometries (line, rectangle, ellipse, paths), bitmap im-
ages, fonts, and transforms.
• bajaui
The bajaui module provides the widget toolkit. Widgets are the basis for graphical composition, lay-
out, user input, and data binding. The bajaui module builds upon gx to paint the widgets.
• PDF
The PDF implementation of the gx APIs.
• HTML
The HTML rendering and data binding engine.

About presentation xml (px)


An XML file format is used to define a Niagara presentation. This file format is called “px” for presen-
tation XML and the term “px” is commonly used to describe the Niagara presentation architecture.
Presentation is a term that describes how Niagara visualizes information (text, graphics, alarms, and so
on) across heterogeneous media – such as: Workbench, desktop browsers, handheld devices, and so on.
Niagara uses “presentation xml” (px) to accomplish this. Figure 1-15 shows an example of a Px file in the
Text Editor (px source file), the Px Editor view, and as displayed in the Px Viewer.

NiagaraAX-3.x
1-13
User Guide
About presentation Chapter 1 – About NiagaraAX Framework
About presentation design philosophy May 1, 2007

Figure 1-15 Px file in Text Editor, Px Editor, and Px Viewer

About presentation design philosophy


The presentation architecture is based on the following design principles:
• Component model
The core philosophy of every subsystem in Niagara is to build atop the component model. The pre-
sentation architecture is no exception. The design embraces a pure component model solution. The
component model is used for the normalized representation of presentation - the “document object
model” (DOM) of a Niagara presentation is always a BComponent tree.
• Unified visualization
Presentations include a unified approach to representing graphics, text, and input controls all within
a single component model. This allows all visualizations to share a common file format as well as a
rendering, layout, and input API.
• Unified media
The design goal of px is to build a single presentation that can be used across multiple media. For
example, given a px file, it can be automatically rendered using the workbench, as an HTML web
page, or as a PDF file. All presentations are stored in the normalized component model as px files.

About presentation media


There are four primary target medias that NiagaraAX supports.
• Workbench
The Niagara stack must be available to take full advantage of the presentation architecture. The
desktop version of Workbench provides a stand alone application that can render Niagara presenta-
tions with their full power. With the WbProfile feature, new custom applications can easily be built
using Workbench framework and its presentation engine.
• Workbench applet
Workbench applet allows the full Niagara stack to be downloaded to a client machine using a web
browser with the Java plug–in. Once loaded to the client, Workbench may be run as an applet within
an HTML page. In this scenario, the presentation engine will be available with the full feature set.
The WbProfile feature may be used to customize how Workbench is decorated inside the HTML
page.
• PDF
Adobe's PDF format is the standard way to export a presentation to be printed to paper. PDF pro-
vides explicit control for how a presentation is rendered on paper in various sizes. It is also a conve-
nient file format for access via HTTP or email. The presentation architecture includes an engine for
generating PDF files from px files.
• HTML
For the casual user where installing the Java plug–in or downloading Workbench is impractical, Nia-
gara supports an engine for generating plain HTML pages from Px. A simple set of HTML, CSS, and

NiagaraAX-3.x
1-14
User Guide
Chapter 1 – About NiagaraAX Framework About stations
May 1, 2007 About presentation media

JavaScript provide a web interface using common standards. This interface may also be used to sup-
port handheld devices and cell phones. Designers are limited to a subset of widgets when creating
HTML presentations (the Px tools provide this support).
Refer to “About Px target media” on page 8-17 for information about presentation media technologies.

Figure 1-16 Presentation media options

About stations
A station is the main unit of server processing in the Niagara architecture.
• A station database is defined by a single .bog file, for example:
"file:!stations/{name}/config.bog"
• Stations are booted from their config.bog file into a single Virtual Machine (VM), or process, on
the host machine.
• There is usually a one–to–one correspondence between stations and host machines (Supervisors or
Jaces). However it is possible to run two stations on the same machine if they are configured to use
different IP ports
A station runs the components of the Niagara Framework and provides the access for client browsers to
view and control these components. The primary parts of a station include components and services. It
is the combination of a database, a web server, and a control engine. The station either runs on a Web
Supervisor PC or a JACE controller.

Figure 1-17 Station in nav tree

A system can be a single station or multiple stations depending on the size of the project and it is defined
by a bog file.

NiagaraAX-3.x
1-15
User Guide
About ORDs Chapter 1 – About NiagaraAX Framework
About BOG files May 1, 2007

About BOG files


A bog file (baja object graph) contains Niagara components. It can be a complete database or any
collection of components. A bog file is a special file that describes the components in a database. All
views can be used on components in a bog file just as if they were in a station.

Figure 1-18 Sample bog file and nav tree presentation

About ORDs
An ORD is an "Object Resolution Descriptor". The ORD is the Niagara universal identification system
and is used throughout the Niagara framework. The ORD unifies and standardizes access to all infor-
mation. It is designed to combine different naming systems into a single string and has the advantage of
being parsable by a host of public APIs.
An ORD is comprised of one or more queries where each query has a scheme that identifies how to parse
and resolve to an object. ORDs may be displayed visually, as with the Open Ord locator or they may be
entered in a text field, as shown in the Open ORD dialog box (see Figure 1-19).

Figure 1-19 Open ORD and graphic locator system

ORDs can be relative or absolute. An absolute ORD usually takes the general format of
“host|session|space”, as illustrated in Figure 1-20.

Figure 1-20 Absolute ORD typical structure

• host
The host query identifies a machine – usually by an IP address such as "ip:hostname". For example
"fox:" indicates a fox session to the host.
• session
The session is used to identify a protocol being used to communicate with the host.
• space
The space query is used to identify a particular type of object. Common spaces are "module:", "file:",
"station:", "view:", “spy:”, or "history:".

NiagaraAX-3.x
1-16
User Guide
Chapter 1 – About NiagaraAX Framework About ORDs
May 1, 2007 About schemes

The local VM is a special case identified by "local:" which always resolves to BLocalHost.INSTANCE. The
local host is both a host and a session (since no communication protocols are required for access).
Both a slot path and a handle scheme can name components within a ComponentSpace. So the ORD for
a component usually involves both a space query and a path/handle.
Examples of ORDs:
• ip:somehost|fox:|station:|slot:/MyService
• ip:somehost|fox:|station:|h:/42
• ip:somehost|fox:|file:/C:/dir/file.txt
• local:|file:!lib/log.properties
• local:|module://icons/x16/cloud.png
• local:|spy:/
In Niagara you may view the complete list of installed ORD schemes at "spy:/sysManagers/registry-
Manager/ordSchemes" (“local:|fox:|spy:/sysManagers/registryManager/ordSchemes”).

About schemes
An ORD is a list of one or more queries separated by the "|" pipe symbol. Each query is an ASCII string
formatted as "<scheme>:<body>".

Figure 1-21 Example ORD scheme and body

• scheme
The scheme name is a globally unique identifier which specifies, in Niagara, how to find a piece of
code to lookup an object from the body string. Refer to “Types of schemes” for a listing of different
types of schemes.
• body
The body string is formatted differently, according to the requirements of the scheme. The only rule
is that it cannot contain a pipe symbol. Queries can be piped together to let each scheme focus on
how to lookup a specific type of object. In general, absolute ords are in the following format: host |
session | space (see Figure 1-20).
Some examples follow:
• ip:somehost|fox:|file:/dir/somefile.txt
In this example, the "ip" scheme is used to identify a host machine. The "fox" scheme specifies
a session to that machine usually on a specific IP port number. Finally, the “file” scheme iden-
tifies an instance of a file within the “somehost” file system.
• ip:somehost|fox:1912|station:|slot:/Graphics/Home
In this example, the "ip" scheme is used to identify a host machine using an IP address. The "fox"
scheme specifies a session to that machine usually on a specific IP port number. Finally, the “sta-
tion” and “slot” schemes identify a specific component in the station database.
• local:|module://icons/x16/cut.png
This example illustrates a special case. The scheme "local" which always resolves to BLocal-
Host.INSTANCE is both a host scheme and a session scheme. It represents objects found with-
in the local VM.

Types of schemes
• ip:
The "ip" scheme is used to identify an Ip Host instance. Ords starting with "ip" are always absolute
and ignore any base that may be specified. The body of a "ip" query is a DNS hostname or an IP ad-
dress of the format "dd.dd.dd.dd".
• fox:
The "fox" scheme is used to establish a Fox session. Fox is the primary protocol used by Niagara for
IP communication. A "fox" query is formatted as "fox:" or "fox:<port>". If port is unspecified then the
default 1911 port is assumed.
• file:
The "file" scheme is used to identify files on the file system. All file ords resolve to instances of jav-
ax.baja.file.BIFile. File queries always parse into a FilePath. File ords include the following examples:
• Authority Absolute: "//hostname/dir1/dir2"
• Local Absolute: "/dir1/dir2"
• Sys Absolute: "!lib/system.properties"

NiagaraAX-3.x
1-17
User Guide
About ORDs Chapter 1 – About NiagaraAX Framework
Types of space May 1, 2007

Sys absolute paths indicate files rooted under the Niagara installation directory identified via
Sys.getBajaHome().
• User Absolute: "^config.bog"
User absolute paths are rooted under the user home directory identified via Sys.getUser-
Home(). In the case of station VMs, user home is the directory of the station database.
• Relative: "myfile.txt"
• Relative with Backup: "../myfile.txt"
• module
The "module" scheme is used to access BIFiles inside the module jar files. The module scheme uses
the "file:" scheme's formatting where the authority name is the module name. Module queries can
be relative also. If the query is local absolute then it is assumed to be relative to the current module.
Module queries always parse into a FilePath:
• module://icons/x16/file.png
• module://baja/javax/baja/sys/BObject.bajadoc
• module:/doc/index.html
• station:
The "station" scheme is used to resolve the BComponentSpace of a station database.
• slot:
The "slot" scheme is used to resolve a BValue within a BComplex by walking down a path of slot
names. Slot queries always parse into a SlotPath.
• h:
The "h" scheme is used to resolve a BComponent by its handle. Handles are unique String identifiers
for BComponents within a BComponentSpace. Handles provide a way to persistently identify a
component independent of any renames which modify a component's slot path.
• service:
The "service" scheme is used to resolve a BComponent by its service type. The body of the query
should be a type spec.
• spy:
The "spy" scheme is used to navigate spy pages. The javax.baja.spy APIs provide a framework for
making diagnostics information easily available.
• bql:
The "bql" scheme is used to encapsulate a BQL query.

Types of space
Space defines a group of objects that share common strategies for loading, caching, lifecycle, naming, and
navigation. Following, is a list of some of the different types of space:
• station
• file
• history
• view

Types of files
In the file system, you may create and edit various types of files, as shown in Figure 1-22. Following, is a
list of some of the different types of files that reside in the file space:

Figure 1-22 Types of files available from the new file menu

• BogFile.bog
bog files are database files. Refer to “About BOG files” on page 1-16 for more information about this
type of file.
• HtmlFile.html
Html files are edited in the Text File Editor view and viewed in the Html View.

NiagaraAX-3.x
1-18
User Guide
Chapter 1 – About NiagaraAX Framework About views
May 1, 2007 Types of files

• JavaFile.java
Java files are edited in the Text File Editor view.
• PaletteFile.palette
These files are custom collections of components that you create and save for viewing in the palette
side bar. Refer to “To create a palette” on page 12-10 for information about creating custom palettes.
• PxFile.px
Px files are edited in the Px view and are used to store graphic presentations that are available for
viewing in the Px viewer and in a browser. Refer to “About presentation xml (px)” on page 1-13 for
more information about px files.
• TextFile.txt
Text files are edited and viewed in the text file editor.
• NavFile.nav
Nav files are edited in the nav file editor and viewed in the nav tree. Refer to “About the Nav file” on
page 8-36 for more information about nav files.

About views
There are many ways to visualize your system and its components. A “view” is a “visualization” of a
component. One way to view a component is directly in the side bar nav tree. In addition, you can right-
click on an item and select one of its views to display in the view pane. You can see many different views
of components. For example, a component that appears in the nav side bar tree may have a wire sheet
view, a property sheet view, and a slot sheet view, that all display in the view pane as shown in Figure 1-
23. Each component has a default view that appears whenever you activate a component (double-
clicking, for example) without specifying a particular view.

Figure 1-23 Views

See “About the view pane” on page 2-10 for more information on the view pane.
Refer to “Plugin Guides” for a comprehensive list of views.

About lexicons
NiagaraAX provides non-English language support by use of lexicons. Lexicons are identified by Java
locale codes, such as “fr” (French) or “de” (German). When installing NiagaraAX on your PC, an instal-
lation step asks you to select “language packages”—these are lexicons. Typically, you install only those
you might need, even though a “Select All” option is available.
Each lexicon is a folder that contains a collection of lexicon files (moduleName.lexicon). Lexicon files are
text files that map various entity “keys” (such as interface names or error and status values) to localized
language characters. Often, mapped characters use special encoding.
Note: Factory-supplied lexicons on a NiagaraAX installation CD typically require review and editing before they
can be used on an actual job. If needed, you can install lexicons from a NiagaraAX CD to your Workbench
PC by simply copying them from the CD’s lexicon folder into a “lexicon” directory created under your
Niagara release directory.
Lexicon files installed on your PC can be accessed and modified using a simple text editor. However, you
typically use the Workbench’s lexicon editor (Tools > Lexicon Editor). The lexicon editor not
only provides edit features, but also shows the default (English) value for each line entry.
In addition, the editor provides a “Lexicon Report” view, useful to see various statuses about a lexicon and
its contained files. For more details, see “Lexicon Editor” on page 11-5. Once reviewed and edited, you
typically install any needed lexicon into all JACE platforms. For more details, see the “Lexicon Installer”
section in the Platform Guide.

NiagaraAX-3.x
1-19
User Guide
About lexicons Chapter 1 – About NiagaraAX Framework
Types of files May 1, 2007

NiagaraAX-3.x
1-20
User Guide
CHAPTER 2
About Workbench
Workbench is the term for the NiagaraAX graphic user interface. The following sections describe the
general layout and many of the features of the Workbench user interface. Refer to the following sections
for more information:
• Tour of the Workbench GUI
• Customizing the Workbench environment

Tour of the Workbench GUI


When you start Workbench, you will see the Workbench screen, as shown in Figure 2-1.

Figure 2-1 Niagara AX Workbench

Menu Bar

Tool Bar
Locator Bar

View Selector

Side Bar Pane

View Pane

Console

The primary window of the Workbench GUI is divided into three main areas:
• Side bar pane
Top-left area displays one or more side bars that you may choose from the Windows menu. For de-
tails, see “About the side bar panes” on page 2-2.
• View pane
Top-right area displays the currently selected view. For details, see “About the view pane” on page 2-
10.
• Console
Bottom area displays a command line that allows you to issue certain commands directly to the sys-
tem. For details, see “About the console” on page 2-11.

About Workbench window controls


The Workbench window provides typical Windows-type controls plus other features unique to Niagara,
as shown in Figure 2-2.

NiagaraAX-3.x
2–1
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
About the side bar panes May 1, 2007

Figure 2-2 Windows controls


Title Bar

Scroll Bars

Border
Controls

Status Bar

You may create additional windows after starting Workbench—all have these basic features:
• Title bar
Has standard Windows title bar features, including windows name and icons to minimize, maxi-
mize, and close. Double-click the title bar to toggle between maximized and a sizable window.
• Border Controls
As needed, drag any outside border to resize the entire window. Drag the inside border between the
side bar and view areas, or (if shown) the console area to change their relative sizes.
• Scroll bars
Scroll bars appear in window areas when some content portions are not visible. They are along the
right and/or bottom portions of a window area (side bar, view, or console).
Simply drag a scroll slider (highlighted area) to scroll quickly. Or, click an ending scroll arrow to
move in small increments.
• Status bar
At the bottom left of the Workbench window is a status bar.
The status bar displays meanings of toolbar buttons. When working in a wire sheet view, other de-
tails are revealed in the status line.

About the side bar panes


Side bar panes are normally visible only if a side bar is open. When you close all side bars, the side bar
pane will collapse and the view pane and console pane (if open) will expand to fill the window. Two types
of side bar panes are:
• Primary side bar pane
The primary side bar pane is the first area on the left, below the locator bar, as shown in Figure 2-3.
• Px Editor side bar pane
This side bar pane appears on the right side of Workbench and is only available when the Px Editor
is active.

NiagaraAX-3.x
2-2
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 About side bars

Figure 2-3 Side bar pane

You use a popup menu to perform all operations that are available from inside the side bars (such as
cutting or pasting). You use the title bar to open, close, and resize the side bars.
• For more information about the side bar title bar, see “About the side bar title bar” on page 2-3.
• For more information about types of side bars see “Types of side bars” on page 2-3.

About side bars


All side bars display in the side bar pane and have some common features, such as the side bar title bar.
The following sections describe characteristics of each type of side bar:
• About the side bar title bar
• Types of side bars
About the side bar title bar
All side bars have a title bar across the top as shown in Figure 2-4. You can click and drag on the title bar
to vertically resize the side bar or you can click on a minimized side bar to restore it to the previous size.

Figure 2-4 Side bar title bar


Title

Close Minimize/Maximize

In addition, all side bars have the following controls:


• Close menu
Drop down control used to close the side bar pane.
• Pane title
Icon and text that identifies the side bar.
• Maximize button
When more than one side bar is open, this button appears on the right side of any non-maximized
side bar. Clicking on the maximize button will expand the side bar to fill the side bar pane and the
restore button will change to the maximize button.
• Restore button
If the side bar pane is at maximum size, the restore button appears on the top right corner of the title
bar. Clicking on this button will restore the side bar pane to its previous size and the maximize but-
ton will change to the restore button.
To find out more about specific side bar panes and their controls see “Types of side bars”.
Types of side bars
The following side bars may be displayed in the side bar pane:

NiagaraAX-3.x
2-3
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
About side bars May 1, 2007

• Bookmarks side bar


Displays a list of bookmarks. For details, see “About the bookmark side bar” on page 2-4.
• Help side bar
Provides a tree view of available help documentation. For details, see “About the help side bar” on
page 2-4.
• Navigator side bar
Provides a tree view of the system. For details, see “About the nav side bar” on page 2-5. For more
information about the nav side bar, see “Types of nodes in the nav side bar tree” on page 2-6, and
“About the nav side bar toolbar” on page 2-7.
• Palette side bar
Provides a tree view of components that are available in specific palettes. For details, see “About the
palette side bar” on page 2-7 and “About the palette side bar toolbar” on page 2-8.
• Jobs side bar
Provides a tree view of available components. For details, see “About the jobs side bar” on page 2-8.
• Bound ords side bar
Provides a listing of all bound ords used in a Px file. For details, see “About the bound ords side bar”
on page 2-9.
• Widget tree side bar
Provides a tree view of all widgets used in a Px file. For details, see “About the widget tree side bar”
on page 2-9.
• Properties side bar
Provides a listing of all properties for a component that is selected in the Px Editor. For details, see
“About the properties side bar” on page 2-10.
About the bookmark side bar
When you open the bookmark side bar, it appears in the side bar pane, as shown in Figure 2-5.

Figure 2-5 Bookmark side bar

From the bookmark side bar, you can double click on bookmark nodes or use popup menus to perform
all operations that are available from the side bar (for example, go directly to a bookmarked location,
manage bookmarks, edit bookmarks, and more). The quick access provided here is very helpful for
changing screens without having to go through multiple selections using other menus or submenus.
For more details about the bookmark side bar, refer to the following:
• To find out how to add or remove bookmarks in the bookmark side bar, see “To add a bookmark”
on page 12-6.
• For details about managing bookmarks, see “To manage bookmarks” on page 12-7
• For details about editing bookmarks, see “To edit a bookmark” on page 12-7
About the help side bar
When you open the help side bar, it appears in the side bar pane, as shown in Figure 2-6.

NiagaraAX-3.x
2-4
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 About side bars

Figure 2-6 Help side bar

The help side bar has three tabs that you may select by clicking on the tab. The three help tabs are listed
and briefly described, as follows:
• Table of Contents
Contains a tree view of help topics, listed in alphabetical order by topic.
• API
Contains a tree view of help topics, listed in alphabetical order by module.
• Search
Contains a Find: text entry field and Search button. For details on using the Search, see “Using
the help side bar” on page 12-7.
About the nav side bar
When you open the nav side bar, it appears in the side bar pane, as shown in Figure 2-7. The nav side bar
contains the tree view that provides a hierarchical view of the whole system. From the nav side bar, you
can double click on nodes in the nav tree or use popup menus to perform all operations that are available
from the nav side bar (for example, connect or disconnect to a station, refresh a tree node, and more).
The expandable tree provided here is very useful for performing actions on nodes and for navigating
through various screens and views in the Workbench. Items are displayed in the tree with an icon that
represents the associated function or file type.
Items are displayed in the tree with a symbol based on type. If the item is a file, it will be based on file type.
Refer to “Types of nodes in the nav side bar tree” on page 2-6 for more details about file types. Refer to
“About the nav side bar popup menu items” on page A-9 for more details about the nav side bar popup
menu.

NiagaraAX-3.x
2-5
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
About side bars May 1, 2007

Figure 2-7 Nav side bar

At the highest level, the nav side bar tree may include the following (when working from a localhost):
• My Host (local system)
• My Modules
• Platform
• Stations (connected or disconnected)
Types of nodes in the nav side bar tree
The nav side bar tree may include the following types of nodes and their child nodes:
• Host node
Represents a physical computer (hardware) that the rest of the nodes (subnodes) reside on. For more
details about how the host fits into the Niagara architecture, see “About Niagara software architec-
ture” on page 1-4.
• Module node
When expanded, displays a tree view of available modules, listed in alphabetical order by module.
For more details on modules, see “About modules” on page 1-6.
• File system node
Represents the top level of a tree view of the host file system. File system subnodes represent drives
and locations on the host system. It is important to understand that the file system provides access
to files that are outside of the station database.
• Station node
Represents a station (connected or disconnected). When expanded, the station node displays the
station contents in a hierarchical tree. For more details on stations, see “About stations” on page 1-
15.
• Platform
When expanded, displays a hierarchical view of the Niagara host platform. You can double-click on
the platform node and sub-nodes, or use a right-click shortcut menu to perform all operations that
are available on or under this node (connecting, disconnecting, refreshing, and more). For details on
the platform node and its subnodes, refer to “About a platform connection” in the Platform Guide
for more details.
• Station
When connected and expanded, displays a hierarchical view of the Niagara station. You can double-
click on the station node and sub-nodes, or use a right-click shortcut menu to perform all operations
that are available on or under this node (connecting, disconnecting, selecting views, and more). For
details on the station node, refer to “About stations” on page 1-15.
• Config node
When expanded, displays a tree view of the station contents or “configuration”.
The config node usually contains one or more of the following types of nodes:
• Component
When expanded, components (as containers) display a tree view of the sub-components that
they contain. Various component types may be displayed either in containers or at the root of

NiagaraAX-3.x
2-6
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 About side bars

the component node. For more details on components, see “About components” on page 1-9.
• Control
Control points may be displayed directly in the root of the Config node. For more information
about Control points, see “About point components” on page 1-11 and “Data and Control Mod-
el” on page 3-1.
• Drivers
Provides a place to store driver modules (such as the Niagara Network, BACnet drivers, Mod-
bus, and more). When expanded, displays a tree view of loaded driver modules. For more details
about drivers, see “Driver architecture” on page 4-1.
• Services
Component for storing services, such as alarm service, history service, program service, and
more.
About the nav side bar toolbar
In addition to the standard side bar title bar (see “About the side bar title bar” on page 2-3 for more details)
the nav side bar has a toolbar, located just below the title bar as shown in Figure 2-8.

Figure 2-8 Nav side bar tool bar

Drop-down
New Tree
selector
Close Tree

The nav side bar toolbar includes the following:


• New tree button
When clicked, creates a new tree in the nav side bar. When you have more than one tree node, you
can select one to activate from the Drop-down tree selector.
• Close tree button
When clicked, closes the currently displayed palette.
• Drop-down tree selector
When palettes are open in the palette side bar, this selector allows you to choose which palette to
display
About the palette side bar
When you open the palette side bar, it appears on the left side of the Workbench in the side bar pane, as
shown in Figure 2-9. The palette side bar provides a place to open and view sets of modules or custom
palettes that you build for yourself. From the palette side bar, you can open multiple palettes (displaying
them one at a time), close palettes and view modules within palettes. You may also double-click or use
popup menus to perform all operations that are available from the palette side bar (for example, copy
modules, select a module view, refresh the tree node, and more). The expandable tree provided in the
palette allows you to perform actions on nodes within the palette and to navigate through the palette sub-
directories. Items are displayed in the tree with an icon that represents an associated function or file type.

NiagaraAX-3.x
2-7
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
About side bars May 1, 2007

Figure 2-9 Palette side bar

For more details about the palette side bar, refer to the following:
• To find out how to use the palette side bar, see “Using the palette side bar” on page 12-9.
• For details about adding palettes to the palette side bar, see “To open a palette” on page 12-
9
About the palette side bar toolbar
In addition to the standard side bar title bar (see “About the side bar title bar” on page 2-3 for more details)
the palette side bar has a toolbar, located just below the title bar as shown in Figure 2-10.

Figure 2-10 Palette side bar tool bar

Open Drop-down
Palette palette selector

Close
Palette

The palette toolbar includes the following:


• Open palette button
When clicked, opens the Open Palette dialog box. Refer to “To open a palette” on page 12-9 for
information about opening palettes.
• Close palette button
When clicked, closes the currently displayed palette.
• Drop-down palette selector
When palettes are open in the palette side bar, this selector allows you to choose which palette to
display.
About the jobs side bar
The Jobs side bar shows all the current jobs in all the stations with which you have a connection. The
current status of each job is shown as: running, canceling, canceled, success, or failed. If the job is running
then a progress bar displays estimated progress. You may cancel a running job by pressing the Cancel
button. Normally, once a job has completed you are notified via the async notification feature. You may
then dismiss the job by pressing the Close button. The details of the job may be accessed using the ">>"
button to display the Job Log dialog box. For details about using the job side bar, refer to “Using the
jobs side bar” on page 12-8.

NiagaraAX-3.x
2-8
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 About side bars

Figure 2-11 Jobs side bar

Dismiss Job

Cancel Job
Job Job
Type Status

Job Job View


Status Progress Job
Icon Bar Log

About the bound ords side bar


The bound ords side bar, in Figure 2-12, is available when the Px editor view is active. It displays a listing
of all the bound ords in the current Px view. Double click on any ORD in the list to display the ORD in
the ORD editor dialog box.

Figure 2-12 Bound ords side bar

About the widget tree side bar


The widget tree, in Figure 2-13, displays a tree hierarchy of the widgets (panes, labels, graphic elements,
and so on) that are in the current Px view.

NiagaraAX-3.x
2-9
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
About the view pane May 1, 2007

Figure 2-13 Widget tree side bar

Note: It is often easier to use the Widget Tree to select objects when you have a lot of objects on a view–especially
when there are several layers of objects. When you select an object in the tree view it is selected in the Px
view as well and displays the selection borders and handles.
About the properties side bar
The properties side bar, shown in Figure 2-14, is available when the Px editor view is active. It displays a
listing of all the properties that are in the currently selected object in the Px view. Double click on any
object in the widget tree or in the in the Px viewer to display the properties dialog box (same infor-
mation as the properties side bar).

Figure 2-14 Properties side bar

About the view pane


The View pane is the largest window area and is located on the right side, below the locator bar, as shown
in Figure 2-15. Features of the view pane include tabbed views and a thumbnail view.

NiagaraAX-3.x
2-10
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 About the console

Figure 2-15 View pane

Multiple tabbed views may be added to the view pane by using the tab feature. You can add, close, and
select tabs in the view window. The view area displays the currently selected view for the active tab. You
can change the selected view by doing any of the following:
• double-click on an item in the nav palette tree
• select a view or action from the nav palette popup menu
• select a command from a menu or submenu
• select a command from the locator bar
• select a view from the view selector or from the view popup menu
The thumbnail view, when active, appears in the top right corner of the window to help you find your way
around the wire sheet. For more details about the thumbnail view, refer to “Show Thumbnail” on page
14-52.
For more details about using tabs, refer to “Creating tabs in the view pane” on page 2-19.

About the console


The console, see Figure 2-16, is located along the bottom of the Workbench interface and may be alter-
natively hidden or shown by selecting Window > Hide Console or Window > Console from the
menu bar.

Figure 2-16 Niagara AX console

The console has scroll bars on the right side and the window size may be adjusted by dragging the top
border bar. The console provides you with access to a command line prompt without leaving the
Workbench environment. From the console you may type in commands directly, including the help
command for additional help. The following lines are some console level commands, parameters, and
options:

NiagaraAX-3.x
2-11
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
About the menu bar May 1, 2007

>wb -help

usage:
wb [options] <ord>
parameters:
ord initial ord to display
options:
-profile:<type> workbench:WbProfile to use
-locale:<x> set the default locale (en_US)
-@<option> pass option to Java VM

About the menu bar


The menu bar is the row of pulldown menus located along the very top of the Workbench GUI, as shown
in Figure 2-17. You may use these menus to perform operations throughout the Workbench GUI. Many
of the menus on the menu bar are context-sensitive and only appear when certain views are active.

Figure 2-17 Menu bar

For detailed information about the menus, refer to “Types of menu bar items” on page A-2.

About the toolbar


The toolbar is the row of icons, just below the menu bar, as shown in Figure 2-18. The toolbar provides
menu choices for objects that appear in the view pane. Usually, toolbar icons provide single–click access
to many of the most commonly used features of the Workbench.

NiagaraAX-3.x
2-12
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 About the locator bar

Figure 2-18 Toolbar

In addition to the primary (always visible) toolbar, additional sets of toolbar icons are added to the toolbar
when different views are active. For example, when the wiresheet view is active, the Delete Links icon
is available. When an icon is dimmed, it is unavailable. For more information about specific toolbar icons,
refer to “Types of toolbar icons” on page A-13.

About the locator bar


The locator bar is the area just below the toolbar that spans horizontally from the left edge of the
Workbench GUI all the way to the right side, including the view selector on the right side, as shown in
Figure 2-19. The part of the locator bar that shows your current path (not including the view selector) is
referred to as the PathBar.

Figure 2-19 Locator bar

The purpose of the locator bar is to provide a graphical navigation field for selecting and displaying desti-
nation references. The locator serves two functions.
• First, it is automatically updated each time a new view is selected - so that it shows you the Ord of
each view.
• Second, since the Ord is displayed in a graphical row of icons, you may click on any icon along that
Ord or any child node from the Ord graphical dropdown menu.
Find the Open Ord command by selecting File > Open from the menu bar.

NiagaraAX-3.x
2-13
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
About the view selector May 1, 2007

About the view selector


The view selector appears on the right side of the locator bar, just below the tool bar, as shown in Figure 2-
20.

Figure 2-20 View selector

The view selector provides a context sensitive menu with commands that allow you to quickly display
different views of the information that is currently in the view pane. The commands in the view selector
differ, depending on the current view pane contents. For example, the view selector commands that are
available when you are viewing the platform in the view pane are different from the commands that are
available when you are displaying the driver manager view.

Types of popup menus


Workbench provides view–specific, or context–specific commands for editing components in many of
the views. Following, is a list of the standard Workbench popup (right–click) menus.
• Nav side bar
For an overview of the popup menus in the nav side bar, refer to “About the nav side bar popup
menus” on page 2-14.
For an overview of the nav side bar, refer to “About the nav side bar” on page 2-5.
• Wire sheet
For an overview of the popup menus in the wire sheet, refer to “About the wire sheet popup menu”
on page 2-15.
• Property sheet
For an overview of the popup menus in the property sheet, refer to “About the property sheet popup
menu” on page 2-15.
For descriptions of the property sheet popup menu items, refer to “About the property sheet popup
menu items” on page A-10.
• Px Editor
For an overview of the popup menus in the Px Editor, refer to “Px Editor popup menu” on page 2-16.
About the nav side bar popup menus
The nav side bar menu is the popup menu that displays command options when you right–click on a
component item in the nav side bar. The nav side bar popup menu is context-sensitive and displays items
that relate to the object that is currently selected. For example, the popup menu for a station is different
from a popup menu for a folder or a point. Figure 2-21 shows a popup menu for a selected node in the
nav side bar.

NiagaraAX-3.x
2-14
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 Types of popup menus

Figure 2-21 Nav side bar popup menu

If you right-click in a blank area of the pane (not selecting any items any the tree), the nav side bar pane
will display the Refresh Tree Node and Sync Tree commands. For descriptions of nav side bar
popup menu items, refer to “About the nav side bar popup menu items” on page A-9.
About the wire sheet popup menu
Figure 2-22 shows the wire sheet popup menu with a wire sheet object selected. The menu displays
different items depending on whether you right-click on an item or on a blank area of the wire sheet. For
descriptions of wire sheet popup menu items, refer to “About the wire sheet popup menu items” on page
A-9.

Figure 2-22 Wire sheet popup menu

For a description of the wire sheet, refer to “wiresheet-WireSheet” on page 14-51.


About the property sheet popup menu
Figure 2-23 shows the property sheet popup menu. For descriptions of wire sheet popup menu items,
refer to “About the property sheet popup menu items” on page A-10.

NiagaraAX-3.x
2-15
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
Types of data–presentation controls and options May 1, 2007

Figure 2-23 Property sheet popup menu

For a description of the property sheet refer to “workbench-PropertySheet” on page 14-56.


Px Editor popup menu
The Px Editor popup menu appears when you right-click on an object in the Px Editor view. The menu
commands are context-sensitive and are dimmed or available, depending on the type of object that you
select.
Figure 2-24 shows the Px Editor popup menu. For descriptions of the Px Editor popup menu items, refer
to “About the Px Editor popup menu items” on page A-10.

Figure 2-24 Px editor popup menu

For a description of the Px Editor view, refer to “workbench-WbPxView” on page 14-60.

Types of data–presentation controls and options


Workbench views often present information in text fields, charts, or tabular layouts. Similar views share
many of the same types of controls and options features. Those common features are described, by
category, in the following lists:

NiagaraAX-3.x
2-16
User Guide
Chapter 2 – About Workbench Tour of the Workbench GUI
May 1, 2007 Table controls and options

• Table controls and options


These controls affect the display of information in a table view. For details see “Table controls and
options” on page 2-17.
• Batch editing
Batch editing is available in many table views. For details see “Batch editing (or batch processing)”
on page 2-17.
• Chart controls and options
These controls affect the display chart views. For details see “Chart controls and options” on page 2-
18.

Table controls and options


Many views that present information in a table have one or more of the following display features and use
one or more of the controls and options described in the following list:

Figure 2-25 Table controls and options


Data Parameters

Title Bar Total Records

Column Headings

Column Borders

Table Options Context Sensitive


Menu Menu Items

• Data parameters
These controls include Delta (for history logging) and Time Range settings.
• Delta reporting option
This option is useful for history logging, when you want to display value changes (delta) in your
report. Refer to “About delta logging” on page 6-14 for information about delta logging.
• Time range option list
This list has a variety of predefined time range options, including an option that allows you to
restrict your data presentation to a particular date and time range that you specify.
• Title bar
This area of the table displays the name of the data collection on the left side of the title bar and in
some tables (collection table, history table, alarm extension manager, and others) displays the total
number of records in the table on the right side of the title bar.
• Column headings
Each column of data has a title that indicates the data type.
• Column boundaries
Each column has a movable column boundary that can be used to re-size the column using the
mouse control. Stretch or shrink column width by dragging the column boundary, as desired. Use
the Reset column widths menu item to reset all column widths to their default size.
• Table Options menu
This menu is located in the top right corner of the table and provides one or more of the following
controls and options. The standard table options menu includes the following items:
• Reset column widths
This menu item sets all columns in the table to their default widths. This is useful if you manu-
ally changed widths of columns, and now some contents are hidden (even after scrolling).
• Export
This menu item opens the Export dialog box where you can choose to export the table to PDF,
text, HTML, or CSV (comma separated variable).
• Context-sensitive menu items
Additional context-sensitive menu items appear in the table options menu, depending on
the component that you are viewing. These additional menu items allow you to select or dese-
lect the item in order to display or hide the column data in the table.

Batch editing (or batch processing)


Batch editing is available in many of the table views in Workbench. This is a process of editing or
processing more than one record at a time and typically includes the following general steps:
• Select multiple rows in a table by pressing the Ctrl or Shift key while clicking the desired rows.
• Use the popup (right-click, context-sensitive) menu or a toolbar icon to select an editing command

NiagaraAX-3.x
2-17
User Guide
Tour of the Workbench GUI Chapter 2 – About Workbench
Chart controls and options May 1, 2007

that performs an action or opens a dialog box editor that is appropriate for the view.
• Edit appropriate fields if a dialog box is used and click the OK button to process the edits.
Note: Some actions, such as moving rows, or editing certain types of fields, are not appropriate for
batch editing. In these cases – even though you can select multiple rows in the table, the action will be
performed on only one (usually the top, or highest) selected record in the table.
Figure 2-26 shows an example of batch processing three alarms by selecting three rows in a table view and
using the popup menu. In this case all three alarms are acknowledged when the Acknowledge
command is selected.

Figure 2-26 Batch processing (acknowledging) multiple alarms

Chart controls and options


Note: Some of the control and option features in the following description are available only in NiagaraAX-3.1
and later versions.
Many views that present information in a chart have one or more of the following display features and
use one or more of the controls and options described in the following list:

Figure 2-27 Chart view controls and options

• Data parameters
These controls include Delta (for history logging) and Time Range settings.
• Delta reporting option
This option is useful for history logging, when you want to display value changes (delta) in your
report. Refer to “About delta logging” on page 6-14 for information about delta logging.
• Time range option list
This list has a variety of predefined time range options, including an option that allows you to
restrict your data presentation to a particular date and time range that you specify.
• Chart Title
This area of the chart displays the name of the chart. This title is editable in the chart builder view.
• Y Axis
Displays units for the y axis.
• X Axis
Displays units for the x axis.
• Zoom Controls
Zoom controls appear when you drag the mouse cursor left-to-right or top-to-bottom in order to
zoom into the plotted data area. Use the zoom control to reduce the magnification amount, or to
move the chart left, right, up, or down. You can reduce the zoom level in increments by using the
“decrease zoom” icon . You can restore normal view (no zoom) in one click by clicking the “nor-
mal view” icon . Zoom Controls in Hx Web profile view are available from a popup menu, shown
in Figure 2-28, that is activated after you click once on the chart area.

NiagaraAX-3.x
2-18
User Guide
Chapter 2 – About Workbench Customizing the Workbench environment
May 1, 2007 Creating Additional Windows

Figure 2-28 Hx chart popup menu (for zoom controls)

The popup menu includes the following control-related menu items:


• Zoom In—zooms in one increment each time you select this menu item.
• Zoom Out—zooms out one increment each time you select this menu item.
• Original View—returns to the non-zoomed display (only available if you have zoomed in).
• Higher Quality—toggles between higher and lower quality graphic display for the chart.
• Charted Values
The color of the line and type of line is editable in the Chart Builder view.
• Popup menu (Export)
The popup menu displays the PDF Export menu item. This menu item opens the Export dialog
box where you can choose to export the chart to PDF, text, HTML, or CSV (comma separated vari-
able).
• Tool Tip
When you “hover” the mouse pointer over the chart, a “tool tip” displays the date, time, and value of
that location in the chart. The values are defined by chart axes and not the values of the actual data
points. Figure Figure 2-27.

Customizing the Workbench environment


You can customize your Workbench GUI as well as many of the settings in the Workbench environment.
Some settings require an acknowledgement via the OK button on a dialog box, while others are invoked
immediately and saved automatically on exit from Workbench. For example, when you exit Workbench
with four tabbed windows in your view pane, those same four windows will be displayed the next time
you open Workbench.
You can customize the Workbench environment in the following ways.
Customizing the Workbench GUI
• Creating Additional Windows
• Creating tabs in the view pane
• Bajadoc options
• General Workbench options
• Text editor options
• Wiresheet options
• Alarm portal options
• Alarm console options

Creating Additional Windows


Workbench allows you to create multiple fully functioning Workbench windows. Choosing File: >
New Window from the menu bar, creates a duplicate of your current Workbench window.
After you create multiple windows, you can then customize each individual window, as needed, to access
different information, allowing you to see multiple concurrent views. You can also copy and paste items
from one window into another window.

Creating tabs in the view pane


Workbench allows you to create multiple tabbed views within the view pane of a Workbench window, as
shown in Figure 2-29, by doing one of the following:
• From the menu bar, select File: > New Tab.
• If tabs already exist, right-click on a tab and select New Tab from the popup menu.
The new tab has a view identical to the previous one.

NiagaraAX-3.x
2-19
User Guide
Customizing the Workbench environment Chapter 2 – About Workbench
Types of Workbench options May 1, 2007

Figure 2-29 Tabs in view

As needed, you can use each tab to display a different view, component, or even host, all within the same
Workbench window. When you select a tab (make it active), the locator bar shows the current path and
view. Also, the menu and tool bars update to show appropriate options for the current view.
From the view of the active tab, you can copy items, select another tab, and then paste them into that view.
You can also drag items into an active view from the (Nav or Palette) side bar.
In the Workbench view pane you can use tabs to help organize and selectively display information.
Only one tab may be active at a time. In addition to simply clicking on a tab to make it active, you can
select File: > Next Tab from the menu bar to move to the next tab, moving left to right, or you
can move to the last tab by choosing File: > Last Tab from menu bar.
To close a tab, do any of the following:
• Right-click a tab and choose Close Tab to close that tab, or
• Right-click a tab and choose Close Other Tabs to close all tabs except that tab.
• From the menu bar, choose File: > Close Tab.
The currently active tab is closed.

Types of Workbench options


Use the Workbench options dialog box, shown in Figure 2-30, to customize your Workbench GUI and
to set other preferences. Open this dialog box by selecting Tools > Options from the menu bar.

Figure 2-30 Options dialog box

The following options are available in the options dialog box:


• General Workbench options
• Alarm console options
• Alarm portal options
• Text editor options
• Lexicon options
• Bajadoc options

NiagaraAX-3.x
2-20
User Guide
Chapter 2 – About Workbench Customizing the Workbench environment
May 1, 2007 General Workbench options

• Px editor options
• Wiresheet options

General Workbench options


General Workbench options, shown in Figure 2-31, include settings for a variety of Workbench display
and behavior options.

Figure 2-31 General Workbench options

Note: The Time Format and Unit Conversion parameters affect values that are displayed when connected to a
station using Workbench—regardless of the User preferences (set under User Manager). The User prefer-
ences that are set under the User Manager are in effect when connected to a station by a browser.
• Time Format
Choose from a format option to set the way that Workbench time values are displayed by default.
• Unit Conversion
Choosing the English or Metric option converts values that are displayed in Workbench to the
chosen unit type. Selecting None leaves units in the state that is assigned at the point facet.
• AutoLogoff Enabled
Setting this parameter to True will activate the AutoLogoff feature. When activated, the AutoLogoff
feature will automatically log off a user from a platform when there is no activity detected in Work-
bench for the period specified in the AutoLogoff Period field. Setting this parameter to False will
disable the AutoLogoff feature.
• AutoLogoff Period
Time until Workbench logs off a user when AutoLogoffEnable is set to True.
• Prompt For Name On Insert
When set to True, Workbench will display a Name dialog box, when a new item is added to the
workspace.
• Use Anti Alias
Anti-aliasing causes text to look crisper or smoother on the screen. When this parameter is set to
true, any editable text (for example a label or a text block) will be anti-aliased.
• Font Size
Choose between Normal and Large font options for Workbench display.

Alarm console options


Alarm console options, shown in Figure 2-32, allow you to customize both the appearance and behavior
of the alarm console.

Figure 2-32 Alarm console options

Alarm console options include the following:

NiagaraAX-3.x
2-21
User Guide
Customizing the Workbench environment Chapter 2 – About Workbench
Alarm portal options May 1, 2007

• Minimum Group Ack Priority


Set a minimum priority level at which groups of alarms (more than one at a time) may be acknowl-
edged.
• Needs Explicit Acknowledgement
When set to true, all alarms must be acknowledged by this console before they are removed from the
alarm table.
• Sounds Enabled
When set to true – causes a sound to accompany an alarm.
• Default Sound File
Sets the path to the default sound file.
• Continuous Alarm
When set to true, causes an alarm to repeat continually, until it is acknowledged or cleared.
• Low Priority Color
Choose a color to designate a low priority alarm.
• Mid Priority Color
Choose a color to designate a mid priority alarm.
• High Priority Color
Choose a color to designate a high priority alarm.
• Alarm Class Mapping
Provides a way for you to create alarm classes and map specific alarms to classes.

Alarm portal options


Alarm portal options, shown in Figure 2-33, allow you to customize both the appearance and behavior of
the alarm console.

Figure 2-33 Alarm portal options

Alarm console options include the following:


• Tray Icon Enabled
When set to True, displays an alarm icon in the system tray when the alarm portal is active.
• Alarm Popup Enabled
When set to True, displays an alarm popup window when the alarm portal is active.
• Alarm Popup Always On Top
When set to True, causes the alarm popup window to stay on top of other windows when the alarm
portal is active.
• Alarm Popup Uncloseable
When set to True, makes the alarm popup window uncloseable when the alarm portal is active.

Bajadoc options
Baja reference documentation includes both Java API details as well as Baja slot documentation.
• Show Baja Only
When set to True displays only the reference documentation for slots (Properties, Actions, and
Topics). When set to False, documentation on the Java constructors, methods and fields is also
displayed.
• Flatten Inheritance
This option allows you to flatten the inheritance hierarchy into a single set of documentation. When
set to False only the Java members and Baja slots declared in the specified class are displayed.
When set to True all Java members and Baja slots inherited from super classes are also shown.

Text editor options


These options offer a whole range of ways to customize the presentation and behavior characteristics of
the text editor tool. Settings include text and symbol color coding options, as well as key bindings for
shortcut keys. The text editor options properties are shown in Figure 2-34.

NiagaraAX-3.x
2-22
User Guide
Chapter 2 – About Workbench Customizing the Workbench environment
May 1, 2007 Lexicon editor options

Figure 2-34 Text editor options

Lexicon editor options


These options offer ways to customize the default settings of the lexicon editor. The lexicon editor
options properties are shown in Figure 2-35 and described in “Lexicon Editor” on page 11-5. All of these
properties may be overridden using the options that are available in the Lexicon

Figure 2-35 Lexicon editor options

Px editor options
These options offer ways to customize the presentation and behavior characteristics of the Px editor view.
The Px editor options properties are shown in Figure 2-36 and described in the following list:

Figure 2-36 Px editor options

• Show Grid
This property sets the default condition of the Px editor grid. Select true to make the grid visible
by default or select false to make the grid hidden by default. Either setting may be changed at any
time using the PxEditor menu.
• Grid Size
This property sets the size of the grid in the Px editor.
• Grid Color
This property sets the color of the grid in the Px editor. Click in the color field to display the Color
Choose dialog box. Use the Color Chooser to set the color that you want to assign to the grid.
• Use Snap
This property sets the default condition of the Snap feature in the Px editor. Select true to make
objects snap to locations when they are at a distance equal to the Snap Size. Select false to disable
the snap feature. Either setting may be changed at any time from the PxEditor menu.

NiagaraAX-3.x
2-23
User Guide
Customizing the Workbench environment Chapter 2 – About Workbench
Wiresheet options May 1, 2007

• Snap Size
Set an integer value in this field to define the interval between successive snaps.
• Show Hatch
This property sets the default condition of the Px editor hatching that displays on objects on the Px
editor canvas. Select true to make the hatching visible by default or select false to make the
hatching hidden by default. Either setting may be changed at any time using the PxEditor menu.
• Hatch Color
This property sets the color of the hatching in the Px editor. Click in the color field to display the
Color Choose dialog box. Use the Color Chooser to set the color that you want to assign to the Px
editor hatching.

Wiresheet options
Wiresheet options, shown in Figure 2-37, allow you to customize the appearance of the wire sheet.

Figure 2-37 Wire sheet options

Wire sheet options include the following:


• Show Grid
When set to True displays a grid background on the wire sheet view.
• Show Status Colors
When set to True, will display a different color for each status when it appears in the wire sheet.
• Show Thumbnail
When set to True – provides a small “thumbnail” view of the whole wiresheet for orientation and
navigation purposes.
• Thumbnail X
A field is provided here for setting the X axis for the default position of the thumbnail view.
• Thumbnail Y
A field is provided here for setting the Y axis for the default position of the thumbnail view.

Lexicon options
Lexicon options, shown in Figure 2-38, allow you to change the default filter settings for the lexicon
report and the lexicon editor.

Figure 2-38 Lexicon options

Lexicon options include the following options:


• Hide Ref Values
Ref Values are those filter values that begin with a / . Setting this to True will hide the filter values
from lexicon view. Use this if you do not want to localize references (like icons).
• Hide Accelerators
When set to True this option hides entries that define keyboard accelerators. Use this if you do not
want to localize the accelerators.
• Show Missing
When set to True this option hides entries that are localized. Use this if you do not want to see lo-
calized keys.

NiagaraAX-3.x
2-24
User Guide
CHAPTER 3
Data and Control Model
In any NiagaraAX station, all real-time data is normalized within the station database as points, a special
group of components. Each point represents one data item.
Note: This applies to a Supervisor station as well as a JACE station, a shift from r2 Niagara data modeling.
Stations no longer have “external links” between them. Instead, proxy points under a Niagara network are
used. For more details, see “About the Niagara Network” on page 4-49.
The following sections provide more details:
• About control points
• About point extensions
• About control triggers
• About point status
• About proxy points
• About writable points
• About composites

About control points


In the most simple form, points are control points. Find them in palette control: Points.

Figure 3-1 Control points

Control points are the foundation for all points in the station, including all proxy points.
• Types of control points
• Other control components
• About data value categories
• About point types
• About point Out
• About point inputs
• About point actions
• About point facets

NiagaraAX-3.x
3–1
User Guide
About control points Chapter 3 – Data and Control Model
Types of control points May 1, 2007

Types of control points


As shown in Table 3-1 there are 8 different simple control points. Each type reflects a combination of a
data (value) category and a point type.

Table 3-1 Control point types


Boolean Category Numeric Category Enum Category String Category
BooleanPoint NumericPoint EnumPoint StringPoint
BooleanWritable NumericWritable EnumWritable StringWritable
See “About data value categories” on page 3-2 and “About point types” on page 3-2.

Other control components


Apart from the 8 simple points, many other components are found in both the control palette and the
kitControl palette. Briefly, these components include:
• Extensions
To “extend” point functionality. See “About point extensions” on page 3-9.
• Triggers
To provide periodic “actions.” See “About control triggers” on page 3-14.
• Other control objects
Found in various folders in the kitControl palette. Use these to provide station control logic based
on data obtained from points. Example objects include (numeric) math types, (Boolean) logic types,
and a PID loop, among others. Also, a few point extensions are in kitControl. See the section “Ap-
plication for kitControl components” in the kitControl Guide.

About data value categories


There are four distinct data value categories for points, as well as for other components (for example,
weekly schedules). These value types are:
• Boolean
Represents a binary value with only two states, such as “Off” or “On.”
• Numeric
Represents an analog value such as a temperature, level, rate or similar floating point number, or a
varying count (integer). Double-precision (64 bit) values are used.
• Enum
Represents an enumerated state (more than two), such as a multi-speed fan with states “Off,” “Slow,”
and “Fast.” Enums are often called multi-states or discretes. States typically derive from established
integer value/state name pairs.
• String
A string of one or more ASCII characters (and if alpha-numeric), often with some literal meaning.
Among the four categories, numeric and boolean points are the most common, as data usually falls into
these two categories.

About point types


Within each of the four point data categories, there are two point types:
• (read-only) e.g. BooleanPoint or NumericPoint
Represents a read-only data item. Unlike with the writable point type, there are no “input” type prop-
erties.
Note: As copied directly from the control palette, there is no application for read-only points.
However, proxy points based upon read-only points, identical except for a non-null proxy extension
and manner of creation, are both common and useful. For more details, see “About the proxy
extension” on page 3-10 and “About proxy points” on page 3-18.
• Writable
Represents a data item that can be written, as well as read by the station (typically). An array of 16
“InN” inputs, each with a different priority level, is available to write the value. By default, the point’s
value can also be set with an operator-issued action (right-click command), available at priority lev-
els 8 (override) and 1 (emergency). For more details, see “About point actions” on page 3-3. Writable
points also have other features. See, “About writable points” on page 3-24.

About point Out


Each point has a property “Out” that provides real-time information, as shown in Figure 3-2.

NiagaraAX-3.x
3-2
User Guide
Chapter 3 – Data and Control Model About control points
May 1, 2007 About point inputs

Figure 3-2 point Out provides real-time information

At a minimum, the Out property provides:


• value
Current value of the data item, within one of four possible data categories. See “About data value cat-
egories” on page 3-2.
• facets
Items affecting the display of the value, such as decimal places, engineering units, or text descriptors
for Boolean/enum states. See “About point facets” on page 3-7.
• status
Current status of the data, meaning the health and validity of the associated value. Status is specified
by a combination of status flags, such as “fault,” “overridden,” “alarm,” and so on. If no status flag is
set, status is considered normal and appears by default as “{ok}.”
Status flags are set in a number of ways. See “About point status” on page 3-15.
• priority
Currently active Niagara priority level (from a 16-level priority scheme), for writable control points
only. For more details on priority, see “About the priority scheme” on page 3-24.
Note: All writable control points include priority in status, including writable proxy points.
Priority appears at the end of the Out value, by default formatted as “@ n”, where n is 1 to 16, or if
the fallback value is in effect, formatted as “@ def”. For example: “Off {ok} @ 1”.

About point inputs


Writable points have 16 input properties: “In1” to “In16,” corresponding to priority levels. As needed, you
can link up to 14 of these inputs to another component in the station. Figure 3-3 shows a BooleanWritable
with links made to 3 inputs.
Note: Read-only (plain) points do not have any input properties.

Figure 3-3 Example links made to priority inputs

By default, a writable point’s glyph (shape on wire sheet) shows only inputs In10 and In16 “pinned” for
linking. However, when linking to a writable point, the Link editor shows all available priority inputs. For
more details, see “About the priority scheme” on page 3-24.

About point actions


Writable points have actions—by default, these appear in a right-click menu when you select a point in a
Workbench view or in the Nav tree (Figure 3-4).

NiagaraAX-3.x
3-3
User Guide
About control points Chapter 3 – Data and Control Model
About point actions May 1, 2007

Figure 3-4 Actions available on right-click menu

An action is a slot that defines a behavior. Some other control objects and extensions also have actions.
In the case of the 4 writable control points, default actions include the ability to:
• Override the point at priority levels 8 (override) and 1 (emergency override), where control can be
independently set or “auto’ed” at either level. An override can be for a defined (or custom) length
duration, as specified in the action’s popup dialog. See “About override actions” on page 3-4.
• Set the value of the point’s “Fallback” property. See “About set (Fallback) action” on page 3-4.
Often, you modify a writable point’s default actions—see “Modifying default actions” on page 3-5.
About override actions
Whenever a writable point is controlled from an action issued at either override level, it has an “override”
status. By default, override status color is magenta, as shown in Figure 3-4. For more point status details,
see “How status flags are set” on page 3-16.
An override action to a value (not an “auto”) prompts for an override duration, see Figure 3-5.

Figure 3-5 Override action duration (“argument”) dialog

By default, a “Permanent” override is the first choice in the drop-down list—the override value will
remain effective until the next time this action is auto’ed. Other timed durations are available, including
a “Custom” selection in which a user specifies a duration in hours, minutes, and seconds. After clicking
OK, the override action is issued to the point—if this is the highest effective priority level, the writable
point operates under this control. If this is a timed override, the action is automatically auto’ed upon
expiration of the override period.
About set (Fallback) action
Whenever a writable point has a “null” or “invalid” value at inputs In1—In16 (note this means that both
override levels are currently “auto’ed”), the Out slot is set to the value of the Fallback property. For more
details, see “About the priority scheme” on page 3-24.
By default, an operator-level user can change the Fallback property, using the “set” action. This produces
a popup dialog that displays the current Fallback value (Figure 3-6).

NiagaraAX-3.x
3-4
User Guide
Chapter 3 – Data and Control Model About control points
May 1, 2007 About point actions

Figure 3-6 Set action prompt to change writable point’s Fallback property

From the set action prompt, a “Cancel” leaves the current Fallback property unchanged. Otherwise, the
Fallback property is set to the value entered (or currently displayed value).
Note: The set action prompt does not display (or accept) a “null” value for Fallback. However, a Fallback of null
can be entered from the point’s property sheet.
A common application for this feature is with NumericWritables used as setpoints, particularly under a
NiagaraNetwork. As Niagara proxy points are always read-only points (not writable types), yet inherit any
actions of the source point, this feature provides user access to setpoints via px graphics without creating
additional proxy points. In particular, this “set” action is designed to work well with “SetPoint” type
widgets (found in the kitPx palette). For details, see “About Widgets” on page 8-7.
Note: Each of the four “constant” kitControl components also provides a “set” action that works in a similar
manner, including with kitPx widgets. However, a constant object (NumericConst, BooleanConst, etc.), has
no priority inputs or Fallback property—the set action simply writes directly to the component’s current
Out slot. For details, see the “About Constant components” section in the kitControl Guide.
Modifying default actions
Unless all the “defaults” for actions of a writable point are acceptable (display names, all actions available,
default user access), you may wish to modify action defaults. Do this from the slot sheet of the writable
point. For general information, see “About slots” on page 1-10, and “Using the slot sheet” on page 12-18.
The following sections provide more details:
• Display names — Change how the point’s popup action menu lists available actions
• Action access — Limit the actions that are made available, either by user level or for all users
Display names By default, action display names are generic (“Emergency Inactive” and so on). You can
change the display name for any action. From the slot sheet, click on an action’s Display Name for an
editor (Figure 3-7). When you change a display name from defaults, it appears in listed in bold.

NiagaraAX-3.x
3-5
User Guide
About control points Chapter 3 – Data and Control Model
About point actions May 1, 2007

Figure 3-7 Editing action display names from slot sheet

When a user invokes an action, the popup menu lists possible actions by more meaningful descriptors.
For example, you could change the “set” action display name from “Set” to “Set Fallback.”
Action access By default, for any writable point, all actions are available to any admin-level user, and all
actions except emergency-level ones are available to an operator-level user. As needed, you can selectively
“hide” actions (from any level user), or change default permissions for actions.
From the slot sheet, do this by editing the action’s config flags (right-click the action and select Config
Flags, as shown in Figure 3-8).

Figure 3-8 Editing config flags of action to “hide” or change permission level

In the Config Flags editor, you click to assign or remove config flags. As pertains to action slots, the
following flags are most often changed:
• Operator
If checked, only operator-level access is needed to invoke the action. If cleared, admin-level access
is needed. For details on permission levels, see “About permission levels” on page 9-5.
• Confirm Required
If checked, a second (confirmation) dialog appears after the action is invoked, before the action ex-
ecutes. An example confirmation dialog is shown in Figure 3-9. By default, this flag is cleared.
• Hidden
If checked, the action does not appear (is hidden) from the action popup menu—for any user. You
may wish to do this selectively for some actions, for example, the “set” action for Fallback access.
(Note that a user with admin-level rights to the point may still access the point’s slot sheet.)

NiagaraAX-3.x
3-6
User Guide
Chapter 3 – Data and Control Model About control points
May 1, 2007 About point facets

Figure 3-9 Action confirmation dialog (from “Confirm Required” config flag)

About point facets


Primarily, facets determine how the point’s value displays in the station. Examples include engineering
units and decimal precision for numeric types, and descriptive value (state) text for boolean and enum
types. With the exception of proxy points (with possible defined device facets), point facets do not affect
how the point’s value is processed.
Note: Besides control points, various other components have facets too. For example, many kitControl and
schedule components have facets. Details about point facets apply to these components too, unless
especially noted.
Topics about facets include:
• Accessing and editing facets
• Facets importance for Enum points
• Effect of facets on point actions
• Effect of facets on proxy points
Accessing and editing facets
Facets is a frozen slot in all control points and objects in the kitControl module. As shown in Figure 3-10,
you modify facet values in a point’s property sheet, using the Edit Facets dialog.

Figure 3-10 Point facets and edit dialog

Optionally, you can add or remove facet values in a point—however, for most points you will only modify
or provide new values for the default facets.
Note: For string-type points (StringPoint, StringWritable), facets have little practical application. By default, the
Facets slot is empty for string-type points.
Facets importance for Enum points
Facets for enum-type components (EnumPoint, EnumWritable, EnumSchedule, etc.) define the
operating range of the component, meaning its different possible enumerated states. Each state is defined
by a pairing of an integer value-to-text, also known as ordinal-tag. Each ordinal must be a unique integer,
and each tag must be unique text. By default, the point’s value displays using tag text.
If you add an enum point from the control palette, its Facets slot has a blank range entry. Until you edit
this facet and supply the ordinal-tag values, it can display only integer values. As shown in Figure 3-11, a
special Enum dialog appears when you edit range facets.

NiagaraAX-3.x
3-7
User Guide
About control points Chapter 3 – Data and Control Model
About point facets May 1, 2007

Figure 3-11 Enum dialog for enum point “range” facets

When defining range enumerations, instead of defining a custom one with your supplied ordinals and
tags text, you can also select from well known “frozen” enumerations, as defined in various installed
modules. A checkbox enables this and provides a drop-down list for you to select by module and enumer-
ation type (see Figure 3-12).

Figure 3-12 Frozen enum selection in Enum dialog

Depending on the driver/network type, the Point Manager under a device may automate this facets range
configuration when you add enum-type proxy points. For example, under a Lonworks device, if you add
a EnumPoint for a Lonworks NVO that uses an enumerated SNVT, that point’s facets will automatically
be configured with the correct range values.
Note: If an enum-type point receives an input value not included in its defined facets range, it displays the ordinal
integer value for that input. This varies from the multistate objects used in r2 Niagara, which would display
“Error” for any value not defined in its “stateText” entries.
Effect of facets on point actions
For some points with actions (see “About point actions” on page 3-3), facets also affect availability in the
point’s action (command) menu, as follows:
• EnumWritable
Upon an override or emergency action, a secondary drop-down selection dialog lists the possible

NiagaraAX-3.x
3-8
User Guide
Chapter 3 – Data and Control Model About point extensions
May 1, 2007 Extension process overview

enum values (in its range), using display tag text. This list appears ordered top-to-bottom by the tag
associated with each ordinal, lowest-to-highest.
• NumericWritable
Upon an override or emergency action, an entry dialog permits a value only between the facets “min”
and “max” values, inclusive. By default, these facets values for numeric-type points are min= -inf and
max= +inf (no effective range checking for an action).
For example, you could use this facet’s feature with a NumericWritable that sets a temperature con-
trol setpoint, by setting its facets min= 65 and max=85. After saving this change, any override or
emergency action issued to that NumericWritable would need to fall within this range. Otherwise,
a user would see a message showing the acceptable range, and be prompted to try again.
Note: Facets “min” and “max” values do not affect any received input values or proxied data, only
what can be issued via an action.
Effect of facets on proxy points
Each proxy point typically represents a piece of data in a remote device (see “About proxy points” on page
3-18). In cases for drivers that support a “learn” mechanism, a proxy point may be created with its facets
(units) already defined—these reflect its “Device Facets” (in its ProxyExt).
If needed, you can change the parent proxy point’s facets to use similar (same family) units. For example,
if a Lonworks proxy point for a temperature NVI (learned in degrees C), you can change the proxy points
facets to degrees F. The “default” conversion performed in the LonProxyExt automatically adjusts the
output value appropriately. In this case, facets directly affect the point’s out value.
Note: If you change a proxy point’s facets to use units that are dissimilar from the device facets in its ProxyExt
(without also changing its Conversion from “Default”), the proxy point will have a fault status (to show
misconfiguration). For example, if its device facets are temperature, and you change the point’s facets to
pressure, the point will have a fault status.
For details on properties common to the ProxyExt in all proxy points, including Device Facets and
Conversion, see “ProxyExt properties” on page 3-23.

About point extensions


As needed, you can add one or more extensions to a point, each as a child of that point. Extensions are a
way to add functionality to a point (or extend it) in a modular fashion.
The following topics provide more details on extensions:
• Extension process overview
• Types of point extensions
• About the proxy extension
• About control extensions
• About alarm extensions
• About history extensions
Note: Extensions also apply to most kitControl objects. See “Extensions and kitControl components” on page 1-4
for more details.

Extension process overview


Extensions are found in several palettes, including alarm, control, history, and kitControl.
You typically add an extension by either:
• dragging it into the property sheet of the point, or
• dropping it on the point’s icon in the Nav tree.
A point’s property sheet lists extensions below its normal (frozen) properties. You can expand each
extension to view and modify its properties, as shown in Figure 3-13.

NiagaraAX-3.x
3-9
User Guide
About point extensions Chapter 3 – Data and Control Model
Types of point extensions May 1, 2007

Figure 3-13 Extension expanded in a point’s property sheet

If a point has multiple extensions, they are processed in the same top-to-bottom order that they appear
listed in that point’s property sheet. You can re-order extensions in a point—from the top of the point’s
property sheet, or on the point’s icon in the Nav sidebar, right-click and select Reorder.
Note: If needed, you can also select and expose extension properties (for linking convenience) on the point’s glyph
by using the Composite editor of the parent point. For more details, see “About composites” on page 3-26.

Types of point extensions


Point extensions include the standard proxy extension (one for each point, see “About the proxy
extension” on page 3-10) and also optional extensions.
Optional extensions are in three main categories:
• control extensions
from control palette. See “About control extensions” on page 3-11.
• alarm extensions
from alarm and kitControl palette. See “About alarm extensions” on page 3-12.
• history extensions
from history palette. See “About history extensions” on page 3-13.

About the proxy extension


Each point has a proxy extension (Proxy Ext), a frozen property. The proxy extension is important—it
indicates how the point’s data originates, including details specific to the parentage of the point’s network
and communications (driver).
A point’s proxy extension is either:
• Null
For any point that you copy from the control palette (or add using the right-click menu), the proxy
extension is simply null (NullProxyExt)—an empty placeholder. The station itself originates the
point's default Out value.
• <DriverType>
For any proxy point, meaning any of the 8 point types you create using the Points extension under a
device represented in any of the network types, the proxy extension is <DriverType>ProxyExt. For
example, a BooleanWritable proxy point under the Points container of a Bacnet Device has a proxy
extension of “BacnetBooleanProxyExt.”
For any proxy point, its proxy extension contains information organized in child properties. Some
properties may be unique to that specific driver type.
Figure 3-14 compares property sheet views of the proxy extension properties for two BooleanWrit-
able points, on the left a control point, on the right a BACnet proxy point.

NiagaraAX-3.x
3-10
User Guide
Chapter 3 – Data and Control Model About point extensions
May 1, 2007 About control extensions

Figure 3-14 Proxy extension for control point (null) and a Bacnet proxy point.

For more details, see “About proxy points” on page 3-18 and “ProxyExt properties” on page 3-23.

About control extensions


Control extensions are found in palette control: Extensions (Figure 3-15). As needed, you can add
them to points along with alarm and history extensions.

Figure 3-15 Control extensions

Control extensions perform additional processing on a point’s received value. There are relatively few
types of control extensions. See “Types of control extensions” on page 3-11.
Types of control extensions
Table 3-2 lists all available control extension types and the applicable point parents.

Table 3-2 Control extension types


Control extension type Applies to point types What it does
(palette:Folder) (read-only) Writable
DiscreteTotalizerExt BooleanPoint BooleanWritable Accumulates runtime and change
(control:Extensions) EnumPoint EnumWritable of state (COS) count. Extension
actions permit resetting (zeroing)
— any object with single Bool- the runtime and COS count.
ean Out, e.g. kitControl:
Logic object “And”

NiagaraAX-3.x
3-11
User Guide
About point extensions Chapter 3 – Data and Control Model
About alarm extensions May 1, 2007

Control extension type Applies to point types What it does


(palette:Folder) (read-only) Writable
NumericTotalizerExt NumericPoint NumericWritable Accumulates numeric total using
(control:Extensions) — any object with single hourly or minutely totalization.
Numeric Out, e.g. kitControl: Extension has action to reset
Math object “Add” (zero) total.

ProxyExt (standard for any point, see ““About the proxy extension” Provides methods to driver com-
(control:Extensions) on page 3-10) munications.

About alarm extensions


Use an alarm extension for any point you wish to monitor for offnormal values, and show alarm
indication when a limit or value is met or exceeded. In an alarm extension, you also specify whether an
alarm annunciation should occur upon alarm transitions, plus many other parameters.
Find the alarm extensions in palettes alarm: Extensions (Figure 3-16) and kitControl:Alarm.

Figure 3-16 Alarm extensions

Alarm extension properties define items such as alarm enable (annunciation) transition types, alarm
delay times, associated alarm class, and alarm display text for different transition types. You define the
actual alarm limits or state(s) in properties in the extension’s “Offnormal Algorithm” slot. For more
details, see “About alarm extension properties” on page 7-3.
Types of alarm extensions
Table 3-3 lists all alarm extension types and the applicable point parents.

Table 3-3 Alarm extension types


Alarm extension type Applies to point types General description
(palette:Folder) (read-only) Writable
OutOfRangeAlarmExt NumericPoint NumericWritable Provides alarming based upon
(alarm:Extensions) — any object with single numeric alarm high and low limits.
numeric Out, e.g. kitControl: Includes configurable deadband.
Math object “Add”
BooleanChangeOfStateAlarmExt BooleanPoint BooleanWritable Provides alarming based upon one of
(alarm:Extensions) — any object with single Bool- two possible values (state) as an
ean Out, e.g. kitControl: alarm condition.
Logic object “And”
BooleanCommandFailureAlarm- — BooleanWritable Provides alarming based upon mis-
Ext match between commanded value
(alarm:Extensions) and actual (sensed) value. Extension
has feedbackValue input property
for linking.

NiagaraAX-3.x
3-12
User Guide
Chapter 3 – Data and Control Model About point extensions
May 1, 2007 About history extensions

Alarm extension type Applies to point types General description


(palette:Folder) (read-only) Writable
EnumChangeOfStateAlarmExt EnumPoint EnumWritable Provides alarming based upon one of
(alarm:Extensions) multiple possible values (state) as an
alarm condition.
EnumCommandFailureAlarmExt — EnumWritable Provides alarming based upon mis-
(alarm:Extensions) match between commanded value
and actual (sensed) value. Extension
has feedbackValue input property
for linking.
StatusAlarmExt any type that accepts any type that accepts exten- Provides alarming based upon any
(alarm:Extensions) extensions sions combination of status flags, includ-
ing overridden, null, etc.
LoopAlarmExt(kitCon- — LoopPoint Sliding alarm limit for LoopPoint
trol:Alarm) based upon controlled process devi-
ation from setpoint.
ElapsedActiveTimeAlarmExt BooleanPoint with BooleanWritable with Dis- Provides alarming based upon accu-
(kitControl:Alarm) DiscreteTotalizerExt creteTotalizerExt mulated runtime (elapsed active
— any object with single Bool- time). References a specific Discrete-
ean Out (also with a Discre- TotalizerExt under same parent
teTotalizerExt), e.g. kitCon- point.
trol: Logic object “And”
ChangeOfStateCountAlarmExt BooleanPoint with BooleanWritable with Dis- Provides alarming based upon accu-
(kitControl:Alarm) DiscreteTotalizerExt creteTotalizerExt mulated COS (change of states). Ref-
— any object with single Bool- erences a specific DiscreteTotalizer-
ean Out (also with a Discre- Ext under same parent point.
teTotalizerExt), e.g. kitCon-
trol: Logic object “And”

About history extensions


Add a history extension to any point for which you want to log historical data, that is collect a history. In
a point history, each collected sample of slot “Out” has a date-timestamp, point status and value. Point
history data is viewable in both a table and chart format.
Find the history extensions in palette history: Extensions (Figure 3-17).

Figure 3-17 History extensions

Each history extension has various properties in two major groups:


• Collector
Determines how or when data is collected, such as active time, and (if applicable) either change tol-
erance or the collection interval time.
• History Config
Determines how the data is stored and accessed in the system, such as history name, capacity, and

NiagaraAX-3.x
3-13
User Guide
About control triggers Chapter 3 – Data and Control Model
About history extensions May 1, 2007

full policy.
For more details, see About Histories.
Types of history extensions
Table 3-4 lists all history extension types and the applicable point parents.

Table 3-4 History extension types


History extension type Applies to point types General description
(read-only) Writable
BooleanChangeOfValue BooleanPoint BooleanWritable Collects upon each change of Bool-
— any object with single ean value (state) or status.
Boolean Out, e.g. kitCon-
trol: Logic object type
“And”
BooleanInterval as above as above Collects upon a repeating time
interval, as configured.
NumericChangeOfValue NumericPoint NumericWritable Collects upon each change of value
— any object with single (outside a specified tolerance) or
Numeric Out, e.g. kitCon- change of status.
trol: Math object type
“Add”
NumericInterval as above as above Collects upon a repeating time
interval, as configured.
EnumChangeOfValue EnumPoint EnumWritable Collects upon each change of enu-
— any object with single merated state or status.
Enum Out
EnumInterval as above as above Collects upon a repeating time
interval, as configured.
StringChangeOfValue StringPoint StringWritable Collects upon each change of string
— any object with single value or status.
String Out
StringInterval as above as above Collects upon a repeating time
interval, as configured.

About control triggers


There are two “time triggers” in the palette control:Trigger. These objects do not represent data, but
instead regularly fire a topic.

Figure 3-18 Control triggers

The two control trigger types are:


• Interval
Fires at a regular, repeating intervals specified in its Trigger Mode property.
For example, every n minutes, n hours, or whatever combination needed.
• Daily
Fires once a day at a specific time and day of week, as specified in its Trigger Mode property. For

NiagaraAX-3.x
3-14
User Guide
Chapter 3 – Data and Control Model About point status
May 1, 2007 How triggers are used

example, at 00:00:00 (midnight) all days of week except Sunday.


Each type has even more configuration capabilities to further define the fire time.

How triggers are used


To use a trigger, you typically link it to a selected action of a point extension (e.g. control, alarm, and
history) to automate an action. Often, you use a trigger as a child of a particular point (sibling to the linked
extension). Or, you can have a trigger in the same container as multiple points, and link it to more than
one point or point extension.
For example, a Daily trigger (defined for midnight) can be linked to the ResetElapsedActiveTime action
of a DiscreteTotalizerExt extension of a BooleanWritable point. In this case, that point’s DiscreteTotal-
izerExt would only show runtime accumulated during the current day.

About related objects


Other objects with trigger functions are found in various palettes. The most closely related is the Trigger-
Schedule object, found in the Schedule palette. See “About trigger schedules” on page 10-18.

About point status


Along with point value, point status is available at point Out. Status reflects status flags, which may get
set singly, or in combinations. Status flags are typed by a unique text string (for example: “alarm” or
“down”), and many have associated status colors (a background and a foreground). For example, the
default status colors for alarm is white text on red background.
Status without any flags set is considered normal (text “ok”), and is without color indication.
Note: For each installed lexicon, text strings for status flags (plus associated colors), are individually adjustable
by editing default values in that host’s baja lexicon, using Workbench’s Lexicon Editor. For a default
English installation, to change default status appearance settings, edit the en: baja lexicon. For more
details, see About Lexicons.
The following topics explain further details about point status:
• Types of status flags
• Priority of status indication
• How status flags are set
• About “isValid” status check

Types of status flags


Status flag types are listed in Table 3-5, along with associated default colors (if any).

Table 3-5 Status flag types

Type Default Colors, Exam- Meaning


ple

alarm white text, Point currently has a value in an alarm range, as defined by property in its
red background alarm extension.

fault black text, Originates from a proxy point only. Typically indicates a configuration or
orange background licensing error. If it occurs after normal operation, it may indicate a “native
fault” in device, or the point’s parent device has a fault status.

overridden black text, Current point control is from an action, meaning a user-invoked command
magenta background at either priority level 8 (override) or priority 1 (emergency).

disabled gray text, Originates from a proxy point only. Point (or its parent device or network)
light gray background has been manually disabled (property enabled = false).

NiagaraAX-3.x
3-15
User Guide
About point status Chapter 3 – Data and Control Model
Priority of status indication May 1, 2007

Type Default Colors, Exam- Meaning


ple

down black text, Originates from a proxy point only. Driver communications to the parent
yellow background device are currently lost, based upon the device status (Monitor) configu-
ration for that network.

stale black text, Originates from a proxy point only. Driver communications have not
tan background received a requested response for this data item within the configured
times (Tuning period).

null (no color indication) Current point control has entered a null state, vs. a specific value and pri-
ority level. Typical to fallback operation for a writable point.

unackedAlarm (no color indication) Last point alarm event has not yet received user acknowledgment. Point’s
alarm extension uses alarm class requiring acknowledgment.

Priority of status indication


Since status flags for a point or object can get set in combinations, status color indication uses a priority
method. Among those 6 status flags with associated colors, priorities (and default colors) are:
1.
disabled (dark gray)
Proxy point origination only. Point may have other status flags set. Typically, you manually set and
clear this status (unlike others). After disabled is set for a proxy point, it is no longer polled. Further
status changes do not occur until disabled is cleared.
2. fault (orange)
Proxy point origination only. See “Proxy point status” on page 3-18.
3. down (yellow)
Proxy point origination only. See “Proxy point status” on page 3-18.
4. alarm (red)
Point may have other status flags set.
5. stale (tan)
Proxy point origination only. See “Proxy point status” on page 3-18.
6. overridden (magenta)
Point may have other status flags set.
Note: Status types unackedAlarm and null do not affect the indicated status color.

How status flags are set


Status flags are set differently depending on the type of point or control object. The following sections
explain:
• Simple control point status
• Propagate Flags status option (linked Math and Logic objects)
• Proxy point status
Simple control point status
For simple control points (NullProxyExt) the following status flags are the only ones set and cleared:
• alarm
Point is currently in an alarm condition as defined in its alarm extension.
• unackedAlarm
Point has alarm extension assigned to an alarm class requiring acknowledgment, but the last alarm
event has not yet been acknowledged. Point may/may not be in alarm.
• override
Writable points only, during a user-initiated action at priority levels 8 (override) or 1 (emergency).
The override flag clears when the action “times out,” or when a user issues an “auto” action at that
same priority level.
• null
Writable point has “null” or otherwise “invalid” value at In1—In16, plus “null” configured as “Fall-
back” value. See “About “isValid” status check” on page 3-18.

NiagaraAX-3.x
3-16
User Guide
Chapter 3 – Data and Control Model About point status
May 1, 2007 How status flags are set

See Figure 3-19 for examples of override and alarm status in simple control points.

Figure 3-19 Status with simple control points

Propagate Flags status option (linked Math and Logic objects)


By default, kitControl objects maintain independent status flags from input-linked points. However, as a
configuration option in each math or logic-type kitControl object (kitControl palette folders “Math” and
“Logic”), you can specify “out” status to propagate from input status.
The object’s Propagate Flags property allows you to select any combination of the following status
types for propagation:
• disabled
• fault
• down
• alarm
• overridden
Note: If the math or logic object has multiple inputs, and you set the propagateFlags property to select one or more
of the statuses above, simple “OR” logic is used across all inputs for the propagation of each selected status.
Depending on usage, status propagation may be extensive. Note that four of the five status types (all
except alarm and overridden) are “invalid status,” meaning they cause the output of the object (if linked)
to be considered invalid at its destination target. See “About “isValid” status check” on page 3-18.
As an example of status propagation, some number of NumericWritable points are used to establish
setpoints, and you link them all to a Math: Average object for downstream zone control. In turn, the
Average object feeds a Math: Reset object. Both math objects have “override” enabled in their “propagate-
Flags” property. A user issues an override (action) to one of the NumericWritable points, to override a
setpoint (Figure 3-20).

Figure 3-20 Status propagation in linked writable points, kitControl objects

NiagaraAX-3.x
3-17
User Guide
About proxy points Chapter 3 – Data and Control Model
About “isValid” status check May 1, 2007

For the duration of the override, the linked Average object will also have an overridden status, as will the
Reset object, and so on. However, note that the linked writable point (NWcombined) in this example does
not have overridden status—status never propagates to any point.
Note: Status propagation did not occur in Niagara r2, and is a new configuration option in NiagaraAX. Before
using this feature in an actual job, you should test and evaluate results to be sure it has the desired effect.
For example, if a Logic or Math object is exposed in a graphic and appears overridden, a user may (incor-
rectly) assume that they can right-click command (perform an action) on that kitControl object, based on
status color indication.
Proxy point status
In addition to status flags that also apply to non-proxy points (see “Simple control point status” on page
3-16), some status flags in proxy points are set and cleared resulting from polled value or status updates
received via the parent driver’s communications subsystem, for example:
• down
Driver unable to receive reply from parent device, as per configuration in Monitor extension. In this
case, all proxy point children of the device will have status down.
• fault
Typically, this indicates an AX configuration error or license error. If a fault occurs following normal
(ok) status, it could be a “native fault” condition detected within the device, or perhaps some other
fault criteria that was met. The point’s proxy extension contains a “Fault Cause” text property that
contains more information.
• stale
Since the last poll update, the point’s value has not updated within the specified “Stale Time” of its
Tuning Policy. This stale status clears upon next received poll value.
Statuses above are set automatically, but you typically set a fourth status for a proxy point manually:
• disabled
Using the proxy extension’s Boolean property “Enabled” (default is true). While set to false (dis-
abled), polling stops for that point, as well as any further status changes.
Note: Typically, a proxy point has an alarm status only if its value falls in the “offnormal algorithm” limits
specified in its own (NiagaraAX) alarm extension. If the driver and protocol has “native” alarm determi-
nation methods (such as with BACnet), a proxy point may show alarm status that originated locally within
that device. In the case of the Niagara Bacnet driver, this also applies to override status, possibly a
“native” condition for a proxied BACnet object.

About “isValid” status check


When linking an input-type slot of a writable point or kitControl object, the value received at the input
is processed (evaluated) by that point or object only if it is valid.
Note: A valid input is one with none of the following status flags set:
• down
• fault
• disabled
• null
• stale
If any of the above status bits are set at an input, that input value is not used.
• If a kitControl object with a single input, by default that object uses the last known valid received (at
least until the input becomes valid again).
• If a kitControl object with a multiple inputs, only the valid inputs are evaluated.
• If a writable point, the priority scan continues. See “About the priority scheme” on page 3-24.

About proxy points


Proxy points are often the bulk of all points in a station. This is true whether a JACE or a Supervisor
station. Proxy points are any of the 8 simple control points (Table 3-1 on page 2), only with a non-null
proxy extension. See “About the proxy extension” on page 3-10.
These following sections provide more details about proxy points:
• Location of proxy points
• How proxy points are made
• Proxy points versus simple control points
• ProxyExt properties

NiagaraAX-3.x
3-18
User Guide
Chapter 3 – Data and Control Model About proxy points
May 1, 2007 Location of proxy points

Location of proxy points


In the AX station architecture, proxy points must reside under the driver network and device from which
the specific data originates. Proxy points are under that device’s Points container (Points extension), as
shown in Figure 3-21.

Figure 3-21 Proxy points location example

As needed, you can create folders under a device’s Points container to further organize the proxy points.
In addition to proxy points, you can also add simple control points (null proxy ext), schedule objects, and
other kitControl objects under a device’s Points container.
Note: See also “Location for kitControl components” in the kitControl Guide.
Depending on station type, proxy point locations will vary as follows:
• JACE station
Most proxy points are under non-Niagara driver networks, such as Lonworks, Bacnet, and Modbus,
to name a few. These points represent real-time data in various devices attached (or somehow net-
worked) to the JACE controller.
Like all AX stations, the JACE will also have a Niagara Network too. Any proxy points under it will
represent data received from other JACE stations and/or perhaps the Supervisor station.
• Supervisor station
Typically, most proxy points are under its Niagara Network, where each JACE appears as a station
device. Proxy points under each station device represent real-time data from that JACE. Typically,
most data in a JACE station also originates as a proxy point, and so these points are often a “proxy
of a proxy.” For details, see “About the Niagara Network” on page 4-49.
Note: If the Supervisor is specially licensed for direct field device communications, such as a BACnet
Supervisor or OPC Supervisor, its station will have many proxy points under other driver network
types, and perhaps only a few under its NiagaraNetwork. In Drivers architecture, it resembles a JACE.
For more details, see “Driver architecture” on page 4-1.

How proxy points are made


Note: You create proxy points in a station as one of the later stages in building a driver network. This section only
provides an overview of the proxy points portion. For more complete details, see “Driver architecture” on
page 4-1.
When you add a device under a network, one of its default extensions is a container named “Points.” The
default view for Points is a “Point Manager,” which you use to add proxy points to the station database.
An example Bacnet device Points Manager is shown in Figure 3-22.

NiagaraAX-3.x
3-19
User Guide
About proxy points Chapter 3 – Data and Control Model
How proxy points are made May 1, 2007

Figure 3-22 Points Manager example (Bacnet Device)

Typically, you have performed your previous station configuration of this network with the host (e.g.
JACE) networked and communicating to the devices of interest. This allows you to use the “Learn Mode”
feature (provided by most drivers). This feature is especially useful for adding proxy points to the station.
In the Point Manager, the Learn Mode toggles the view between only proxy points that are currently in
the station (“Database”), and a split view showing both a “Discovered” area and the “Database” area. See
“About Learn toggle” on page 4-16 for more details.
Clicking the Discover button launches a “point discovery job.” The driver queries the selected device
to retrieve available data. Depending on a number of factors (driver type, communications rate, amount
of data), this can take from only a few seconds to over a minute. See Figure 3-23.

Figure 3-23 Points Discover in progress

When the discover completes, the “Discovered” view portion provides a table of available data items.
Each row represents at least one item (a candidate for one proxy point). If there are multiple, closely-
related data items, that row appears with a leading plus (“+”). You can expand it to see other available data
items. Again, each row is a candidate for one proxy point.
Depending on the driver type, table column headings vary—for example a Bacnet points discover shows
“Object Name,” “Object ID,” etc., in the Discovered table (see Figure 3-24).

NiagaraAX-3.x
3-20
User Guide
Chapter 3 – Data and Control Model About proxy points
May 1, 2007 How proxy points are made

Figure 3-24 Points Discover completed

As needed, you click on column headers to resort and/or use the scroll bar to view available discovered
data items. After selecting one or more items by clicking on rows (to highlight), you can click the Add
button to start the proxy point creation process. The Add dialog appears (Figure 3-25).

Figure 3-25 Add points dialog

The Add dialog allows you to select each data item and change things about its default point creation
before it is added to the station database. Most important is “Type,” meaning the control point type—as
unlike other things (such as Name) you cannot change that after the creation. Apart from Name and
Type, most other properties are proxy extension properties.
Selecting the Type drop-down, alternate point types are available for selection, see Figure 3-26. If the
driver recognizes the data item as writable, this will include writable point types.

NiagaraAX-3.x
3-21
User Guide
About proxy points Chapter 3 – Data and Control Model
How proxy points are made May 1, 2007

Figure 3-26 Type drop-down in Add dialog

Typically, you do not change the data category type (Boolean, Numeric, etc.), but you may wish to select
either a read-only point or a writable point.
You click any discovered data item to select it for changing Type, or any other property. If a common
change is needed among data items (for example, Poll Frequency), you can select multiple items and edit
that property one time.
When you are satisfied with the point types shown for each item, you click the OK button at the bottom
of the Add dialog. Those proxy points are then created in the station database in the Points container,
and now appear as table rows in the “Database” (lower) table of the Point Manager view. The source data
items now appear “ghosted” in the “Discovered” (upper) table, to indicate that they now exist in the
station database. See Figure 3-27.

Figure 3-27 Proxy points added to station

You may repeat this process as needed to create additional proxy points, where you can toggle the display
of the Discovered portion off and on by clicking the Learn Mode tool.
Once in the Database table of the Points Manager, you can click to select (highlight) a proxy point, then
modify it using the Edit button, or simply double-click it. This produces an Edit dialog nearly identical
to the Add dialog, where you can change the same proxy extension properties and Name (but not Type).
You can also select multiple proxy points and use the Edit dialog to “gang edit” one or more of the same
properties that are common to each selected point.
In the Database portion, you can right-click a proxy point to access its normal views, including property
sheet. There, you can expand its Proxy Ext to see many of the same properties you saw in the Add and
Edit dialogs. Also, you can right-click a proxy point in the Database table to access any available point
actions (if a writable point).
Each Points container has other views besides the default Point Manager. For example, you can select its
Wire Sheet view to see and organize the proxy points glyphs (Figure 3-21 on page 19), add additional
objects from palettes control and/or kitControl, and so forth.
Note: The following notes apply when working with proxy points.
• In a Niagara Network, the Discover and Add process is different than in other driver networks.
There, you use a “BQL Query Builder” to select data items in a remote station. For more details, see

NiagaraAX-3.x
3-22
User Guide
Chapter 3 – Data and Control Model About proxy points
May 1, 2007 Proxy points versus simple control points

“About the Niagara Network” on page 4-49 and “About the Bql Query Builder” on page 4-56.
• Any Point Manager view only shows proxy points. If you added other objects (for example, control
points with null proxy extension, or kitControl objects), they do not appear in the Database table.
However, they are visible in the Nav tree and the Points wire sheet.
• If you want folders under Points to organize your proxy points and other objects, use the “New Fold-
er” button in the Point Manager to create each folder. This provides a Point Manager view for each
folder. For more details, see “About the Point Manager” on page 4-28.

Proxy points versus simple control points


Functionally, there is little difference between a simple control point (NullProxyExt) and the equivalent
proxy point. For example, you can add the same extensions (e.g. control, alarm, and history) to a proxy
point as to a simple control point—there is no need to “duplicate” the point first.
However, apart from the location differences (see “Location of proxy points” on page 3-19) and manner
of creation (see “How proxy points are made” on page 3-19), proxy points have the following differences
from simple control points:
• Status flag processing
Status flags of proxy points are affected by real-time changes that may occur in the remote device,
plus changes in communications between that device and the station. This is in addition to “AX-add-
ed” status flags set by an alarm extension (for example, “alarm” or “unackedAlarm”). See “Proxy
point status” on page 3-18.
Related are “global” status rules common among NiagaraAX drivers, set at both the network-level as
well as adjustable at the proxy-point level. For details, see “About Tuning Policies” on page 4-8.
• Point duplication
When you duplicate a proxy point, you are duplicating information in its Proxy Ext that might be
better left unique. This may result in redundant messages between the device and station for the
same data item, adding overhead. If duplicating a proxy point, you should have a clear idea of what
you will change to prevent this inefficiency.

ProxyExt properties
Regardless of the driver, the proxy extension (ProxyExt) for any proxy point has a number of core
properties that provide the same behavior. Depending on the driver, other ProxyExt properties are often
present—see the particular driver document for details on those properties.
Core properties in any ProxyExt include the following:
• Status
(read only) Status of the proxy extension, which in turn determines parent point status. See “Proxy
point status” on page 3-18.
• Fault Cause
(read only) If point has fault status, provides text description why.
• Enabled
Either true (default) or false. While set to false, the point’s status becomes disabled and polling is sus-
pended.
• Device Facets
(read only) Native facets used in proxy read or writes (Parent point’s facets are used in point status
display, and are available for edit in Add and Edit dialogs in Point Manager).
• Conversion
Specifies the conversion used between the “read value” (in Device Facets) and the parent point’s out-
put (in selected point facets).
Note: In most cases, except when working with particular Ndio proxy points, or perhaps Modbus
proxy points, the standard “Default” conversion selection is best.
Conversion selections include:
• Default
(The default selection). Conversion between “similar units” is automatically performed within
the proxy point. For example, if a Lon proxy point with a LonFloatProxyExt (Device Facets of
degrees C), if you set the point’s Facets to degrees F, its output value automatically adjusts.
If you set the parent point’s Facets to dissimilar units (say, in this case to kilograms), the parent
point has a fault status to indicate a configuration error.
• Linear
Applies to certain Ndio proxy points, such as NdioVoltageInput and NdioResistiveInput. Also
commonly used in some Modbus proxy points. For these points, you typically want the point’s
output value in some units other than Device Facets (if Ndio, voltage or resistance), and the Lin-

NiagaraAX-3.x
3-23
User Guide
About writable points Chapter 3 – Data and Control Model
About the priority scheme May 1, 2007

ear selection provides two fields to make the transition:


– Scale: Determines linear response slope.
– Offset: Offset used in output calculation.
• Reverse Polarity
Useful in a Boolean-type Ndio proxy point to reverse the logic of the hardware binary input. Al-
so, may be used in any driver’s proxied BooleanPoint, as a way to “flip” the read state of the na-
tive value.
Note: Be careful in the use of the reverse polarity conversion, as it may lead to later confusion
when troubleshooting logic or communications problems.
• Thermistor Type 3
Applies to an NdioThermistorInput point, where this selection provides a “built-in” input re-
sistance-to-temperature value response curve for Type 3 Thermistor temperature sensors.
• Tabular Thermistor
Applies to an NdioThermistorInput point, where this selection provides a control for a popup
dialog for a custom resistance-to-temperature value response curve, including ability to import
and export response curves.
• Tuning Policy Name
(most drivers) Associated network tuning policy for this proxy point, by name. Tuning policies are
used to separate poll rates and other driver features. See “About Tuning Policies” on page 4-8.
• Read Value
(read only) Last value read from the device, expressed in device facets.
• Write Value
(read only) Applies if writable point only. Last value written, using device facets.

About writable points


All writable points provide right-click actions. Override actions are evaluated within the priority scheme
used by any writable point. In the case of the “set” action, the point’s “Fallback” property is modified (see
“About point actions” on page 3-3). BooleanWritable points also offer built-in “minimum on/off ” timers.
• About the priority scheme
• About minimum On and Off times

About the priority scheme


Each writable point uses a 16-level priority scheme, with corresponding inputs In1—In16, plus a
“Fallback” property. Level 1 is the highest priority, and level 16 is the lowest.
The following topics further describe the priority scheme:
• Priority input scan
• Priority linking rules
• Priority level conventions
Priority input scan
For any writable point, the effective input value is determined by a priority scan, looking for a “non-auto”
action at level 1 (emergency), then the value at the highest valid input, going from level 2, to 3, and so on
to level 16. (At level 8, any “non-auto” action is evaluated as valid).
Like almost all control execution, this priority scan is event-driven, meaning it occurs when any input
value changes. An input’s value typically comes from a link—however, note that for most inputs, you may
enter a value directly in the point’s property sheet (as an alternative source).
Note: A valid input is one with none of the following status bits set:
• down
• fault
• disabled
• null
• stale
If all 16 priority levels are evaluated without a valid input (and without an action at levels 1 and 8), then
the fallback value is used.
Note: You can configure the writable point’s “Fallback” property to be “null,” so that the point’s Out has a null
status in this condition. Depending on the specific control sequence and usage of the writable point, this
may be an effective solution.

NiagaraAX-3.x
3-24
User Guide
Chapter 3 – Data and Control Model About writable points
May 1, 2007 About minimum On and Off times

However, note that by default, a “set” action exists on any writable point, which writes directly to the
Fallback value. See “About set (Fallback) action” on page 3-4. If you want a writable point to always have
a Fallback of “null,” go to its slot sheet and set the “Hidden” config flag on the “set” slot. Otherwise, a user
can invoke a right-click command to set Fallback to any value. For more details, see “Modifying default
actions” on page 3-5.
Priority linking rules
When linking to the priority inputs of a writable object, you may notice these default rules:
• Only one link per input (level).
• Levels 1 and 8 are unavailable for links. If a BooleanWritable, level 6 is also unavailable.
Priority levels 1 and 8 are reserved for actions (emergency and override). See “About point actions”
on page 3-3. Priority level 6 in a BooleanWritable is reserved for minimum on/off times. See “About
minimum On and Off times” on page 3-25.
Note: Both rules vary from the r2 Niagara priority input scheme, where a single priorityArray input was used for
a writable object (AnalogOutput, BinaryOutput, and so forth). That input could be linked to multiple
priority type outputs, including those with duplicate priority levels and/or levels also used for object
commands (emergency and manual).
Priority level conventions
The 16 priority levels used by writable points are modeled after corresponding BACnet priority levels,
using the following conventions, from highest to lowest:
1. Emergency (Manual Life Safety)—Unlinkable input, but available as action (command).
2. Automatic Life Safety
3. User Defined
4. User Defined
5. Critical Equipment Control
6. Minimum On/Off (BooleanWritable meaning only, see “About minimum On and Off times”)
7. User Defined
8. Override (Manual Operator)—Unlinkable input, but available as action (command).
9. Demand Limiting
10. User Defined
11. Temperature Override
12. Stop Optimization
13. Start Optimization
14. Duty Cycling
15. Outside Air Optimization
16. Schedule
Note: Although priority levels are patterned after BACnet, there is no direct linkage to BACnet priorities, even
with BACnet writable proxy points. Priority inputs of all AX writable points are strictly a station-centric
NiagaraAX implementation.

About minimum On and Off times


Each BooleanWritable point has built-in timers to specify minimum on and/or minimum off times. The
respective point properties are “Min Active Time” and “Min Inactive Time.” Usage is optional, and both
properties work independently. Typical usage is to prevent short-cycling of equipment controlled by the
point.
Default property times for a BooleanWritable are all zeros (“00000h 00m 00s”), which effectively disables
a timer. In either property, you can specify any value needed using of a mix of hours (h), minutes (m), and
seconds (s) to enable that timer.
A minimum timer is triggered by a state change transition to active or inactive. This results in the new
state value being stored in the point’s priority array (at priority level 6) for the duration of that timer.
While a minimum timer is in effect, only input changes at a higher priority (5 or above) or an emergency
action can affect the Out value.
For example, a BooleanWritable point controls a fan, with related properties set as follows:
• Min Active Time:00000h 01m 30s
Specifies that once started, the fan must run at least 90 seconds.
• Min Inactive Time:00000h 03m 5s

NiagaraAX-3.x
3-25
User Guide
About composites Chapter 3 – Data and Control Model
Some composite examples May 1, 2007

Specifies that once stopped, the fan must remain stopped at 3 minutes, 5 seconds.
Starting with the fan stopped at schedule level (priority 16), if a user gives it a manual override on (priority
level 8), the fan will run for 90 seconds at priority level 6 (a higher level). After this period, the fan
continues running at the override 8 level for the duration of the override.
During the initial 90 seconds, a different override action (off or auto) will be ineffective—as the higher
priority level 6 remains in control. See “Priority level conventions” on page 3-25.
Once stopped, the point’s minimum off time will keep the fan off at priority level 6 for the specified
duration (in this example, 3 minutes and 5 seconds). During this period, only an emergency command or
input change at In2—In5 can effect further change.

About composites
Currently, a composite is something that Workbench allows you do to virtually any component in a
station, notably control points and objects, and even folders that contain control logic. When you make
a composite, you expose slots of child components in the glyph (object shape) of that parent (composited)
component. This can simplify linking and promote reuse of control logic.

Caution Composites have associated issues—see “Composite issues” on page 3-29. For now, you should avoid
making folder composites in your control logic, and instead use the composite feature only at the point/
object level to expose extension slots (if necessary). See example “Point-level composite” on page 3-26.

When you composite a component (say a control point, meaning its contents), you select specific slots in
child components (say, properties and/or actions of its extensions) to be “exposed” in the “shape” of that
point. Then, when looking at that point in the wire sheet view of its parent folder, you can see exposed
properties of children as linkable slots (and/or available actions).
Note: If you are familiar with Niagara r2, the composite concept is similar to “Bundle” or “Composite” objects,
only more flexible—you can expose slots in containers many levels down, for example. However, please see
the Caution above.

Some composite examples


A few simple examples of composites are included here, as follows:
• Point-level composite
• Folder-level composite
Point-level composite
Figure 3-28 shows a proxy NumericPoint representing a space temperature value that has two extensions:
• an alarm extension (OutOfRangeAlarmExt)
• a history extension (NumericInterval)

Figure 3-28 Property sheet of proxy point with two extensions

In this example, when another system-related BooleanWritable (representing the system fan) has a false
(Off ) status, it is desired that this temperature point be:
• disabled from alarming, and
• disabled from continued history collection

NiagaraAX-3.x
3-26
User Guide
Chapter 3 – Data and Control Model About composites
May 1, 2007 Some composite examples

To achieve these “disable” functions, you must link the controlling source fan out to a slot of each
extension (visible in point’s wire sheet view, but not in the parent wire sheet for the point itself ).
Furthermore, other kitControl objects needed. Without making a composite, the necessary objects and
links may appear as shown in Figure 3-29.

Figure 3-29 Proxy point example without composite

kitControl
Objects

Proxy Numeric
Point

Proxy point’s wire sheet


(with linked extensions

Notice that when looking at the proxy NumericPoint in the wire sheet of its parent folder, it is not
apparent that this point has linked extensions.
By making a composite of the NumericPoint (acting as the container for both the extensions plus the
additional kitControl objects) you can simplify reuse and clarify available links. Figure 3-30 shows the
now-composited NumericWritable linked to the controlling BooleanWritable, and the wire sheet view of
the NumericWritable that contains the needed kitControl objects.

Figure 3-30 Proxy point as composited container

In this example, the exposed input slots in the composite were renamed from “In” to “almInhib” and
“histStop” respectively, to clarify what each does. When looking at the Composite Editor for this example
NumericPoint, it appears as shown in Figure 3-31.

NiagaraAX-3.x
3-27
User Guide
About composites Chapter 3 – Data and Control Model
Some composite examples May 1, 2007

Figure 3-31 Composite Editor for example NumericPoint

Folder-level composite
Note: Please see the related Caution on page 26.
Figure 3-32 shows a simple example of three Math objects chained together, located in a “LogicA” folder.
Together, they perform a “Celsius to Fahrenheit” conversion. A NumericWritable is also shown linked to
the first Math object to test.

Figure 3-32 Simple example of folder before compositing

If this application was needed later, you could copy all 3 linked objects again and insert in another
(perhaps already crowded) wire sheet. However, the middle “Multiply” object reveals an intermediary
result that is distracting. Or, you could just create a new subfolder with only the 3 linked objects and then
link directly to the child objects as needed (however, it would not be obvious from the parent’s wire sheet
that links to children in that folder were established).
It would be better to “encapsulate” this into a single object with only a single “input” (degrees F) and single
“output” (degrees C). You can do something like this by compositing the parent container, in this example
folder “FolderA.”
In this case, you would want to delete the link from the test NumericWritable first, then open the
Composite Editor for the parent component FolderA (Figure 3-33). The Composite Editor lets you
expand the tree of all contained components and “expose” those items of interest.

NiagaraAX-3.x
3-28
User Guide
Chapter 3 – Data and Control Model About composites
May 1, 2007 Composite issues

Figure 3-33 Launching and using the Composite Editor

In this example, only the “In A” of the first math object and the “Out” of the third math object is selected
to be exposed. The Composite Editor provides a tree pane showing slots of points and objects (by clicking
the expand controls), and a slot is exposed by simply double-clicking it. Other controls in the editor are
available to rename, remove, reorder and reverse exposed items, but are not used here. (For more details,
see Making a composite.)
After clicking OK to perform the composite, the item composited (in this example, “LogicA”) shows
exposed slots when viewed in its parent’s wire sheet. Figure 3-34 shows the test NumericWritable now
linked to the composited LogicA folder.

Figure 3-34 Example LogicA folder showing exposed input and output

You could later reopen this folder’s Composite Editor and rename the exposed properties differently,
perhaps “inDegF” and “outDegC” (to make the purpose of the composited folder clearer). This would not
affect the three (child) math objects in any way.

Composite issues
Although composites can simplify linking and make understanding logic flow easier, they always
introduce performance issues. Perhaps the biggest issue is that once you link a dynamic value to a
composite, for example the “out” of a proxy point, it essentially “pinned” into the “subscribed” state. This
means that proxy point will always be polling (regardless of any other usage).
In addition, each item exposed in a composite represents a link, where each link consumes some small
amount of station resources. If used excessively, composites could noticeably reduce the total capacity of
the station.

NiagaraAX-3.x
3-29
User Guide
About composites Chapter 3 – Data and Control Model
Composite issues May 1, 2007

NiagaraAX-3.x
3-30
User Guide
CHAPTER 4
Driver architecture
In any NiagaraAX station, one or more driver networks are used to fetch and model data values. Data is
modeled with proxy points, lower-tier components in that driver’s architecture. For more details, see
“About proxy points” on page 3-18.
To support a driver’s proxy points, the station must have that driver’s network architecture.
The following main topics apply to common driver architecture:
• What are networks?
• About Network architecture
• About the Driver Manager
• Common network components
• About the Device Manager
• Common device components
• Types of device extensions
• About the Point Manager
• About Histories extension views
• About Schedules extension views
• About the Niagara Network

What are networks?


Networks are the top-level component for any NiagaraAX driver. For drivers that use field bus commu-
nications, such as Lonworks, BACnet, and Modbus (among many others), this often corresponds directly
to a physical network of devices. Often (except for BACnet), the network component matches one-to-one
with a specific comm port on the NiagaraAX host platform, such as a serial (RS-232 or RS-485) port,
Lonworks FTT-10 port, or Ethernet port.
Note: A BacnetNetwork component is unique because it supports multiple logical BACnet networks, which
sometimes use different comm ports (e.g. if a JACE-4/5 with BACnet MS/TP, one or more RS-485 ports).
See the Bacnet Guide for more details.
Other “non field bus” drivers also use a network architecture, for example the Ndio (Niagara Direct Input
/ Output) driver has an NdioNetwork to interface to physical I/O points on the host JACE (Ndio applies
only to a JACE model with onboard I/O or with an attached hardware I/O board). Also, “database” drivers
also use a network architecture, for example the “rdbSqlServer” driver includes an RdbmsNetwork.
(Database drivers apply only to Supervisor or SoftJACE hosts.)

Where are networks located?


In any NiagaraAX station, all driver networks are located under the DriverContainer component in the
station’s database (“Drivers” in the root of the station, as shown in Figure 4-1).

NiagaraAX-3.x
4–1
User Guide
About Network architecture Chapter 4 – Driver architecture
Network component hierarchy May 1, 2007

Figure 4-1 DriverContainer in Nav tree

Note: Currently, all stations require a NiagaraNetwork. It may be used to model data in other NiagaraAX
stations. Also, it contains the NiagaraFoxService required for Workbench-to-station communications. For
more details, see “About the Niagara Network” on page 4-49.
Note: By convention, you should keep all driver networks located under the station’s Drivers container—it is a
special component with a view that provides some utility. See “About the Driver Manager” on page 4-4 for
more details.

About Network architecture


To represent any driver in a station database, a consistent “driver framework” using a network archi-
tecture is used. This includes the upper-tier parent network component, and one or more child device
components, each with device ext (extension) child components.
The following sections explain further:
• “Network component hierarchy”
• “About network components”
• “About device components”
• “About device extensions”

Network component hierarchy


Hierarchically, the component parentage is: network, device, device extensions, points (Figure 4-2).

Figure 4-2 Example driver architecture (Bacnet)

To simplify driver modeling, the New Station wizard automatically creates the necessary “Drivers”
container, complete with a NiagaraNetwork (and its required component slots).
• If engineering a JACE station, you invariably add additional driver networks, opening the driver’s
palette and copying the network-level component into Drivers. Or, you can use the New button in
the Driver Manager. Examples are a LonNetwork or BacnetNetwork.
• If engineering a Supervisor (PC) station, the NiagaraNetwork may be the only one needed. Option-
ally, you may add a “database” network (providing the PC host is licensed for it). And, if a PC host
licensed as a direct “integration Supervisor” (e.g. BACnet Supervisor), you may add a driver network
(e.g. BacnetNetwork) directly into its Drivers container.
Note: Regardless of host platform, in most cases the network component is the only item you need to manually
copy from that driver’s palette. After that, you use “manager views” to add child components like devices
and proxy points, even if programming offline.

NiagaraAX-3.x
4-2
User Guide
Chapter 4 – Driver architecture About Network architecture
May 1, 2007 About network components

This enforces the correct component hierarchy under that driver as you engineer, and helps coordinate
mechanisms used by the driver for communications. Exceptions to this rule are noted (as applicable) in
other documentation about NiagaraAX drivers.

About network components


A network component (“generically”: DriverNetwork) is the top-level component for any driver, and by
default has mandatory (frozen) component slots, such as:
• “Health” and other status properties—see “Network status properties” on page 4-6.
• AlarmSourceInfo—see “About network Alarm Source Info” on page 4-6.
• PingMonitor—see “About Monitor” on page 4-7.
• TuningPolicyMap—see “About Tuning Policies” on page 4-8.
Access these slots in the DriverNetwork’s property sheet (Figure 4-3).

Figure 4-3 Example BacnetNetwork property sheet

Note: Depending on the specific driver, there may be additional slots in the DriverNetwork. For example, if a field
bus network, there may be “PollScheduler” and/or “CommConfig” slots. Some of these may require proper
configuration before driver communications occur. See “Additional network components” on page 4-11.
The DriverNetwork is also the parent container for all device-level components. Devices list in tabular
format in the default view for that network, the DeviceManager. See “About the Device Manager” on page
4-12. You use the Device Manager to create and manage device components, and (if the driver provides
this), use discover features.

About device components


A device component (“generically”: DriverDevice) is a second-tier component for any driver, and by
default has mandatory (frozen) component slots, such as:
• “Health” and other status properties—see “Device status properties” on page 4-20.
Note: Depending on the driver type, a device typically has other properties. For example, if a device
under a field bus, it may have a “Device Address” property, or a similar properties. See “Driver-specific
device slots” on page 4-21. Or, starting in AX-3.2, a device may have a “Virtual” gateway slot. See
“Virtual Gateway component” on page 4-21.
• One or more device extensions—for example “Points” (DriverDevicePointExt). See “About device ex-
tensions” on page 4-4.
Typically, the property sheet is the default view for a device component—you can access device
properties, slots, and its extensions using the device’s property sheet (Figure 4-4).

Figure 4-4 Example BacnetDevice property sheet

The DriverDevice is also the parent container for all device extensions. As shown in Figure 4-5, device
extensions (e.g. “Points”) are visible under the device when you expand it in the nav tree.

NiagaraAX-3.x
4-3
User Guide
About the Driver Manager Chapter 4 – Driver architecture
About device extensions May 1, 2007

Figure 4-5 Example BacnetDevice extensions in Nav tree

About device extensions


A device extension is a child of a device, and represents some functionality of the device. Each extension
contains properties and other components. Device extensions are container components, often with one
or more special views. For more details, see “Types of device extensions” on page 4-24.
For example, in any of the field bus networks, each device has a Points extension, the parent container for
proxy points. The default view of the Points extension is the Point Manager, which you use to create and
manage proxy points. See “About the Point Manager” on page 4-28 for details.
Note: Device extensions are required (frozen) components of a device—you cannot delete them. They are created
automatically when you add a device to the station database. This varies from the “point extension” model,
where you individually add/delete extensions under control points and components.

About the Driver Manager


The Driver Manager is the default view for the DriverContainer (showing all networks) in a station.
Figure 4-6 shows an example Driver Manager for a JACE station.

Figure 4-6 Driver Manager

By default, each driver network lists showing its name, a type description, a real-time status field, whether
it is enabled, and a fault cause field (empty, unless the network is in fault).
Within the Driver Manager view, network-level operations are available:
• Double-click a network to go to its Device Manager view. See “About the Device Manager” on page
4-12.
• Right-click a network to see its popup menu, including available actions. Available actions will vary
by driver, but may include “Ping,” “Upload,” and “Download” as examples.
Buttons at the bottom of the Driver Manager provide other functions. See the section “Driver Manager
New and Edit” on page 4-4.

Driver Manager New and Edit


Buttons at the bottom of the Driver Manager include:
• New

NiagaraAX-3.x
4-4
User Guide
Chapter 4 – Driver architecture Common network components
May 1, 2007 Driver Manager New and Edit

• Edit
Note: New and Edit are also on the Driver Manager toolbar and the Manager menu.
New
The New button in the Driver Manager allows you to add a new driver network to the station. This is
equivalent to copying a driver network component from that driver’s palette. The New dialog provides a
selection list for network type, and also the number of networks to add (Figure 4-7).

Figure 4-7 New dialog in Driver Manager

Note: Currently, you are allowed to add multiples of any driver network, as well as any network type (regardless
of the station’s host platform). However, please understand that many networks should be “one-only” per
station, e.g. a NiagaraNetwork and BacnetNetwork. Also, consider that networks shown in the selection list
reflect only the modules available on your Workstation, and may not be present (or supported) on the target
NiagaraAX host.
Edit
The Edit button in the Driver Manager allows you to rename a selected network, or to set it to disabled
(Figure 4-8).

Figure 4-8 Edit dialog in Driver Manager

Caution Whenever you set a network to disabled (Enabled = false), the network component and all child driver
components (all devices, proxy points, etc.) change to disabled status. If a field bus driver, communications
routines like polling and device status pings also suspend. By default, disabled status color is gray text on
a light gray background.

This network-wide action may be useful for maintenance purposes. Note that Enabled is also individually
available at the device-level and proxy point-level, using the Edit button/dialog in the Device Manager or
Point Manager, respectively.
A disable at the device-level disables all child (proxy points), as well as polling to that points under that
device. A disable at the proxy-point level disables the single point.

Common network components


Each driver network contains common properties and other components. This section describes those
items.

NiagaraAX-3.x
4-5
User Guide
Common network components Chapter 4 – Driver architecture
Network status properties May 1, 2007

• Network status properties


• About network Alarm Source Info
• About Monitor
• About Tuning Policies
• Additional network components

Network status properties


Status
The Status property of a network indicates if the driver is capable of communications—for any
configured driver, network Status is typically “{ok}.” However, when adding some networks, the initial
Status may be fault, as shown in Figure 4-9. This might mean a communications port is yet unassigned,
or there is a port conflict.
Note: A fault status also occurs if the host platform is not properly licensed for the driver being used. If a network
fault, see the Fault Cause property value for more details.

Figure 4-9 Network status properties

Enabled
By default, network Enabled is true—you can toggle this in the property sheet, or in the Driver Manager
(by selecting the network and using the Edit button). See related Caution on page 5.
Health
Network Health contains historical properties about the relative health of the network in the station,
including historical timestamps.

About network Alarm Source Info


A network’s Alarm Source Info slot holds a number of common alarm properties (Figure 4-10). These
properties are used to populate an alarm if the network does not respond to a monitor ping. See “About
Monitor” for details on the monitor mechanism.

Figure 4-10 Example Network Alarm Source Info properties

NiagaraAX-3.x
4-6
User Guide
Chapter 4 – Driver architecture Common network components
May 1, 2007 About Monitor

Alarm Source Info properties work the same as those in an alarm extension for a control point. For
property descriptions, see “About alarm extension properties” on page 7-3.
Note: Each child device object also has its own Alarm Source Info slot, with identical (but independently
maintained) properties. See “Device Alarm Source Info” on page 4-20.

About Monitor
A network’s Monitor slot holds configuration for the “ping mechanism” used by the driver network. In
the network’s property sheet, expand the Monitor slot to see configuration (Figure 4-11).

Figure 4-11 Example Monitor properties

Monitor provides verification of the general health of the network, plus the network’s “pingables”
(typically, devices) by ensuring that each device is minimally “pinged” at some repeating interval.
• If a device responds to the monitor ping, device status is typically “ok,” and normal communications
routines to it (proxy-point polling, plus reads of device schedules, trends, etc. if supported by the
driver) proceeds normally. Typically, this applies even if the device returns an error response to the
ping, because this indicates that the device is “alive.”
• If a device does not respond to the monitor ping, it is marked with a down status—this causes normal
communications routines to that device to be suspended. Upon the next successful monitor ping to
that device, device status typically returns to “ok” and normal communications routines resume.
Note: Whenever successful communications occur to a device, that device component’s Health property is updated
with the current time. The network ping Monitor will only “ping” the device if the time of last health verifi-
cation is older than the ping frequency. Therefore, in normal operation with most drivers, the proxy point
polling mechanism actually alleviates the need for the monitor ping, providing that the ping frequency is
long enough. Also, in most drivers if a point poll request receives no response (not even a “null”) from a
device, a “ping fail” condition is immediately noted, without waiting for the monitor ping interval.
The following sections provide more Monitor details:
• Monitor properties
• Monitor considerations by driver
Monitor properties
The monitor ping properties are as follows:
• Ping Enabled
• If true, (default) a ping occurs for each device under the network, as needed.
• While set to false, device status pings do not occur. Moreover, device statuses cannot change
from what existed when this property was last true.
Note: It is recommended you leave Ping Enabled as true in almost all cases.
• Ping Frequency
Specifies the interval between periodic pings of all devices. Typical default value is every 5 minutes
(05m 00s), you can adjust differently if needed.
• Alarm On Failure
• If true (default), an alarm is recorded in the station’s AlarmHistory upon each ping-detected de-
vice event (“down” or subsequent “up”).
• If false, device “down” and “up” events are not recorded in the station’s AlarmHistory.
• Startup Alarm Delay
Specifies the period a station must wait after restarting before device “down” or “up” alarms are gen-
erated. Applies only if the Monitor’s property Alarm On Failure is true.

NiagaraAX-3.x
4-7
User Guide
Common network components Chapter 4 – Driver architecture
About Tuning Policies May 1, 2007

Monitor considerations by driver


The monitor mechanism used by a specific driver may have unique characteristics.
• For example, in a BacnetNetwork, any monitor ping is directed to the device’s BACnet “Device Ob-
ject,” and in particular, to its “System_Status” property. In this unique case, a received response of
“non-operational” is evaluated the same as getting no response at all!
• Or, in any Modbus network, when a monitor ping message is sent, it is directed to the device’s “Ping
Address,” which is configured by several properties in the ModbusDevice object.
Other drivers may have specific considerations for the Monitor ping mechanism. For more information,
refer to the “Device Monitor Notes” section within any NiagaraAX driver document.

About Tuning Policies


A network’s Tuning Policies holds one or more collections of “rules” for evaluating both write requests
(e.g. to writable proxy points) as well as the acceptable “freshness” of read requests from polling. In some
drivers (such as Bacnet), also supported is association to different poll frequency groups (Slow, Normal,
Fast). Tuning policies are important because they can affect the status of the driver’s proxy points.
In the network’s property sheet, expand the Tuning Policies (Map) slot to see one or more contained
Tuning Policies. Expand a Tuning Policy to see its configuration properties (Figure 4-12).

Figure 4-12 Example Tuning Policies Map (Bacnet)

Note: Some driver networks do not have Tuning Policies, for example an RdbmsNetwork for a database driver.
Also, the NiagaraNetwork has greatly simplified Tuning Policies.
By default, a driver’s TuningPoliciesMap contains just a single TuningPolicy (“Default Policy”). However,
you typically create multiple tuning policies, changing those items needed differently in each one. Then,
when you create proxy points under a device in that network, you can assign each point (as needed) to
the proper set of “rules” by associating it with a specific tuning policy.
As a simple example (under a BacnetNetwork), you could duplicate the default tuning policy twice,
naming the first copy “Slow Policy” and the second copy “Fast Policy.” Then, in each copy change the “Poll
Frequency” property from “Normal” to “Slow” or “Fast,” respectively. You would then have 3 available
(and different) poll frequency groups to pick from when you create and edit proxy points.
The following sections provide more Tuning Policy details:
• Tuning Policy properties
• Tuning Policy considerations by driver
Tuning Policy properties
Tuning Policy properties for typical field bus drivers are as follows:
• Min Write Time
Applies to writable proxy points, especially ones that have one or more linked inputs. Specifies the
minimum amount of time allowed between writes. Provides method to throttle rapidly changing val-
ue so that only the last value is written. If property value is 0 (default), this rule is disabled (all value
changes attempt to write).
• Max Write Time
Applies to writable proxy points. Specifies the maximum “wait time” before rewriting the value, in
case nothing else has triggered a write. Any write action resets this timer. If property value is 0 (de-
fault), this rule is disabled (no timed rewrites).

NiagaraAX-3.x
4-8
User Guide
Chapter 4 – Driver architecture Common network components
May 1, 2007 About poll components

• Write On Start
Applies to writable proxy points. Determines behavior at station startup.
• If true, (default) a write occurs when the station first reaches “steady state.”
• If set to false, a write does not occur when the station reaches “steady state.”
• Write On Up
Applies to writable proxy points. Determines behavior when proxy point (and parent device) transi-
tions from “down” to “up.”
• If true, (default) a write occurs when the parent device transitions from down to up.
• If set to false, a write does not occur when the parent device transitions from down to up.
• Write On Enabled
Applies to writable proxy points. Determines behavior when a proxy point’s status transitions from
“disabled” to normal (enabled). Note this status can be inherited globally if the parent device was set
to disabled (or network-wide if driver network was set to disabled).
• If true, (default) a write occurs when writable point transitions from disabled.
• If set to false, a write does not occur when writable point transitions from disabled.
• Stale Time
Applies to all proxy points.
• If set to a non-zero value, points become “stale” (status stale) if the configured time elapses without
a successful read, indicated by Read Status “ok.”
• If set to zero (default), the stale timer is disabled, and points become stale immediately when unsub-
scribed.
Note: By default, proxy point status “stale” is indicated by tan background color. In addition, stale
status is considered “invalid” for any downstream-linked control logic. For more details, see “About
“isValid” status check” on page 3-18.
• Poll Frequency
(May not exist in some drivers) Applies to all proxy points. Provides a method to associate the tuning
policy with one of 3 Poll Rates available in the network’s Poll Service: Fast Rate, Normal Rate, or Slow
Rate. The default poll frequency is “Normal.”
Note: Depending on the driver, there may be a single “Poll Service” (or “Poll Scheduler”) slot under
the network, or as in the case of a BacnetNetwork, a separate “Poll Service” for each configured port
(IP, Ethernet, Mstp) under its BacnetComm > Network container. The NiagaraNetwork uses subscrip-
tions instead of polling.
Tuning Policy considerations by driver
Tuning policies used by a specific driver may have unique characteristics. For example, under a Niagar-
aNetwork, its TuningPolicy has only two properties: Min Update Time and Max Update Time. For more
details, see “NiagaraNetwork component notes” on page 4-50.
Other drivers may have specific considerations for tuning policies. For more information, refer to the
“Tuning Policy Notes” section within any NiagaraAX driver document.

About poll components


Many driver networks use a single polling mechanism (Poll component, named “Poll Service” or “Poll
Scheduler”) adjusted at the network level in the station. In the case of a BacnetNetwork, a separate
BacnetPoll is used for each port under the BacnetStack’s Network component, as shown in Figure 4-13.
• Poll scheduler operation
• Poll component properties
Note: The Niagara Network does not use polling, but uses subscriptions only.

NiagaraAX-3.x
4-9
User Guide
Common network components Chapter 4 – Driver architecture
About poll components May 1, 2007

Figure 4-13 Example BacnetPollService

Poll scheduler operation


Regardless of driver type, the Poll Service provides a “poll scheduler” that operates in the same fashion
via an ongoing scan of four “buckets” to service “pollables” as follows:
• The poll scheduler allocates three “rate group” buckets, one for each rate group (Slow, Normal, Fast).
“Pollables” (mainly proxy points) are associated with one of three “rate” groups (Slow, Normal, Fast)
via either:
• assigned Tuning Policy in each point’s proxy extension (BacnetNetwork)
• assigned Poll Frequency in each point’s proxy extension (drivers other than Bacnet)
In the case of device objects, a Poll Frequency property is used to select the rate directly.
• A fourth “dibs stack” bucket is allocated for pollables that transition to a subscribed state. This may
be a “temporary subscription,” such as results when viewing unlinked proxy points (without alarm
or history extensions) in Workbench or a browser. Or, it may occur when a permanently subscribed
point is first polled (thereafter, it is no longer “dibs stack-polled”).
Priority of polling by the scheduler occurs in this fashion:
1. Dibs stack. When first subscribed, a pollable moves to the top of the dibs stack (first dibs). The poll
scheduler always polls the dibs bucket before doing anything else. The dibs stack is polled last-in,
first-out (LIFO). As long as entries are in the dibs stack, they are polled as fast as possible with no
delays.
2. When the dibs stack is empty, the scheduler attempts to poll the components in each “rate” bucket
using an algorithm designed to create uniform network traffic.
For example, if the fast rate is configured to 10 seconds and there are 5 components currently sub-
scribed in the fast bucket, then the scheduler will attempt to poll one component every 2 seconds.
Note: Every ten seconds the poll scheduler rechecks the buckets for configuration changes. So if a pollable’s config-
uration is changed from slow to fast, it takes at most ten seconds for the change to take effect.
Poll statistics are also updated every ten seconds. You can manually reset the statistics by issuing the Reset
Statistics action to the Poll Service (Figure 4-14).

Figure 4-14 Reset Statistics action of PollService

NiagaraAX-3.x
4-10
User Guide
Chapter 4 – Driver architecture Common network components
May 1, 2007 Additional network components

Poll component properties


Properties of the poll component for typical field bus drivers include four writable properties and various
read-only statistics properties, as follows:
•Poll Enabled
• If true (default), polling occurs for all associated pollables (proxy points, devices) under the net-
work component, or if a BacnetPoll, under that BacnetStack, Network, Port.
• While set to false, polling is suspended and further value updates from polling do not occur.
Note: PollService actions Enable and Disable allow access to this property, see Figure 4-14.
• Fast Rate
Target poll interval for pollables assigned to this rate group (default often is 1 second).
• Normal Rate
Target poll interval for pollables assigned to this rate group (default often is 5 seconds).
• Slow Rate
Target poll interval for pollables assigned to this rate group (default often 30 seconds).
Note: All remaining properties are read-only statistics properties.
• Statistics Start
Timestamp reflecting either the last manual reset of poll statistics, or if statistics have not been reset,
the first “steady state” time immediately following the last station restart.
• Average Poll
Average time spent in each poll.
• Busy Time
Percentage of time spent busy doing polls.
• Total Polls
Total number of polls made and time spent waiting for polls to execute.
• Dibs Polls
Total number of polls made processing the dibs stack.
• Fast Polls
Total number of polls processing fast queue.
• Normal Polls
Total number of polls processing normal queue.
• Slow Polls
Total number of polls processing slow queue.
• Dibs Count
Current and average number of components in dibs stack.
• Fast Count
Current and average number of components in fast queue.
• Normal Count
Current and average number of components in normal queue.
• Slow Count
Current and average number of components in slow queue.
• Fast Cycle Time
Average cycle time of the fast queue.
• Normal Cycle Time
Average cycle time of the normal queue.
• Slow Cycle Time
Average cycle time of the slow queue.
Note: Depending on driver, additional statistics properties may be present in a Poll component. For example, a
BacnetPoll has additional properties Device Count, Point Count, and Object Count. See the specific driver
document for unique Poll Service features or notes.

Additional network components


Depending on the driver type, a network typically includes other components that define communica-
tions settings. Access these components on the property sheet of the network. More details are in the
following subsections:
• About communication components
• About driver-specific properties

NiagaraAX-3.x
4-11
User Guide
About the Device Manager Chapter 4 – Driver architecture
Additional network components May 1, 2007

About communication components


Communication components contain properties and possibly other components that configure and
represent communications ports, or other protocol layers. These components will vary from driver to
driver. Often, you must configure (or verify) these components to allow online operations.
For example, the NiagaraNetwork contains the NiagaraFoxService, a BacnetNetwork contains a Bacnet-
Stack (Bacnet Comm), a LonNetwork contains LonCommConfig (Figure 4-15).

Figure 4-15 LonNetwork’s LonCommConfig component

See the driver document for specific details on configuring a network’s communications components.
About driver-specific properties
Depending on the driver, other specific properties (or even component containers) may be found in the
network component’s property sheet.
For example, the NiagaraNetwork has container components Fox Service and History Policies, a
ModbusAsyncNetwork contains a number of properties for timeouts and byte-order conventions, and a
LonNetwork contains a LonNetmgt component with various child properties (Figure 4-16).

Figure 4-16 LonNetwork’s LonNetmgmt component

For more details see “About the Niagara Network” on page 4-49, or the corresponding driver document
for driver-specific properties and components of a network.

About the Device Manager


The Device Manager is the default view for any network container (for a NiagaraNetwork only, this view
is called the Station Manager). The Device Manager is a table-based view, where each row represents a
unique device (Figure 4-17). When building a network in the station, you use this view to create, edit, and
delete device-level components.

NiagaraAX-3.x
4-12
User Guide
Chapter 4 – Driver architecture About the Device Manager
May 1, 2007 Device New Folder and New

Figure 4-17 Example Device Manager (BacnetDeviceManager)

Following station configuration, this view provides a status and configuration summary for all devices
networked using that driver. The “Exts” column provides quick double-click access to device extensions,
such as Points for proxy points, Schedules for imported schedules, and so forth (see “Types of device
extensions” on page 4-24 for details). You can also use it to issue actions to selected devices, such as “ping,”
upload, and so forth.
At the bottom of the view, buttons “New Folder” and “New” let you create new device folders and devices
in the station database. The “Edit” button lets you edit one or more selected devices in the station
database. If the driver supports online “device learning,” buttons “Discover,” and “Match” are also
typically available. Finally, additional buttons may be available, depending on the driver.
For more details, see:
• Device New Folder and New
• Device Edit
• About Device Discover, Add and Match (Learn Process)
• Manager table features

Device New Folder and New


Buttons New Folder and New exist in the Device Manager view of a device-level component under any
driver network. Use of New Folder is optional. Typically, you use New only if the driver does not support
online discovery, or if you are programming offline.
Note: New Folder and New are also on the Device Manager toolbar and the Manager menu.
New Folder
The New Folder button in the Device Manager adds a special “DeviceFolder” component you can use
to organize devices. This is equivalent to copying that same component from that driver’s palette. A
Name dialog lets you name the folder before it is created (Figure 4-18).

Figure 4-18 Example New Folder dialog in Device Manager

When you click OK, a new DeviceFolder component is added under the network.
Note: A driver’s DeviceFolder component is different than a “normal” Folder component, as it provides that
driver’s Device Manager view by default (just like the parent network component). Also, an “All Descen-
dants” command is available from the root Device Manager, which allows you to see all devices in the
network.

NiagaraAX-3.x
4-13
User Guide
About the Device Manager Chapter 4 – Driver architecture
Device New Folder and New May 1, 2007

All Descendants
When in the Device Manager of a device folder, it is “unaware” of devices in other device folders (or in the
root of the network component). However, from the root Device Manager view (of the network), you can
“flatten” the folder structure to view all devices by selecting it from the Manager menu (Figure 4-19) or
by simply clicking the “All Descendants” tool on the toolbar (Figure 4-20).
Note: Be aware that in a large network, with many device folders and devices, using the all descendants feature
may decrease performance. This might result from so many devices/points being subscribed.

Figure 4-19 Manager menu “All Descendants” command

Figure 4-20 Device Manager “All Descendants” tool on toolbar

Note: If you are using device folders, and you click on a table column to resort devices, please be aware that any
device-to-device folder organization is lost during that view. However, you can always see contents of device
folders clearly in the Nav tree, and again when returning to the Device Manager view from another view.
New
The New button in the Device Manager allows you to add a new device component to the station. This is
equivalent to copying a device component from that driver’s palette. The New dialog provides a selection
list for device type, and also the number of devices to add (Figure 4-21).

Figure 4-21 Example New dialog in Device Manager

When you click OK, a new device-level component is added under the network. You usually need to edit
specific details for each new device, including addressing parameters for communications.

NiagaraAX-3.x
4-14
User Guide
Chapter 4 – Driver architecture About the Device Manager
May 1, 2007 Device Edit

Device Edit
In the Device Manager view, you can edit any device component in the station database by simply double-
clicking it. (Editing does not apply to device folders.)
Edit
The Edit dialog appears with the device listed (Figure 4-22).

Figure 4-22 Example Edit dialog in Device Manager (single device)

Note: The Edit dialog for a device component only shows some of the device component’s properties. Typically,
these are key properties required for communications, and will vary among drivers (to access all properties
of the device component, go to its property sheet).
When a single device is selected in the Edit dialog, you can edit any property except Type (it was fixed when
you added the device). Included is the ability to edit the Name of the device in the station. This is equivalent
to the right-click Rename command on the component.
The following related topics also apply:
• Device “gang” edits
• Manager table features
Device “gang” edits
The Edit button in the Device Manager allows you to edit one or more device components in the station
in a single dialog. Before clicking Edit, use standard Windows keyboard controls to highlight (select)
multiple devices (e.g. hold down Ctrl key and click desired devices).
Note: Edit is also available on the Device Manager toolbar and the Manager menu.
The “gang” edit feature is useful for making the same change in multiple (selected) devices. For example,
as shown in Figure 4-23, you can change “Poll Frequency” in multiple devices at the same time (versus
editing this individually).

NiagaraAX-3.x
4-15
User Guide
About the Device Manager Chapter 4 – Driver architecture
About Device Discover, Add and Match (Learn Process) May 1, 2007

Figure 4-23 Example “gang edit” in Edit dialog in Device Manager

When you have the Edit dialog open with multiple devices, you can also click on select ones to make
individual edits (e.g. Name, or any other editable property), during the same dialog session where you
made “gang” property edits. When you click OK, all the changes are applied to the device components as
made during your Edit session. For more details, see “About gang edits.”
Note: When you have multiple devices selected in the Edit dialog, properties that must be unique (such as Name)
are automatically unavailable (dimmed). However, note that some properties that typically should be
unique (often address properties) may still be available for “gang edit,” as this rule is not automatically
enforced. Typically, when editing these properties, you should verify only a single device component (row)
is highlighted in the table.

About Device Discover, Add and Match (Learn Process)


Online “device learns” are possible using the Device Manager for many drivers, for example the Niagar-
aNetwork, BacnetNetwork, LonNetwork, and NdioNetwork. Whenever available, this method is the
easiest way to accurately add device components to the station database.
Note: With the exception of a “Quik Learn” option in a LonNetwork, any device learn in NiagaraAX is a two-step
process where you first:
1. Discover device candidates for inclusion in the station database.
2. Select and Add from those candidates, creating device components in the network.
If you already added devices using New, you can also Match candidates to existing devices. For more
details see “Match (Device)” on page 4-18.
The Device Manager reinforces this process by providing two separate panes in the view whenever you enter
“Learn Mode.” See “About Learn toggle” on page 4-16.
About Learn toggle
Any driver that offers online “learns” of devices, points, and possibly schedules and log data (histories)
provides specialized “Manager” views. Any such view offers both a two-pane view (Learn Mode) and a
single-pane view (Database only).
At any time, you can toggle between Learn Mode and the single-pane (Database) view by clicking the
Learn Mode tool in the toolbar (Figure 4-24), or using the Learn Mode command in the Manager menu.
Also, note that the Discover tool (binoculars) is next to the Learn Mode tool.

Figure 4-24 Learn Mode toggle tool in any Manager

Note: Whenever in Learn Mode of any Manager view (DeviceManager, PointManager, and so forth) you can drag
the border between the two panes to resize, as necessary.

NiagaraAX-3.x
4-16
User Guide
Chapter 4 – Driver architecture About the Device Manager
May 1, 2007 About Device Discover, Add and Match (Learn Process)

Discover
The Discover button is available in the Device Manager only if the driver supports online discovery.
When you click Discover, the Device Manager view splits into two panes (Learn Mode), and at the same
time typically launches a discovery “job” (Figure 4-25).

Figure 4-25 Discover splits Device Manager view

Note: In some drivers, an intermediate dialog may appear before the discovery job begins. For example, in a
discover for a BacnetNetwork, a “Configure Device Discovery” dialog allows you to limit possible ranges of
devices, before discovery begins. For more details, see the Bacnet Users Guide.
The two panes in the Device Manager operate as follows:
• Discovered (top pane)
Lists devices discovered on the driver’s network, as candidates. Any device found that already exists
in the station database appears “ghosted” (faintly listed). A job “progress bar” is also included on top
of the Discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.
• Database (bottom pane)
Lists devices and device folders that are currently in the station database.
Add
The Add button is available in the Device Manager in Learn Mode when you have one or more devices
selected (highlighted) in the top Discovered pane. When you click Add, an Add dialog appears that allows
you to edit items before the device component(s) are created in the station database (Figure 4-26).

Figure 4-26 Add dialog from Add button in Device Manager

NiagaraAX-3.x
4-17
User Guide
About the Device Manager Chapter 4 – Driver architecture
Match (Device) May 1, 2007

The Add dialog is nearly identical to the device Edit dialog, but allows you to edit Type as well as other
device properties. Often, device address properties in the Add dialog already have acceptable values for
operation (otherwise, communications to that device would not have occurred). Often, you change only
Name, unless you know other settings you wish to change. You can always Edit the device component(s)
after you click OK and add them to your station.
Note: When you have one or more devices selected in the top Discovered pane, an Add tool is also available on
the toolbar (“plus” symbol), as well as a command in the Manager menu. Also, you can simply double-click
a discovered device to bring it up in the Add dialog.

Match (Device)
Device Match is a feature that may be useful when you have an application replicated many times at the
device level, or if you have programmed offline using the New device feature.
• In the first case (replicated device application), you could discover and add one typical device, and
complete further engineering under it (learning and adding proxy points, point extensions, creating
other control logic, adding Px views, including all self-contained links and bindings).
Then, you could duplicate that typical device component (choosing Duplicate in its right-click
menu) for as many identical devices as exist. The Match feature now allows you to match each du-
plicated device component to a unique discovered device, saving engineering time. This repopulates
the necessary properties of the duplicated device object with the correct values from the discovered
device.
• In the second case (offline programming) where a connection to the actual device network is un-
available, you can manually add New devices and begin station engineering of a driver network. Typ-
ically, most component creations under a driver network are possible (including all levels) using the
New feature in the various “manager” views (Device Manager, Point Manager, other device exten-
sion managers). Or, you can add saved applications (from the device level on down) and edit as nec-
essary. Then, when online with the driver network later, you could use Match to “sync” to existing
components (device-level, proxy points, and so forth).
The Match button in the Device Manager becomes available when in Learn Mode, and you have:
1. Selected one device candidate in the top (Discovered) pane.
2. Selected one existing device component in the bottom (Database) pane.
Note: In this case, the toolbar also has an available Match tool, and the Manager menu has a Match command.
When you click Match, the Match dialog appears, as shown in Figure 4-27.

Figure 4-27 Match dialog example in Device Manager

Note: Match is strictly a “one-to-one” function for “discovered-to-database”—note that it is unavailable any time
you have multiple items selected either in either the top or bottom pane.
The Match dialog is nearly identical to the single-device Edit dialog, and typically provides the
“discovered” device address values. Often, most properties in the Match dialog already have acceptable
device address values required for operation (otherwise, communications to the discovered device would
not have occurred). You can always Edit the device component after you click OK and add it to your
station.

NiagaraAX-3.x
4-18
User Guide
Chapter 4 – Driver architecture Common device components
May 1, 2007 Manager table features

Manager table features


As with other table-based views in Workbench, manager views of various components under a driver’s
network provide common features that can be useful (see “About table controls” for a general overview).
These features apply to various component views found throughout a station’s driver architecture, for
example, the Driver Manager, Device Manager, Point Manager, History Import Manager, and so on.
Of particular utility are the following table features:
• Table options menu
• Column resorting
Table options menu
Use the table options drop-down menu (small control in upper table right, as shown in Figure 4-28) to
perform any of the following:

Figure 4-28 Table options menu in Device Manager

• Reset Column Widths


Useful if you manually changed widths of columns, and now some contents are hidden (even after
scrolling). The reset restores all columns to widths that accommodate contents.
• Export
Produce the standard Export dialog, where you can select exporting the table to PDF, text, HTML,
or CSV (comma separated variable). See “About table exports” for more details.
• select or clear columns for display
Depending on the driver, a certain “default” collection of columns is pre-selected for display in the
Manager view. You can change that by checking or clearing column headings.
Column resorting
Click on any column header to toggle the table sort between ascending (first click) and descending
(second click). The current table sort is indicated by a small triangle in the sorting column.

Common device components


Each device component has some number of required (frozen) slots and properties, which will vary by
driver. However, the following categories of components and slots are typical to most device-level
components:
• Device status properties
• Device Alarm Source Info
• Device address properties
• Driver-specific device slots
Also, a device component has one or more device extensions, which are visible when you expand the
device in the Nav tree. For more details, see “Types of device extensions” on page 4-24.
Note: Starting in AX-3.2, some drivers may implement “virtual components,” which typically adds a frozen
“Virtual” gateway slot under the device component. See “Virtual Gateway component” on page 4-21.

NiagaraAX-3.x
4-19
User Guide
Common device components Chapter 4 – Driver architecture
Device status properties May 1, 2007

Device status properties


Status
The Status property of a device indicates whether it is communicating—good status is “{ok}” (no status
flags). However, if using New to add a device, initial Status may be down or fault, as shown in Figure 4-
29. This could mean device address properties are yet unassigned, or are misconfigured.
Note: If a device status fault, see the Fault Cause property value for more details.

Figure 4-29 Device status properties

Status of devices is verified by successful polling, or the device status “ping” as configured in the network
component’s Monitor configuration. See “About Monitor” on page 4-7.
From the Device Manager view, you can also right-click a device, and from the popup menu select
Actions > Ping to manually verify communications.
Depending on conditions, a device may have one of various status flags set, including fault or disabled, or
others in combination, such as down, alarm, stale, and/or unackedAlarm. In the Device Manager, non-
ok status in indicated for any device by row color other than white.
Enabled
By default, device Enabled is true—you can toggle this in the property sheet, or in the Device Manager
(by selecting the device and using the Edit button). See Caution on page 5.
Health
Device Health contains historical properties about the last successful message received from the device,
including timestamps.

Device Alarm Source Info


A device’s Alarm Source Info slot holds a number of common alarm properties (Figure 4-10). These
properties are used to populate an alarm if the device does not respond to a monitor ping. This ping is
configured at the network level—see “About Monitor” on page 4-7.

Figure 4-30 Example Device Alarm Source Info properties

NiagaraAX-3.x
4-20
User Guide
Chapter 4 – Driver architecture Common device components
May 1, 2007 Device address properties

These properties work the same as those in an alarm extension for a control point. For property descrip-
tions, see “About alarm extension properties” on page 7-3.
Note: Each parent network component also has its own Alarm Source Info slot, with identical (but independently
maintained) properties. See “About network Alarm Source Info” on page 4-6.

Device address properties


Depending on the driver, a device-level component typically has one or more address type properties,
accessible from the device’s property sheet. For example, a BacnetDevice has an Address property with 3
separate fields (Figure 4-31).

Figure 4-31 Example device address properties

In the case of a Lon device (DynamicDevice) various address parameters are stored under a DeviceData
component, itself visible when you expand the device in the Nav tree. For more details on device-level
address properties, see the specific driver document.
Poll Frequency
Common to most devices is a Poll Frequency property, typically located below device address properties.
It provides a drop-down menu to select among 3 poll frequencies, as configured in the network’s Poll
Service. For more details, see “About poll components” on page 4-9.

Driver-specific device slots


A device-level component typically has slots unique to that driver, accessed on its property sheet. For
example, a Lon device has a large collection of nv slots (network variables nvi, nvo, and nci), each as an
expandable container holding numerous values. A BacnetDevice holds a number of properties that define
Bacnet “services” that it supports. For details, see the specific driver document.

Virtual Gateway component


Starting in AX-3.2, the ability for a device-level component to have a Virtual gateway child was
added. This is in addition to the “standard” collection of slots for device-level components (See “About
device components” on page 4-3.).
Note: Baja virtual components are not specific to just drivers. However, the original need for virtual components
(which are transient, and do not permanently reside in a station’s database) and a special “gateway”
component to access them, came about from driver “use case needs.” It is possible that other applications
for virtual gateways (and virtual components) may evolve in future builds of NiagaraAX.
In the NiagaraAX driver architecture, a device’s virtual gateway provides access to “virtual components”
in the station’s “virtual component space,” specific to that device. Currently, only the BACnet driver has
implemented virtual components.
About virtual component spaces
A NiagaraAX station contains object “types,” each within a defined “space” at a top level (Figure 4-32).

Figure 4-32 Top level object spaces

Object types in these spaces are:


• Components — in the component space under a Config node (regular component space).
• Files — in the files space under a Files node.
• Histories— in the histories space under a History node.

NiagaraAX-3.x
4-21
User Guide
Common device components Chapter 4 – Driver architecture
Virtual Gateway component May 1, 2007

A station uses these objects when running, and when it is stopped they persist—components in the
station’s database (config.bog), files in the station’s directory, and histories within the history database.
Virtual component spaces are different, in the following ways:
• There can be multiple virtual component spaces—each belongs to a different virtual gateway, which
are specialized components in the station’s component space (under Config).
• A virtual component space is a mapping of virtual components, organized in a tree fashion, created
at runtime when its virtual gateway is “started” (accessed).
• Virtual components are transient components created in the station only when needed. When no
longer necessary (i.e. become unsubscribed) they are automatically removed in the running station.
When the station is stopped, virtual components do not exist. This permits monitoring applications
in cases where normal proxy points would use too many resources.
• Virtual components have limitations, and should not be confused with other components (such as
proxy points). For example, links to and from virtual components, use of point extensions (history,
alarm, etc.), and typical copy/paste operations are not supported.
About virtual gateways
Virtual gateways reside in the station database, along with other components. Each virtual gateway
provides the link between the normal component space and its own virtual components. In the initial
“driver application” of virtual components, each device component in a driver network has its own virtual
gateway, as shown in Figure 4-33 for a BacnetDevice in the AX-3.2 bacnet palette.

Figure 4-33 One virtual gateway per device

This is a logical division of gateways (separating data by its source device). However, this is not to say that
future virtual component applications will always use this method of hierarchy for virtual gateways.
Gateway activation Unlike with a device’s extensions, there is no special view for a virtual gateway—you
simply double-click it to access the gateway’s property sheet, or expand it in the Nav tree. When you do
this for a device’s virtual gateway, a “driver-specific” call is made to the device to gather data, where the
results appear as child virtual components.
In the case of the BACnet driver, expanding a virtual gateway fetches “an object list,” where each BACnet
object in the device appears as a virtual component (slot) under the gateway. See Figure 4-34.

Figure 4-34 BacnetVirtualGateway functions as BACnet object list

As shown in Figure 4-35, you can expand any virtual component to see its “virtual property sheet,”
resulting in another incremental call to the device.

NiagaraAX-3.x
4-22
User Guide
Chapter 4 – Driver architecture Common device components
May 1, 2007 Virtual Gateway component

Figure 4-35 Property sheet of BacnetVirtualComponent

This “virtual view” property sheet reflects dynamic values, noting that virtual components are transient
vs. persisted components—meaning they are dynamically created (and subscribed) only when accessed,
and are not stored in the station database.
Note: Virtual components have limitations when compared with other components (such as proxy points). For
example, links to and from virtual components, use of point extensions (history, alarm, etc.), and typical
copy/paste operations are not supported.
Property sheet access of virtual components (as shown in Figure 4-35) can provide utility when config-
uring or commissioning a device, especially for “one time” modification of parameters (assuming that the
device permits writes). For example, you could quickly adjust an alarm limit setting, whereas (otherwise)
you would typically have to create a specific proxy point in the station database to do this.
The other common application for virtual components is for real-time monitoring of values in Px views
(graphics). See the next section “Virtual components in Px views” for more details.
Virtual components in Px views The AX-3.2 and later feature of “virtual components” provides utility
when reviewing and making “one-time” property value adjustments for objects in devices, as described
in “Gateway activation” on page 4-22. In addition, virtual components can be used to show real-time
values in Px views—at least when the built-in features of proxy points (right-click actions, status color-
ation) are not required.
Note: A virtual gateway cannot have its “own” Px view, but you can use its child virtual components in Px views
for other components, for example on the device component itself, or its Points extension, and so on.
The only persisted (permanent) record of such a virtual component is its ord in the Px binding to it, which
uses a “Virtual ord syntax” that includes the virtual gateway within it (and activates it at runtime). This
ord is automatically resolved when you drag a virtual component onto the Px page, and make your
property selection in the popup Px “Make Widget” dialog, as shown in the example in Figure 4-36.

Figure 4-36 Dragging virtual component into Px editor view, with resulting Make Widget popup

NiagaraAX-3.x
4-23
User Guide
Types of device extensions Chapter 4 – Driver architecture
Virtual Gateway component May 1, 2007

The selected property in the virtual component displays in the Px widget, for example in a “field editor”,
as shown in Figure 4-37.

Figure 4-37 BacnetVirtualComponent in Px view

Note: For complete details on Px views and widget editing, see “About Px Editor” on page 8-5.
Virtual ord syntax The general syntax for a “virtual ord” uses a specialized form as follows:
<ord to VirtualGateway>|virtual:/virtualPath
where virtualPath represents some hierarchy of virtual components and child properties.
For example, for BacnetVirtualComponents, the general virtual path syntax is:
<ord to VirtualGateway>|virtual:/objectType_Instance/propertyName
Or in the special case of an arrayed property:
<ord to VirtualGateway>|virtual:/objectType_Instance/propertyName/elementN
where N is the property array index.
For specific virtual ord details, refer to the corresponding driver document section about “Virtual Points”.

Types of device extensions


When you create a device-level component (New, Add, or simply drop from the driver’s palette), you may
notice that it has default children, collectively called device extensions. Device extensions group various
functions of a device.
Note: For any device, its extensions are typically visible both in the Nav tree and in the Device Manager view
(Figure 4-38), providing double-click access to each extension’s default view. One exception to this is for an
AX-3.1 or later AxSupervisor, in its Station Manager view of the NiagaraNetwork, where special “provi-
sioning” extensions for NiagaraStations do not appear. See “NiagaraStation component notes” on page 4-
55 for related details.

Figure 4-38 Device extensions in Nav tree and Device Manager

Perhaps the most important of all device extensions is the Points extension—the container for all proxy
points (representing data originating from that device).
Types of Device extensions include:
• Points extension—see “About the Points extension” on page 4-25.
• Histories extension—see “About the Histories extension” on page 4-25.

NiagaraAX-3.x
4-24
User Guide
Chapter 4 – Driver architecture Types of device extensions
May 1, 2007 About the Points extension

• Alarms extension—see “About the Alarms extension” on page 4-26.


• Schedule extension—see “About the Schedules extension” on page 4-27.

About the Points extension


A device’s Points extension (or simply Points) serves as the top parent container for real-time data values
originating from that device.

Figure 4-39 Points under a Lon device

These values are “proxied” using NiagaraAX control points, or proxy points. Values can be both read from
data values in that device, and written to value stores in the device. For details see “About control points”
on page 3-1 and “About proxy points” on page 3-18.
Note: You create all proxy points using the Point Manager view of Points—simply double-click Points under any
device component, or right-click Points and select Views > Point Manager. See “About the Point
Manager” on page 4-28 for more details.

About the Histories extension


Not all drivers have devices with a HistoryDeviceExt—notably, this exists only if the driver protocol (or
device) provides local data logging. Currently, this device extension exists under components NiagaraS-
tation, ObixClient, R2ObixClient, and BacnetDevice (under a BacnetDevice it is named “Trend Logs”).

Figure 4-40 Histories device extension (NiagaraStation)

A device’s Histories extension serves as the parent container for history descriptors—components that
specify how history-type collections (log data) are imported or exported. By default, it also contains a
Retry Trigger, see “About the Retry Trigger” on page 4-26.
Note: Creating history import and history export descriptors is how you save a Niagara history to a different
location (station) from where it originated. In a typical application, this is considered archiving. For
example, an originating history (with a limited record count) may be in a JACE station. If imported to a
supervisor station, its history import descriptor can be configured such that the imported history in the
supervisor has “unlimited” record capacity. The JACE history can run collecting only the last 500 records,
while the imported history in the supervisor will collect all (unlimited) records.
The difference between a history import and history export are as follows:

NiagaraAX-3.x
4-25
User Guide
Types of device extensions Chapter 4 – Driver architecture
About the Retry Trigger May 1, 2007

• Import
An imported history appears in the local station as a Niagara history, where data is effectively
“pulled” from a remote source device.
• If configured by a history import descriptor under Histories of a NiagaraStation device, the source
is another Niagara history in that remote station.
• If configured by a history import descriptor under Trend Logs of a BacnetDevice, the source is a
BACnet Trend Log object residing in that BACnet device.
• Export
(NiagaraStation only) An exported history is a Niagara history that exists in the local station, and is
configured by a history export descriptor to “push” its data to a remote NiagaraStation. This adds it
to the histories in that remote station.
Note: Under a BacnetNetwork, the single “LocalDevice” component (that represents station data
exported to BACnet) has a special view on its child Export Table component that permits
exporting station histories as BACnet Trend Log objects. See the BACnet Guide section “Bacnet server
configuration overview” for more details.
You create history import descriptors and export descriptors under the Histories extension of a device
using separate views. For details, see “About Histories extension views” on page 4-37.

About the Retry Trigger


By default, device extensions Histories and Schedules contain a “Retry Trigger”-named component,
appearing in the Nav tree but not in any Manager view (Figure 4-41).
Note: Retry Trigger is unique in that it requires no linking of its output for operation.

Figure 4-41 Retry Trigger under device Histories extension

Upon any unsuccessful execution of a history import/export descriptor or schedule import extension/
schedule export descriptor contained in that same device extension, the Retry Trigger defines subsequent
“retries” that will automatically occur upon the interval period defined (default value is 15 minutes). This
continues until successful execution occurs.

About the Alarms extension


Not all drivers have devices with an AlarmDeviceExt (Alarms)—notably, this exists only if the driver
protocol (or device) provides for local (native) alarming. Currently, only a device component under a
NiagaraNetwork (station), BacnetNetwork, or ObixNetwork has a child Alarms extension.
Alarms extension properties specify how alarms from that device are mapped into the station’s own
alarm subsystem, plus provide status properties related to alarm sharing. Unlike other device extensions,
there are no special views, nor does the extension contain other special components.
Alarms extension properties
The following properties apply:
• Alarm Class
(Available only if checkbox “Use Existing Alarm Class” is cleared) Provides selection list of local
AlarmClass, from which you select one to use for all alarms received from this device.
• Use Existing Alarm Class
(checkbox, applies to NiagaraStation only)
• If enabled (default), alarms from this remote station are routed to any “matching” AlarmClass,
that is, one with identical name as the “alarmClass” field in each alarm record. If no local
“matching” AlarmClass is found, the station’s default AlarmClass is used.
• If cleared, all received alarms are routed to the single local AlarmClass specified.

NiagaraAX-3.x
4-26
User Guide
Chapter 4 – Driver architecture Types of device extensions
May 1, 2007 About the Schedules extension

• Last Received Time


Timestamp when last alarm from this station was received. This is configured remotely, either in the
sending Niagara station or the BACnet device.
Note: Remaining properties apply to the Alarms extension under a NiagaraStation component only
(are not available in Alarms extension under a BacnetDevice).
• Last Send Time
Timestamp when last local alarm was routed to this device. This is configured under the local sta-
tion’s AlarmService with a corresponding StationRecipient or BacnetDestination component linked
to one or more AlarmClass components).
• Last Send Failure Time
Timestamp when last local alarm routed to this station could not be sent.
• Last Send Failure Cause
Text string describing failure cause routing local alarm to this station.

About the Schedules extension


Not all drivers have devices with a ScheduleDeviceExt (Schedules)—notably, this exists only if the driver
protocol (or device) provides local event scheduling. Currently, this device extension exists only under
components NiagaraStation and BacnetDevice.

Figure 4-42 Schedules device extension (NiagaraStation)

A device’s Schedules extension is the parent container for imported schedules—Niagara schedule compo-
nents with a ScheduleImportExt. Events in an imported schedule are obtained from that device, and are
read-only (often called “slave schedules”). By default, the Schedules extension also contains a Retry
Trigger, see “About the Retry Trigger” on page 4-26.
The Schedules extension can also contain schedule export descriptors. These correspond to local station
schedules that are exported (“pushed”) to that remote station (often called “master schedules”). A
schedule export descriptor is automatically created whenever a local schedule is “imported” into a remote
station.
The difference between a schedule import and schedule export are as follows:
• Import
An imported schedule appears in the local station as a Niagara schedule, where read-only schedule
events are configured/adjusted in a remote source device.
• If under a NiagaraStation device, the source is a Niagara schedule in that remote station.
• If under a BacnetDevice, the source is a BACnet Schedule or Calendar object residing in that BACnet
device. That object’s data is now modeled as a Niagara schedule component.
• Export
This is a Niagara schedule in the local station that is exported into a remote station (NiagaraNet-
work) or BACnet Schedule or Calendar object (BacnetNetwork). A resulting schedule export de-
scriptor allows configuration of a “push” mechanism to keep event configuration synchronized in
the remote device.
Note: Under a BacnetNetwork, the single “LocalDevice” component (that represents station data
exported to BACnet) has a special view on its child Export Table component that permits “exposing”
Niagara schedule components in the station as either a BACnet Schedule object or Calendar object.
For details, see the Bacnet Users Guide.
You create imported schedules under a device’s Schedules extension using an Import Manager view. A
separate Export Manager view provides access to schedule export descriptors. For details, see “About
Schedules extension views” on page 4-44.

NiagaraAX-3.x
4-27
User Guide
About the Point Manager Chapter 4 – Driver architecture
Points New Folder and New May 1, 2007

Note: Schedule components local to the station can reside anywhere under the station’s Config hierarchy and be
imported by one or more other stations. As this occurs, a schedule export descriptor is automatically
created under the NiagaraStation component that represents the remote station (and is located in its
Schedules container). On the other hand, if you import a schedule from another NiagaraStation or Bacnet-
Device, it must reside in that device’s Schedule container. Imported schedules are always under a specific
device.

About the Point Manager


The Point Manager is the default view for the Points extension under any device object. Like other
manager views, it is table-based (Figure 4-43). Here, each row represents a proxy point (or a points folder)
under Points.

Figure 4-43 Point Manager under a BacnetDevice

When building a network in the station, you use this view to create, edit, and delete proxy points in the
station database. See “About proxy points” on page 3-18.
Following station configuration, this view provides a status summary for proxy points. You can also use
it to issue an override action to a writable proxy point, e.g. “Active,” “Off,” and so on.
Note: Only proxy points appear in the Point Manager Database—any other components that may also reside
under Points do not appear. For example, you do not see kitControl or schedule components, or any control
point with a “null proxy extension.” However, you can use other views of Points (wire sheet, property sheet,
slot sheet) to access these items.
At the bottom of the view, buttons “New Folder” and “New” let you create new point folders and proxy
points in the station database. An “Edit” button lets you edit one or more selected proxy points. If the
driver supports online “device learning,” buttons “Discover,” and “Match” are also typically available.
Finally, additional buttons may be available, depending on the driver.
For more details, see:
• Points New Folder and New
• Point Edit
• About Point Discover, Add and Match (Learn Process)
• About other Points views

Points New Folder and New


Buttons New Folder and New exist in a device’s Point Manager view under any driver network.
Note: New Folder and New are tools on the Point Manager toolbar, and in the Manager menu.

NiagaraAX-3.x
4-28
User Guide
Chapter 4 – Driver architecture About the Point Manager
May 1, 2007 Points New Folder and New

New Folder
New Folder in the Point Manager adds a special “PointFolder” component that you can use to organize
proxy points. This is equivalent to copying that same component from that driver’s palette. A Name
dialog lets you name the folder before it is created (Figure 4-44).

Figure 4-44 Example New Folder dialog in Point Manager

When you click OK, a new PointFolder component is added under Points. Point folders are often useful,
especially if you are creating many proxy points, or need extra wire space for additional kitControl or
schedule components (and whatever links you wish to create between them).
Note: A devices’s PointFolder component is different than a “normal” Folder component, because it includes that
devices’s Point Manager view as its default view (just like the parent Points component). You can double-
click a point folder (either in the Point Manager view pane or in the Nav tree), to access its Point Manager.
Also, an “All Descendants” command is available from the root Points Manager, which allows you to see all
proxy points in that device.
All Descendants When in the Point Manager of a point folder, it is “unaware” of proxy points in other
point folders (or in the root of Points). However, from the root Point Manager view (of Points), you can
“flatten” the folder structure to view all proxy points by selecting “All Descendants” from the Manager
menu (Figure 4-45) or simply clicking the “All Descendants” tool on the toolbar (Figure 4-46). Note that
“all descendants” is also available at any point folder (level) as well—you just see all points in descendants
from that folder level on down.
Note: Be aware that in a device with many point folders and proxy points, using the all descendants feature
(particularly at the Points root level) may decrease performance. This might result from so many points
becoming subscribed.

Figure 4-45 Manager menu “All Descendants” command

NiagaraAX-3.x
4-29
User Guide
About the Point Manager Chapter 4 – Driver architecture
Point Edit May 1, 2007

Figure 4-46 Point Manager “All Descendants” tool on toolbar.

Note: If you are using point folders, and you click on a table to column to resort points, please be aware that any
proxy point-to-point folder organization is lost during that view. However, you can always see contents of
point folders clearly in the Nav tree, and again when returning to the Point Manager view from another
view.
New
New in the Point Manager is to add new proxy points to the station. Typically, you use New only if the
driver does not support online discovery, or if you are programming offline. Under any of the Modbus
drivers, for example, you use New to add proxy points.
Using New is equivalent to copying proxy points from that driver’s palette, except it provides more utility
to specify other parameters. Minimally, the New dialog provides a selection list for proxy point type, and
also the number of points to add (Figure 4-47).

Figure 4-47 Example New dialog in Point Manager

In some driver networks, the New dialog may provide other parameters, such as a starting address range
when adding multiple proxy points. When you click OK, the number and type of proxy points you
specified are added under Points or a point folder. You need to edit specific properties for each new proxy
point (note these are typically properties of its proxy extension).

Point Edit
In the Point Manager view, you can Edit any proxy point shown in the station database by simply double-
clicking it. (Edit does not apply to point folders.)
Edit
The Edit dialog appears with the proxy point listed (Figure 4-48).

NiagaraAX-3.x
4-30
User Guide
Chapter 4 – Driver architecture About the Point Manager
May 1, 2007 Point Edit

Figure 4-48 Example Edit dialog in Point Manager (single point)

Note: The Edit dialog for a proxy point shows mostly properties under its proxy extension, plus (typically) the
parent point’s Name and Facets. Many of the proxy extension values are required for communications, and
will vary among drivers. To access all properties of the proxy point, including all those under any of its
extensions, go to its property sheet.
When a single point is selected in the Edit dialog, you can edit any property except Type (fixed when you
added the point). Included is the ability to edit the Name of the proxy point in the station. This is equivalent
to the right-click Rename command on the point.
The following related topics also apply:
• Proxy point “gang” edits
• Manager table features
Proxy point “gang” edits
The Edit button in the Point Manager allows you to edit one or more proxy points in the station in a single
dialog. Before clicking Edit, use standard Windows keyboard controls to highlight (select) multiple points
(e.g. hold down Ctrl key and click desired points).
Note: Edit is also on the Point Manager toolbar and the Manager menu, if any point is selected.
The “gang” edit feature is useful for making the same change in multiple (selected) proxy points. For
example, as shown in Figure 4-49, you can change “Tuning” (point’s associated tuning policy) in multiple
points at the same time (versus editing this individually).

NiagaraAX-3.x
4-31
User Guide
About the Point Manager Chapter 4 – Driver architecture
About Point Discover, Add and Match (Learn Process) May 1, 2007

Figure 4-49 Example “gang edit” in Edit dialog in Point Manager

When you have the Edit dialog open with multiple points, you can also click on a specific one to make
individual edits (e.g. Name, or any other editable property), during the same dialog session where you
made “gang” property edits. When you click OK, all the changes are applied to the proxy points as made
during your Edit session. For more details, see “About gang edits.”
Note: When you have multiple points selected in the Edit dialog, properties that must be unique (such as Name)
are automatically unavailable (dimmed). However, note that some properties that typically should be
unique (often address properties) may still be available for “gang edit,” as this rule is not automatically
enforced. Typically, when editing these properties, you should verify only a single point component (row) is
highlighted in the table.

About Point Discover, Add and Match (Learn Process)


Online “point learns” are possible in some driver networks, for example the NiagaraNetwork, Bacnet-
Network, LonNetwork, and NdioNetwork. Whenever available, this method is the easiest way to
accurately add proxy points to the station database.
Any proxy point learn in NiagaraAX is a two-step process using the Point Manager, where you:
1.Under a selected device component, use its (Points device extension) Point Manager view to
Discover data items as point candidates for inclusion in the station database.
2. Select and Add from those candidates, creating proxy points under the device’s Points container. (If
you already used New to add points, you can also Match to those existing points).
Note: The Point Manager reinforces this process by providing two separate panes in the view whenever you enter
“Learn Mode.” See “About Learn toggle” on page 4-16.
Discover
The Discover button is available in the Point Manager only if the driver supports online discovery. When
you click Discover, the Point Manager view splits into two panes (Learn Mode), and at the same time
typically launches a discovery “job” (Figure 4-50).
Note: Under a LonNetwork, Point Manager has a Learn Mode, but no point Discover. All possible data items
were already discovered when the parent device was discovered and added. Here, enter Learn Mode by
toggling (see “About Learn toggle” on page 4-16).

NiagaraAX-3.x
4-32
User Guide
Chapter 4 – Driver architecture About the Point Manager
May 1, 2007 About Point Discover, Add and Match (Learn Process)

Figure 4-50 Discover splits Point Manager view

Note: Under a NiagaraNetwork (only), a Niagara Point Manager discover produces an intermediate dialog: the
Bql Query Builder. You use it to browse the remote station and specify what items to select from as
discovered proxy point candidates. For details, see “About the Bql Query Builder” on page 4-56.
In Learn Mode, the two panes in the Point Manager operate as follows:
• Discovered (top pane)
Lists data items discovered on the driver’s network, as proxy point candidates. For any data item
found that already exists in the station database, it will appear “ghosted” (listed faintly). Note items
listed may be “expandable”—see “Discovered selection notes” on page 4-33.
A job “progress bar” is also included on top of the Discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.
• Database (bottom pane)
Lists proxy points and point folders that are currently in the station database.
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-
pane Learn Mode and the single-pane (Database) view by clicking the Learn Mode tool in the toolbar
(Figure 4-24 on page 16), or using the Learn Mode command in the Manager menu.
Discovered selection notes Often, data items listed in the Point Manager’s discovered pane are
expandable, having one or more related items, each individually selectable. Expandable items are
indicated by a leading plus (+), which you click to expand (a toggle control).
Figure 4-51 shows an example item (Lonworks nvoUnitStatus) expanded to reveal individual numeric-
type elements, each selectable as a separate proxy point.

NiagaraAX-3.x
4-33
User Guide
About the Point Manager Chapter 4 – Driver architecture
About Point Discover, Add and Match (Learn Process) May 1, 2007

Figure 4-51 Expand discovered data items to see all point candidates

Here, if you selected only the top “mode” element to add, you would have one proxy EnumPoint to
monitor the enumerated unit status (auto, heat, cool, etc), but would not have any of the related numeric-
type items proxied as control points.
Depending on the driver/device type, expandable discovered items represent individual properties or
other “structured” data. Some examples:
• BacnetDevice—Each top item is typically the “present value” property of the BACnet object (most
commonly selected). Expand the item to see other properties of the object.
• NiagaraStation—Using Bql Query Filter defaults (Config, control, ControlPoint), each top item
is equivalent to the “Out” slot of the Niagara component (and most commonly selected). Expand the
item to see other slots in the component (including Out).
• LonDevice—Each top item is typically the first element (field) in a structured SNVT (multi-field data
structure), as used in that particular network variable (nv or nci). To access other data fields in the
SNVT’s structure, you must expand that item.
For specific details, refer to the “Point discovery notes” section in a particular driver document.
Add
The Point Manager's Add button is available in Learn Mode when you have one or more data items
selected (highlighted) in the top discovered pane. When you click Add, an Add dialog appears that allows
you to edit properties before the proxy point(s) are created in the station (Figure 4-52).
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add
tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a
discovered item to bring it up in the Add dialog.

NiagaraAX-3.x
4-34
User Guide
Chapter 4 – Driver architecture About the Point Manager
May 1, 2007 About Point Discover, Add and Match (Learn Process)

Figure 4-52 Add dialog from Add button in Point Manager

The Add dialog is nearly identical to the point Edit dialog, but allows you to edit Type as well as other
properties.
Often, you may wish to change Type from the pre-selected one, at least between read-only points and the
equivalent writable control point within that data category. For example, if adding a proxy point for the
present value (default) property for a BACnet Binary Output object, you may wish it to be a read-only
BooleanPoint point rather than the default BooleanWritable. As shown in Figure 4-53, you can do this in
the Add dialog before it is added to the station database, (but not later using the point Edit feature).

Figure 4-53 Change Type as needed in point Add dialog

Note: In most cases, alternate point Types include StringPoint, and possibly others. Generally speaking, there are
few practical applications in changing the data category of a proxy point type (e.g. from Boolean to Enum
or Sting), however, this may be an option. Note that if working under a NiagaraNetwork, only read-only
proxy points are available.
Address-related properties in the Add point dialog already have acceptable values for operation
(otherwise, the data item would not have been discovered). It is possible you change only Name and
possibly Type, unless you know other settings you wish to change now. You can always Edit these
properties in the proxy point(s) after you click OK and add them to your station.
Match
Match is a feature that may be useful when you have an application with proxy points you wish to reuse,
or if you have programmed offline using the New point feature.

NiagaraAX-3.x
4-35
User Guide
About the Point Manager Chapter 4 – Driver architecture
About other Points views May 1, 2007

• In the first case (application for reuse), you could have some number of proxy points included in an
application that you have saved and now recopied under the target Points container. Often, address-
related properties in the copied proxy points are incorrect. However, you can use the Point Manag-
er’s Learn Mode and step through each proxy point in the copied application, and use the Match fea-
ture to “sync” with the intended (and discovered) data item.
• In the second case (offline programming) where a connection to the actual device network is un-
available, you can manually add New devices and New proxy points, and begin station engineering
of a driver network. Typically, most component creations under a driver network are possible (in-
cluding all levels) using the New command in the various “manager” views (Device Manager, Point
Manager, other device extension managers). Or, you can add saved applications (from the device lev-
el on down) and edit as necessary. Then, when online with the driver network later, you could use
Match to “sync” to existing components (device-level, proxy points, and so forth).
The Match button in the Point Manager becomes available when in Learn Mode, and you have:
1. Selected one point candidate in the top (Discovered) pane.
2. Selected one existing proxy point in the bottom (Database) pane.
Note: In this case, the toolbar also has an available Match tool, and the Manager menu has a Match command.
When you click Match, the Match dialog appears, as shown in Figure 4-54.

Figure 4-54 Match dialog example in Point Manager

Note: Match is strictly a “one-to-one” function for “discovered-to-database”—note that it is unavailable any time
you have multiple items selected either in either the top Discovered pane or bottom Database pane.
The Match point dialog is nearly identical to the single-point Edit dialog, and typically provides the
“discovered” point address values. Often, most properties in the Match dialog have acceptable address
values required for operation (otherwise, the item would not have been discovered). You can always Edit
the proxy point after you click OK and add it to your station.

About other Points views


Although you initially use the Point Manager (default) view of a device’s Points extension (and/or child
point folders), typically other views are needed when engineering a network. You can use the view
selector in the locator bar, or in the Nav tree right-click Points (and/or child point folders) and select one
of the View menu options.
Note: Remember that the Point Manager view provides access only to proxy points, and edit features apply only
to proxy extension properties.
Commonly used Points views include:
• Wire sheet
Shows all proxy points, plus any kitControl and schedule components, simple control points, and so
on, as well as links between them. Typically, you use this view to engineer control logic.
• Property sheet
Also includes all proxy points, plus any kitControl and schedule components, simple control points,

NiagaraAX-3.x
4-36
User Guide
Chapter 4 – Driver architecture About Histories extension views
May 1, 2007 History Import Manager

and so on. As needed, you can use this view to expand down to any level to access and edit properties.
For example, you can access an alarm extension under a proxy point.
• Slot sheet
Also includes all proxy points, plus any kitControl and schedule components, simple control points,
and so on. As needed, you can use this view to edit config flags from defaults (say, for security
schemes), edit config facets, and add name maps.
• Px view (New View)
(Optional) A custom graphical view that you define by creating a new px file or using an existing px
file. When created, this view becomes the default view for the device’s Points extension (or if created
for a points folder, its default view).

About Histories extension views


For an overview of a device Histories extension, see “About the Histories extension” on page 4-25. Special
views available on a device’s Histories extension may include:
• History Import Manager
• History Export Manager

History Import Manager


The History Import Manager is the default view for a device’s Histories extension. Like other managers,
it is a table-based view (Figure 4-55). Here, each row is a history import descriptor. Each descriptor
specifies how log data is imported (pulled) from the device into the station as a history.

Figure 4-55 History Import Manager under a NiagaraStation

When building a network in the station, you use this view to create, edit, and delete history import
descriptors. Each import descriptor you add results in the creation of a local Niagara history.
Following station configuration, this view provides a status summary for collecting imported histories.
You can also use it to issue manual “Archive” commands to one or more history descriptors. This causes
an immediate import request to pull logged data from the remote device.
Note: Only history import descriptors appear in the History Import Manager view—any other components that
may also reside under Histories do not appear. For example, you do not see the default “Retry Trigger”
component (see “About the Retry Trigger” on page 4-26). However, you can use the Histories property sheet
to access these items.
At the bottom of the view, the button “New” lets you manually create new import descriptors in the
station. An “Edit” button lets you edit one or more import descriptors. Buttons “Discover,” “Add” and
“Match” are also available, (these work similarly as in the Point Manager). An “Archive” button is
available to manually import (pull data) into one or more selected histories. Finally, additional buttons
may be available, depending on the driver.

NiagaraAX-3.x
4-37
User Guide
About Histories extension views Chapter 4 – Driver architecture
History Import Manager May 1, 2007

For more details, see:


• History Import New
• History Import Edit
• About History Import Discover, Add and Match (Learn Process)
History Import New
Button New exists in a device’s History Import view, but is typically used only if engineering offline—most
devices with a Histories extension support online discovery (a FileDevice is one exception). If used,
Match may be used later (when online with the device).
Note: A New tool is also on the History Import Manager toolbar, and in the Manager menu.
History Import Edit
In the History Import Manager, you can Edit any import descriptor in the station database by simply
double-clicking it.
Edit The Edit dialog appears with the import descriptor listed (Figure 4-56).

Figure 4-56 Edit dialog in History Import Manager (single history)

Note: The Edit dialog shows configuration properties of the history import descriptor, plus Name (equivalent to
the right-click Rename command on the descriptor). To access all properties, (including all status
properties) go to its property sheet.
The following related topics also apply:
• History Import properties
• History descriptor “gang” edits
• Manager table features
History Import properties Properties of history import descriptors available in the Edit or Add dialog
are as follows:
• Name
Name for history import descriptor component. If discovered, typically left at default.
Note: Editing name does not affect name of the resulting history (imported into station).
• History Id
If under a NiagaraStation, (NiagaraNetwork), this property specifies the history name in the local
station’s history space, using two parts: “/<stationName>” and “/<historyName>”. If learned, station
name is “^” (see note below) and history name reflects the source history name. Typically, you leave
both fields at default values, or edit the second (<historyName>) field only.
Note: The “^” character is basically a shorthand character to refer to the device name of the parent
container (NiagaraStation component). This may be useful if you have multiple JACEs with histories
named the same. You can create and configure a single History Import Descriptor and then duplicate
and paste it under the other stations without having to go in and change the station name each time.
If under a BacnetDevice, the fields apply to the source BACnet object (“trendLog,” instance number
<n>)—you typically leave learned values at defaults. You name the Niagara history using an addition-
al Local History Name property.
• Execution Time
Either Daily (default), Interval, or Manual. If Manual, properties below are not available:
• Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.

NiagaraAX-3.x
4-38
User Guide
Chapter 4 – Driver architecture About Histories extension views
May 1, 2007 History Import Manager

• Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds
and this interval is added to the Time of Day. May prevent “server flood” issues if too many his-
tory archives are executed at the same time. Default is zero (no randomization).
• Days of Week (Daily and Interval)
Select (check) days of week for archive execution. Default is all days of week.
• Interval (Interval)
Specifies repeating interval for archive execution. Default is every 15 minutes.
• Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).
• Enabled
Default is true. If set to false, does not execute import of history data.
• Capacity
Specifies local storage capacity for imported history, either as Unlimited or Record Count.
If set to Record Count, the following property is available:
• records
Number of records (samples) to locally store. Default is 500.
• Full Policy
Either Roll (default) or Stop. Applies only if capacity is set to record count
• If Roll, upon record count, oldest records become overwritten by newest records.
• If Stop, upon record count, importing stops (until history records are locally deleted).
Note: Bacnet History Import descriptors have additional properties, including a Local History Name
property visible from the Add or Edit dialog.
History descriptor “gang” edits The Edit button in the History Import (or Export) Manager allows you
to edit one or more descriptors in a single dialog. Before clicking Edit, use standard Windows keyboard
controls to highlight (select) multiple descriptors (e.g. hold down Ctrl key and click desired descriptors).
Note: Edit is also on the History Import (or Export) Manager toolbar and the Manager menu, if any descriptor
is selected.
The “gang” edit feature is useful for making identical changes in multiple (selected) descriptors. For
example, you can change “Execution Time” (when data is pulled into imported history) in multiple
descriptors at the same time (versus editing individually).
When you have the Edit dialog open with multiple descriptors, you can also click on select ones to make
individual edits (e.g. Execution, Time of Day), during the same dialog session where you made “gang”
edits. When you click OK, all the changes are applied to the descriptors as made during your Edit session.
For more details, see “About gang edits.”
Note: When you have multiple descriptors selected in the Edit dialog, properties that currently have different
values are automatically unavailable (dimmed). Only a property that currently has the same value (across
all selected descriptors) is available for gang edit.
About History Import Discover, Add and Match (Learn Process)
Unless working offline, you can use the learn process to import histories in the station. As with other
NiagaraAX learns, this is a two-step process in the History Import Manager, where you:
1.Under a selected device component, use its (Histories extension) Histories Import Manager view to
Discover log data (histories) as candidates for inclusion in the station as histories.
2. Select and Add from those histories, creating history descriptors under the device’s Histories
container.
Note: The Histories Import Manager reinforces this process by providing two separate panes in the view whenever
you enter “Learn Mode.” See “About Learn toggle” on page 4-16.
Discover When you click Discover, the Histories Import Manager splits into two panes (Learn Mode):
discovered items in the top pane, and existing import descriptors bottom pane (Figure 4-57).
Note: If under a BacnetDevice, a “Bacnet Trend Logs Discover” job is started, with a progress bar at top. If BACnet
Trend Log objects are found, they are listed in the discovered pane.

NiagaraAX-3.x
4-39
User Guide
About Histories extension views Chapter 4 – Driver architecture
History Import Manager May 1, 2007

Figure 4-57 Discover splits Histories Import Manager

Note: Under a NiagaraNetwork (only), the discovered pane shows the collapsed tree structure of all Niagara
histories of that selected NiagaraStation. Click to expand and select histories for import. See “Discovered
selection notes” on page 4-40 for more details.
In Learn Mode, the two panes in the Histories Import Manager operate as follows:
•Discovered (top pane)
Lists histories (Niagara) or Trend Logs (Bacnet) found in the device, as history descriptor candidates.
Any item that already exists as a history in the station is “ghosted” (faintly listed).
If a BacnetDevice, a job “progress bar” is also included on top of the Discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.
• Database (bottom pane)
Lists history descriptors currently in the station database (each has an associated history).
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-
pane Learn Mode and the single-pane (Database) view by clicking the Learn Mode tool in the toolbar
(Figure 4-24 on page 16), or using the Learn Mode command in the Manager menu.
Discovered selection notes In the Niagara History Import Manager, discovered histories of a Niagar-
aStation are under an expandable tree structure, organized by station name (Figure 4-58).

Figure 4-58 Expand Niagara stations to see all Niagara histories

NiagaraAX-3.x
4-40
User Guide
Chapter 4 – Driver architecture About Histories extension views
May 1, 2007 History Export Manager

Histories under the same station name as the parent NiagaraStation (device) component are local
histories for that station. Histories under any other stations represent histories currently imported into
(or exported to) that station.
For example, discovered histories in Figure 4-58 for NiagaraStation J403IP98 include local histories
(expanded); other “imported” histories from station NxMbTest56 are shown contracted.
Note: From any NiagaraStation, you can import both its “local” histories and already-imported histories, as
needed. However, unless circumstances warrant a “relay archive method,” it may be best to import histories
directly from the source station whenever possible.
Add The Add button is available in Learn Mode when you have one or more items selected (highlighted)
in the top discovered pane. When you click Add, a dialog appears that allows you to edit properties before
the history descriptor(s) are created in the station.
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add
tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a
discovered item to bring it up in the Add dialog.
The Add dialog is identical to the history import descriptor Edit dialog. For details on properties, see
“History Import properties” on page 4-38.
Match Match, as an online function, is available if you have one history selected in the top (discovered)
pane and one history import descriptor selected in the bottom (database) pane. However, usage of Match
when importing histories from a device (NiagaraStation, BacnetDevice) is generally not recommended.
Instead, use the Discover and Add method to import histories.

History Export Manager


The History Export Manager view is available (only) on a NiagaraStation’s Histories extension.
Note: If using the Bacnet driver, Niagara histories in the local station can also be “exposed” to all networked
BACnet devices as BACnet “Trend Log objects”. However, this is done using a different view under the Local
Device component in the BacnetNetwork. See the Bacnet Users Guide for more details.
Like other managers, the History Export Manager is a table-based view (Figure 4-59). Each row repre-
sents a history export descriptor. Each descriptor specifies how data from a local history is exported
(“pushed”) from the station to a selected NiagaraStation, where it appears as a history.
Note: The “capacity” and “fullPolicy” configuration for each “exported” history (as created on the remote station),
is determined by that target station’s NiagaraNetwork component’s “History Policies.” Before exporting any
histories, you should review and adjust these policies as needed. For more details, see “About History
Policies” on page 4-51.

Figure 4-59 History Export Manager under a NiagaraStation

You use this view to create, edit, and delete history export descriptors. Each export descriptor you add
results in the creation of a Niagara history on that remote station.

NiagaraAX-3.x
4-41
User Guide
About Histories extension views Chapter 4 – Driver architecture
History Export Manager May 1, 2007

Following station configuration, this view provides a status summary for exporting local histories. You
can also use it to issue manual “Archive” commands to one or more history descriptors. This causes an
export “push” of history data into the selected histories at the remote Niagara station.
Note: Only history export descriptors appear in the History Export Manager view—any other components that
may also reside under Histories do not appear. For example, you do not see the default “Retry Trigger”
component (see “About the Retry Trigger” on page 4-26), or history import descriptors. However, you can
use the Histories property sheet or the Nav tree to access these items.
At the bottom of the view, the button “New” lets you manually create new export descriptors in the
station. An “Edit” button lets you edit one or more export descriptors. Buttons “Discover,” “Add” and
“Match” are also available, (these work similarly as in the Point Manager). An “Archive” button is
available to manually export (push data) into one or more selected histories. Finally, additional buttons
may be available, depending on the driver.
For more details, see:
• History Export New
• History Import Edit
• About History Import Discover, Add and Match (Learn Process)
History Export New
Button New exists in a NiagaraStation’s History Export view, but is used only if engineering offline (online
discovery is preferred). If used, Match may be used later (when online with the device).
Note: A New tool is also on the History Export Manager toolbar, and in the Manager menu.
History Export Edit
In the History Export Manager, you can Edit any export descriptor in the station database by simply
double-clicking it.
Edit The Edit dialog appears with the export descriptor listed (Figure 4-60).

Figure 4-60 Edit dialog in History Export Manager (single history)

Note: The Edit dialog shows configuration properties of the history export descriptor, plus Name (equivalent to
the right-click Rename command on the descriptor). To access all properties, (including all status
properties) go to its property sheet.
The following related topics also apply:
• History Export properties
• “History descriptor “gang” edits” on page 4-39
• “Manager table features” on page 4-19
History Export properties Properties of history export descriptors available in the Edit or Add dialog
are as follows:
• Name
Name for history export descriptor component. Typically left at default. Begins with “Local_” for
any history originating from the local station.
Note: Editing name does not affect name of resulting history (exported into remote station).
• History Id
This property specifies the history name to be created in the remote station’s history space, using
two parts: “/<stationName>” and “/<historyName>”. Histories originating in the local station show
a “^” (shorthand for local station name), and history name reflects the source history name. Typical-
ly, you leave both fields at default values.

NiagaraAX-3.x
4-42
User Guide
Chapter 4 – Driver architecture About Histories extension views
May 1, 2007 History Export Manager

•Execution Time
Either Daily (default), Interval, or Manual. If Manual, properties below are not available:
• Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.
• Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds
and this interval is added to the Time of Day. May prevent “server flood” issues if too many his-
tory archives are executed at the same time. Default is zero (no randomization).
• Days of Week (Daily and Interval)
Select (check) days of week for archive execution. Default is all days of week.
• Interval (Interval)
Specifies repeating interval for archive execution. Default is every 15 minutes.
• Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).
• Enabled
Default is true. If set to false, history data is not exported.
Note: The capacity and full policy of any exported history (created on the remote station) is determined by rules
under that station’s NiagaraNetwork “History Policies,” and is set at creation time only. For details, see
“About History Policies” on page 4-51.
About History Export Discover, Add and Match (Learn Process)
Unless working offline, you can use the learn process to export histories in the station. As with other
NiagaraAX learns, this is a two-step process in the History Export Manager, where you:
1.Under a selected NiagaraStation, use its (Histories extension) Histories Export Manager view to
Discover (local) station histories as candidates for export to that station as histories.
2. Select and Add from those histories, creating history descriptors under the station’s Histories
container.
Note: The Histories Export Manager reinforces this process by providing two separate panes in the view whenever
you enter “Learn Mode.” See “About Learn toggle” on page 4-16.
Discover When you click Discover, the Histories Export Manager splits into two panes, or Learn Mode
(Figure 4-61). The top discovered pane is a collapsed tree structure of all Niagara histories of the local
station. Click to expand and select histories for export. See “Discovered selection notes” on page 4-44 for
more details.

Figure 4-61 Discover splits Histories Export Manager

In Learn Mode, the two panes in the Histories Export Manager operate as follows:
• Discovered (top pane)
Lists all histories in the local station (station you are engineering). Any history that already exists as
a history in the selected NiagaraStation device is “ghosted” (listed faintly).

NiagaraAX-3.x
4-43
User Guide
About Schedules extension views Chapter 4 – Driver architecture
History Export Manager May 1, 2007


Database (bottom pane)
Lists history descriptors currently in the station database (each has an associated history, exported
to that remote station).
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-
pane Learn Mode and the single-pane (Database) view by clicking the Learn Mode tool in the toolbar
(Figure 4-24 on page 16), or using the Learn Mode command in the Manager menu.
Discovered selection notes In the Niagara History Export Manager, discovered local histories are
under an expandable tree structure, organized by station name (Figure 4-62).

Figure 4-62 Expand Niagara stations to see all Niagara histories

Histories under the same station name as the local station originated in that station. Histories under any
other stations represent histories currently imported (or exported) into the local station.
For example, discovered histories in Figure 4-62 for local station NxMbTest56 include locally-originated
histories (expanded); other “imported” histories from station J403IP98 are shown contracted.
Note: To any NiagaraStation, you can export both a station’s “locally-originated” histories as well as already-
imported histories, as needed. However, unless circumstances warrant a “relay archive method,” it may be
best to export only “locally-originated” histories.
Add The Add button is available in Learn Mode when you have one or more items selected (highlighted)
in the top discovered pane. When you click Add, a dialog appears that allows you to edit properties before
the history export descriptor(s) are created in the station.
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add
tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a
discovered item to bring it up in the Add dialog.
The Add dialog is identical to the history export descriptor Edit dialog. For details on properties, see
“History Export properties” on page 4-42.
Match Match, as an online function, is available if you have one history selected in the top (discovered)
pane and one history export descriptor selected in the bottom (database) pane. However, usage of Match
when exporting histories from a device (NiagaraStation, BacnetDevice) is generally not recommended.
Instead, use the Discover and Add method to export histories.

About Schedules extension views


For a Schedules device extension overview, see “About the Schedules extension” on page 4-27.
Special views on a device’s Schedules extension may include:
• Schedule Import Manager
• Schedule Export Manager
Note: Other standard views of a Schedules extension are commonly used. For example, the wire sheet may be used
when linking imported schedules to other control logic in the station.

NiagaraAX-3.x
4-44
User Guide
Chapter 4 – Driver architecture About Schedules extension views
May 1, 2007 Schedule Import Manager

Schedule Import Manager


The Schedule Import Manager is the default view for a device’s Schedules extension. Like other managers,
it is a table-based view (Figure 4-63). Each row corresponds to an imported Niagara schedule (read-only).
Configuration for each includes its name and whether it is enabled.

Figure 4-63 Schedule Import Manager under a NiagaraStation

When building a network in the station, you use this view to create, edit, and delete imported Niagara
schedules. In the case of a Niagara network (only), each schedule that you import results in the creation
of a remote “schedule export descriptor” in that remote Niagara station.
Following station configuration, this view provides a status summary for collecting imported schedules.
You can also use it to issue manual “Import” commands to one or more schedules. This causes an
immediate import request to pull schedule configuration data from the remote device.
Note: Only imported schedules appear in the Schedule Import Manager—any other components that may also
reside under Schedules do not appear. For example, you do not see the default “Retry Trigger” component
(see “About the Retry Trigger” on page 4-26), or if a NiagaraStation, schedule export descriptors. However,
the Nav tree and other views on Schedules provide you access to these items.
At the bottom of the view, the button “New” lets you manually create new imported schedules in the
station. An “Edit” button lets you edit a few properties of one or more imported schedules. Buttons
“Discover,” “Add” and “Match” are also available, (these work similarly as in the Point Manager). An
“Import” button is available to manually import (pull data) into one or more selected imported schedules.
Finally, depending on driver, additional buttons may be available.
For more details, see:
• Schedule Import New
• Schedule Import Edit
• About Schedule Import Discover, Add and Match (Learn Process)
Schedule Import New
Button New exists in a device’s Schedule Import Manager, but is used only if engineering offline (all
devices with a Schedules extension support online discovery). If used, Match2 may be used later (when
online with the device).
Note: A New tool is also on the Schedules Import Manager toolbar, and in the Manager menu.
Schedule Import Edit
In the Schedule Import Manager, you can Edit selected properties of a schedule in the station database
by simply double-clicking it.
Edit The Edit dialog appears with the imported schedule listed (Figure 4-64).

NiagaraAX-3.x
4-45
User Guide
About Schedules extension views Chapter 4 – Driver architecture
Schedule Import Manager May 1, 2007

Figure 4-64 Edit dialog in Schedule Import Manager (Bacnet)

Note: The Edit dialog shows some properties of the schedule’s ScheduleImportExt, plus Name—equivalent to the
right-click Rename command on the schedule component). To access all properties of the schedule
(including all status properties) go to its property sheet, or to see the imported schedule events, to its Weekly
Scheduler view.
To access the Scheduler, in the Nav tree you can simply double-click the schedule.
The following related topics also apply:
• Schedule Import properties
• Schedule Import or Export “gang” edits
• Manager table features
Schedule Import properties Properties of imported schedules available in the Edit or Add dialog of the
Schedule Import Manager are as follows:
• Name
Name for the imported Niagara schedule component. If discovered, will match the name of the
source schedule. Must be unique among other components in same container.
Note: Editing name does not affect name of the source schedule, nor the name of the corresponding
schedule export descriptor (if source is a Niagara schedule).
• Supervisor Id
(NiagaraStation only) Unique slot path of source Niagara schedule in that station.
• Object Id
(BacnetDevice only) Combination of BACnet object type (schedule or calendar) and instance num-
ber (unique within that object type in that device).
• Enabled
Default is true. If set to false, the imported schedule is disabled.
Note: While disabled, the schedule’s Out slot has status disabled. Any downstream logic linked to
Out no longer processes it. See “About “isValid” status check” on page 3-18.
• Execution Time
(BacnetDevice only) Specifies how event-configuration refresh (import) occurs with source sched-
ule, using a “pull” request method. Options are Daily, Interval, or Manual (default).
If Manual, some properties below are not available, as noted:
• Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.
• Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds
and this interval is added to the Time of Day. May prevent “server flood” issues if too many
schedule imports execute at the same time. Default is zero (no randomization).
• Days of Week (Daily and Interval)
Select (check) days of week for import execution. Default is all days of week.
• Interval (Interval)
Specifies repeating interval for import execution. Default is every 15 minutes.
• Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).
• Last Trigger

NiagaraAX-3.x
4-46
User Guide
Chapter 4 – Driver architecture About Schedules extension views
May 1, 2007 Schedule Import Manager

Timestamp of when last interval or daily import occurred.


• Next Trigger
Timestamp of when the next interval or daily import is configured to occur.
Schedule Import or Export “gang” edits The Edit button in the Schedule Import (or Export) Manager
allows you to edit one or more items in a single dialog. Before clicking Edit, use standard Windows
keyboard controls to highlight (select) multiple items (e.g. hold down Ctrl key and click desired
schedules).
Note: Edit is also on the Schedule Import (or Export) Manager toolbar and the Manager menu, if any item in the
database is selected.
The “gang” edit feature is useful for making identical changes in multiple (selected) items. For example,
as shown in Figure 4-65 when using Edit in the Niagara Schedule Export Manager, you can change the
“Execution Time, Interval” in multiple schedule export descriptors at the same time (versus editing
individually). For more details, see “About gang edits.”

Figure 4-65 Example “gang edit” in Edit dialog of Schedule Export Manager

About Schedule Import Discover, Add and Match (Learn Process)


Unless working offline, you can use the learn process to import schedules in the station. As with other
NiagaraAX learns, this is a two-step process in the Schedule Import Manager, where you:
1.Under a selected device component, use its (Schedules extension) Schedule Import Manager view
to Discover schedules as candidates for inclusion in the station as Niagara schedules.
2. Select and Add from those candidates, creating imported schedules under the device’s Schedules
container.
Note: The Schedule Import Manager reinforces this process by providing two separate panes in the view whenever
you enter “Learn Mode.” See “About Learn toggle” on page 4-16.
Discover When you click Discover, the Schedule Import Manager splits into two panes (Learn Mode):
discovered items in top pane, and existing imported schedules in bottom pane (Figure 4-66).
A schedule discovery job (either Niagara or Bacnet) is started, with a progress bar at top.
• If Niagara schedules are found in the remote station, they are listed in the discovered pane.
• If BACnet Schedule and/or Calendar objects are found, they are listed in the discovered pane.
Note: A Cancel button is available during a discovery job. If needed, use it to stop discovery.

NiagaraAX-3.x
4-47
User Guide
About Schedules extension views Chapter 4 – Driver architecture
Schedule Export Manager May 1, 2007

Figure 4-66 Discover splits Schedules Import Manager

In Learn Mode, the two panes in the Schedule Import Manager operate as follows:

Discovered (top pane)
Lists schedule components (Niagara) or Schedule and/or Calendar objects (Bacnet) found in the de-
vice, as candidates for imported schedules. Any item that already exists as a schedule in the station
is “ghosted” (faintly listed).
• Database (bottom pane)
Lists schedules currently imported in the station database (contained in Schedules container).
Note: As necessary, drag the border between the two panes to resize. Also (at any time), toggle between the two-
pane Learn Mode and the single-pane (Database) view by clicking the Learn Mode tool in the toolbar
(Figure 4-24 on page 16), or using the Learn Mode command in the Manager menu.
Add The Add button is available in Learn Mode when you have one or more items selected (highlighted)
in the top discovered pane. When you click Add, a dialog allows you to edit properties before the schedule
is created in the station. The Add dialog and Edit dialog are identical.
Note: Whenever you select one or more items in the top discovered pane, the toolbar also has an available Add
tool (“plus” symbol), and the Manager menu has an Add command. Also, you can simply double-click a
discovered item to bring it up in the Add dialog.
For details on properties, see “Schedule Import properties” on page 4-46.
Match2 Match, as an online function, is available if you have one schedule selected in the top
(discovered) pane and one schedule selected in the bottom (database) pane. However, usage of Match
when importing schedules from a device (NiagaraStation, BacnetDevice) is generally not recommended.
Instead, use the Discover and Add method to import schedules.

Schedule Export Manager


The Schedules extension of a NiagaraStation, ObixClient/R2ObixClient, or BacnetDevice has an
available Export Manager view. It allows management of schedule components in the local station made
available to that remote device.
Like other managers, the Schedule Export Manager is a table-based view (Figure 4-67). Each row repre-
sents a schedule export descriptor. Each descriptor specifies how/when configuration for a local schedule
is “pushed” to either:
• An imported schedule component in the designated NiagaraStation.
• An existing BACnet Schedule object or Calendar object in the designated BacnetDevice, or existing
schedule in the designated oBIX server.

NiagaraAX-3.x
4-48
User Guide
Chapter 4 – Driver architecture About the Niagara Network
May 1, 2007 Schedule Export Manager

Figure 4-67 Schedule Export Manager under a NiagaraStation

Note: A Schedule Export Manager works differently in NiagaraNetworks and BacnetNetworks/ObixNetworks.


• For NiagaraStation, you do not create export descriptors using this view—there is no “Learn Mode,”
Discover, Add, or New. Instead, each schedule export descriptor is automatically created upon the
remote Niagara station “importing” a local schedule component. For more details, see “Station
Schedules import/export notes” on page 4-60.
• For a BacnetDevice or ObixClient, you do use Learn Mode to discover BACnet Schedule/Calendar
objects or oBIX schedules in the device. Then, you select and add any as schedule export descrip-
tor(s). In each export descriptor, you must specify the station’s local schedule component that “ex-
ports” (writes) its event configuration to that remote schedule object. For more details, see the
NiagaraAX BACnet Guide or NiagaraAX oBIX Guide.
After configuration, this view provides a status summary for exporting local schedules. You can also use
it to issue manual “Export” commands to one or more schedules. This causes an export “push” of
schedule configuration into the remote device.
Note: Only schedule export descriptors appear in the Schedule Export Manager view—any other components
that may also reside under Schedules do not appear. For example, you do not see imported schedules or the
default “Retry Trigger” component (see “About the Retry Trigger” on page 4-26). However, the Nav tree and
other views on Schedules provide you access to these items.

About the Niagara Network


Currently, by default every NiagaraAX station has a Niagara Network under its Drivers container. The
Niagara Network is where data is modeled that originates from other stations. Generally, this is done using
the same driver architecture used by other (non-Niagara) drivers. See “About Network architecture” on
page 4-2.
A Niagara Network has the following unique differences:
• All proxy points under a NiagaraStation are “read only” types, namely one of the following:
• BooleanPoint
• EnumPoint
• NumericPoint
• StringPoint
However, note that a Niagara proxy point inherits any actions from the originating (remote) point
or object. For more details, see “Niagara proxy point notes” on page 4-59.
• Connections between stations occur as client and server sessions using the Fox protocol. The re-
questing station is the client, and target (responding) station is the server. A Workbench connection
to a station operates identically, where Workbench is the client, and station is server. Client authen-
tication (performed by the server) is required in all Fox connections.
For more details specific to a Niagara Network, see:
• NiagaraNetwork component notes
• Niagara Station Manager notes
• NiagaraStation component notes
• About the Bql Query Builder

NiagaraAX-3.x
4-49
User Guide
About the Niagara Network Chapter 4 – Driver architecture
NiagaraNetwork component notes May 1, 2007

• Niagara proxy point notes


• Station Alarms notes
• Station Schedules import/export notes

NiagaraNetwork component notes


In addition to common network components (see “Common network components” on page 4-5), the
Niagara Network contains components specific to Niagara, namely:
• Fox Service
A container for Fox protocol settings affecting client connections made to the local station, such as
from Workbench or from another station. Such connections appear locally as “server connections.”
For details, see “About the Fox Service” on page 4-50.
• History Policies
A container for “rules” that specify how remotely-generated histories should be changed when these
histories are pushed into the station (that is, exported from remote stations). For details, see “About
History Policies” on page 4-51.
Also, Tuning Policies for a NiagaraNetwork are simplified, with only 3 properties, as follows:
• Stale Time
• If set to a non-zero value, points become “stale” (status stale) if the configured time elapses
without a successful read, indicated by Read Status “ok.”
• If set to zero (default), the stale timer is disabled, and points become stale immediately when
unsubscribed.
• Min Update Time
The minimum amount of time between updates sent from the server to the client. It is used to throt-
tle data changing at a rate faster than minUpdateTime. Default value is 1 second.
• Max Update Time
Used to resend the value if it hasn't been sent for other reasons (such as a change). Default value is
15 minutes.
About the Fox Service
The NiagaraNetwork’s Fox Service holds configuration for the local station’s Fox settings. (This varies
from most other services, which are found instead under the station’s ServiceContainer). Included are
properties for the TCP/IP port number assigned to the Fox server, authentication method used, and
various timeout/trace settings. Typically, most properties are left at default values. See Fox Service
properties for more details.
Authentication is required when establishing any Fox connection to/from the station:
• If opening a station in Workbench, you must enter a valid station username and password for it in
the station login dialog (otherwise it does not open).
• If accessing a station in a browser as a user with a User
• If adding a NiagaraStation to a station’s NiagaraNetwork, you must configure username and pass-
word properties under its Client Connection slot (otherwise it remains “down”). Often, you enter the
username and password of a “super user”-level account in that station. You also specify the software
port used by that station’s Fox server.
Note: Often in a multi-station job, in each station you create a user account specifically for station-to-station
communications, with an assigned profile type of “super user.” This is the account that you reference when
you edit a NiagaraStation’s Client Connection properties, entering its username and password. See “Multi-
station security notes” on page 9-8.
The Fox Service also has a Server Connections container slot with a default ServerConnectionsSummary
view. Client connections to the station’s Fox server are dynamically modeled as “SessionN” child compo-
nents. The summary view allows you to see all current connections, and if necessary, perform a right-click
Force Disconnect action on one or more connected users.
Fox Service properties NiagaraNetwork Fox Service properties are as follows:
• Port
Specifies well-known TCP/IP port used by Fox server (default is 1911).
• Authentication Policy
Either Digest Md5 (default) or Basic. Applies to password authentication when establishing a client
connection.
• If Digest Md5, user password is encrypted. This is the recommended setting.
• If set to Basic, password is passed in clear text. Typically, Basic is used only if using LDAP.

NiagaraAX-3.x
4-50
User Guide
Chapter 4 – Driver architecture About the Niagara Network
May 1, 2007 NiagaraNetwork component notes

• Request Timeout
Time to wait for a response before assuming a connection is dead (default is 1minute).
• Socket Option Timeout
Time to wait on a socket read before assuming the connection is dead (default is 1minute).
• Keep Alive Interval
Interval between keep alive messages (default is 5 seconds). The keep alive should be well below the
request timeout and socket option timeout.
• Enable Announcement
Either true (default) or false. Enables multicast announcement messages for learn/discover.
• Multicast Time To Live
Number of hops to make before a multicast message expires (default is 4).
• Server Connections
Provides status information about current Workbench client connections to the local station (does
not reflect station-to-station Fox connections).
• Trace Session States
Either true or false (default). Debug usage for tracing session state changes.
• Trace Read Frame
Either true or false (default). Debug usage for dumping frames being read from the wire.
• Trace Write Frame
Either true or false (default). Debug usage for dumping frames being written to the wire.
• Trace Multicast
Either true or false (default). Debug usage for tracing multicast messaging.
About History Policies
The NiagaraNetwork’s “History Policies” (HistoryNetworkExt) holds “rules” that are used when remote
histories are “exported” into the local station. Unlike imported histories, which let you define (and adjust
later, if needed) the “capacity” and “full policy” settings in each HistoryImportDescriptor, histories that
are exported into the station have no associated component—only the history itself. The capacity and “full
policy” for each history is set only at creation time, using the local history policies.
Note: You export histories into the station working under a remote station—meaning, from a view of the Histories
device extension under the NiagaraStation that represents this (local) station. See “History Export
Manager” on page 4-41.
For an example scenario showing histories in two JACE stations that are exported to a Supervisor station,
and how history policies apply, see Figure 4-68.
Additional details are in the following sections:
• Default history policies
• Config Rules
• Example rules

NiagaraAX-3.x
4-51
User Guide
About the Niagara Network Chapter 4 – Driver architecture
NiagaraNetwork component notes May 1, 2007

Figure 4-68 History Policies in a supervisor station

As shown in Figure 4-68, the Supervisor’s History Policies “Config Rules” determine the capacity and
fullPolicy settings for each history upon export from the JACE stations “WestWing403” and
“EastWing403”. Rules are matched to remote station (device) names and history names, which determine
the corresponding capacity and full policy values to apply upon history creation. If a history does not
match any rule, it is created using the same capacity and full policy as in the source history. For an
example related to this scenario, see “Example rules” on page 4-53.
Default history policies By default, under a NiagaraNetwork’s History Policies, only a single “default
rule” exists—with wildcard matches to “all” stations and history names, specifying “unlimited” capacity
and a “roll” fullPolicy. This means that any history that is exported into the station (from any remote
station) is archived using a local history configured with unlimited capacity.
Given the vast storage capacity of a supervisor host PC, the default “one rule” setting may be acceptable
on the target of most exported histories (supervisor station). However, if for some reason you are
exporting histories to a JACE station, you should definitely change the “Default Rule” of the History
Policies under its NiagaraNetwork to specify smaller capacities. Even for a supervisor station, you may
wish to change the default rule, and/or add additional optional config rules, as needed.
Config Rules When a history is exported to the station (from another station), these rules are evaluated
to set the local (archived) history’s config properties “capacity” and “fullPolicy.” The first matching rule
is used. The “Default Rule” is always at top, and cannot be deleted or renamed.
Note: Rule priority is set by order—as the “Default Rule” is always first, it is highest priority. If you create other
rules (in Workbench, right-click a rule, then click “Duplicate”), you can edit, rename, and reorder as
needed.
Each rule under the network’s History Policies has the following configuration properties:

NiagaraAX-3.x
4-52
User Guide
Chapter 4 – Driver architecture About the Niagara Network
May 1, 2007 NiagaraNetwork component notes

• Device Pattern
String matching to device names, meaning name of NiagaraStation(s) that are exporting histories.
Default value is a wildcard (“*”), meaning all station names are matched.
• History Name Pattern
String matching to history names of histories being exported. Again, default value is a wildcard (“*”),
meaning all named histories are matched.
Note: Both device pattern and history name pattern must apply for the rule to be used—otherwise
the next rule down (in order) in History Policies is evaluated.
• capacity
The capacity setting to use when creating the local history, if matched by device and history names.
Either “unlimited,” or “Record Count,” with a finite record specified.
• fullPolicy
Applies if capacity is not “unlimited,” and specifies if collection continues when the capacity record
limit is reached (“roll”) or collection stops (“stop”).
Example rules As shown in the three-station scenario of Figure 4-68, histories in two JACE stations are
exported to the “Supervisor” station. As shown in Figure 4-69, the receiving supervisor station has 2
additional config rules under its History Policies of its NiagaraNetwork.

Figure 4-69 Example history policies config rules (supervisor station)

In this example, the highest-priority “Default Rule” matches all (any) stations exporting, with a history
name pattern of “Audit*”—this matches any “AuditHistoryLog”. Capacity is set to unlimited, as all
history records are wanted for archive.
The next two rules are applied to histories exported (by any stations), as follows:
• MetersRule — This rule applies to any station, for any history named beginning with “Meter”
(“Meter*”). Any such history is archived using unlimited capacity, as all records are wanted.
• EastWins — This rule applies only to stations named beginning with “East” (“East*”), for any histo-
ry. Such a history is archived using a capacity of 100,000 and a “roll” full policy.
Following this example (with exported histories in the JACE stations, as shown in Figure 4-68), the
histories are created in station “Supervisor” as follows:
• WestWing403
Histories are exported using following capacity and fullPolicy (from config rule):
• AuditHistoryLog: unlimited, roll (from Default Rule)
• LogHistory: 500 records, roll (no rule matched, using source history config, as in JACE)
• Meter1: unlimited, roll (from “MetersRule”)
• ZoneTemp1: 500 records, roll (no rule matched, using source history config, as in JACE)
• Meter2: unlimited, roll (from “Meters Rule”)
• ZoneTemp2: 500 records, roll (no rule matched, using source history config, as in JACE)
• EastWing403
Histories are exported using following capacity and fullPolicy (from config rule):
• AuditHistoryLog: unlimited, roll (from “Default Rule”)
• LogHistory: 100,000 records, roll (from “EastWins” rule)
• Meter4: unlimited, roll (from MetersRule)

NiagaraAX-3.x
4-53
User Guide
About the Niagara Network Chapter 4 – Driver architecture
Niagara Station Manager notes May 1, 2007

• ZoneTemp1: 100,000 records, roll (from “EastWins” rule)


• Meter3: unlimited, roll (from Meters Rule)
• ZoneTemp2: 100,000 records, roll (from “EastWins” rule)
Again, note that the rules are processed in priority order. In this example, if the two optional rules were
reordered (“EastWins” above “MeterRule”) before the JACE histories were exported, results would differ.
“Meter” histories from EastWing403 would have a 100,000 record capacity instead.

Niagara Station Manager notes


The Station Manager is the default view for the Niagara Network. It operates like the Device Manager for
most drivers that have online “device discovery” capability. For general information, see “About the
Device Manager” on page 4-12.
When using the Station Manager, the following notes apply:
• Station Learn and Discover notes
• Station Add notes
Station Learn and Discover notes
By default, a station discover uses IP address (vs. host name). Typically, this is the recommended method.
However, if Niagara hosts are installed on a network using DNS, you can toggle the discovery method to
use host name instead. Do this in the table options menu (click upper right small control) of the Station
Manager, as shown in Figure 4-70. You can also select other columns for display, and sort on any column.
See “Manager table features” on page 4-19 for more details.

Figure 4-70 Station Manager table options menu

By default, discovered stations list showing address. If a station uses a Fox port other than 1911 (default),
address includes the port number appended, for example: 192.168.1.112.1912.
Station Add notes
When you add a NiagaraStation to the database, the Add dialog includes its Fox port, along with fields
for station username and password (required for client connection) as shown in Figure 4-71.

NiagaraAX-3.x
4-54
User Guide
Chapter 4 – Driver architecture About the Niagara Network
May 1, 2007 NiagaraStation component notes

Figure 4-71 Add dialog for NiagaraStation

Typically, you enter a user name and password for a “super user” that exists in the remote station. By
convention, this may be a user especially for station-to-station access (for example, a user “m2m”). See
“Multi-station security notes” on page 9-8 for more details.
Note: When working in an AxSupervisor station running AX-3.1 or later, additional “platform” properties are
present, to specify the platform daemon credentials the Provisioning Service should use to connect to the
remote JACE platform, to run provisioning jobs. For more details, see “New station notes” in the Provi-
sioning Guide.
Note: After you add a station, in the Station Manager’s database pane just double-click it to bring up the Edit
dialog, which provides access to the same properties in the Add dialog (Figure 4-71). Or, you can access all
client connection properties from the NiagaraStation component’s property sheet (“Client Connection” slot,
along with status properties).
Adding a NiagaraStation automatically creates a reciprocal NiagaraStation in the remote station.
Reciprocal NiagaraStation component When you add a station under the Niagara Network, that
remote station automatically adds a “reciprocal” NiagaraStation component under its own Niagara
Network, representing your local station. However, it is created with its “Enabled” property set to false,
and so has a status of “disabled” (gray on gray background). This provides a visual clue for you to edit its
client connection username and password to a valid user account in the reciprocal station, and to set
Enabled back to true for operation.

NiagaraStation component notes


Explains items unique to Niagara Station components versus other device components.
• About station status properties
• About client connection properties
• About server connection properties
• About station “provisioning” extensions
About station status properties
Station status properties are typical of most device status properties. See “Device status properties” on
page 4-20.
About client connection properties
Client connection properties determine the Fox port used for station and Workbench connections, as
well as the user name and password used for station-to-station connections. Many properties are status
types, that contain either real-time or historical information.
About server connection properties
Server connection properties are all status properties that provide either real-time or historical infor-
mation.
About station “provisioning” extensions
In AX-3.1 or later, the NiagaraNetwork in an AxSupervisor station (only) has NiagaraStation components
that each contain four provisioning device extensions (in addition to the standard device extensions
described in “Types of device extensions” on page 4-24). For more details, see “Types of provisioning
extensions” in the Provisioning Guide. Note that provisioning extensions do not appear in the Station
Manager view, but do appear in the Nav tree.

NiagaraAX-3.x
4-55
User Guide
About the Niagara Network Chapter 4 – Driver architecture
About the Bql Query Builder May 1, 2007

About the Bql Query Builder


The Bql Query Builder is the initial dialog you use when you “Discover” proxy points in a station
under the Niagara Network. You also use it in discovers in other managers, for example, the Bacnet
Export Manager.
This dialog provides extensive Find and Match filters, plus other controls, which are briefly discussed in
the following sections:
• About Bql Query Find filters
• About Bql Query Match filters
• About Bql Query Save, Load, and Edit
Note that the default point Discover for a NiagaraStation produces a Bql Query Builder dialog with a Find
of (all) “Config,” type “Control Point,” and Match of “All,” as shown in Figure 4-72. While this may be
usable, typically you narrow this range, and run multiple point discovers, as needed.

Figure 4-72 Default Bql Query Builder from NiagaraStation point Discover

About Bql Query Find filters


By default, the Find filter preselects all control points in the target NiagaraStation (Config). Often, you
may wish to narrow this range. For example, you may wish to find Boolean proxy points only under a
specific driver network (during this particular Discover sequence).
To do this, simply click the Find icon (magnifying glass) which produces the Choose Root dialog, as
shown in Figure 4-73.

Figure 4-73 Choose Root dialog

As needed, expand Config to select the root component of interest and click OK (or simply double-click
the component of interest). The proxy point Find is now limited to that area of the station.
To change the type of component, click the “Of type” drop-down and make a selection (Figure 4-74).

NiagaraAX-3.x
4-56
User Guide
Chapter 4 – Driver architecture About the Niagara Network
May 1, 2007 About the Bql Query Builder

Figure 4-74 Select component type

The proxy point Find is now limited to that class of component.


Note: A basic understanding of the NiagaraAX component class structure is helpful when making type selections.
For example, selection of Boolean Point (as shown in Figure 4-74) includes all components that “subclass”
from the simple BooleanPoint. Included are all BooleanWritables, as well as many kitControl components
(Logic components, as one example in this case).
If you select type “Component,” you have a “full-width find.” This means that all components are
included—this includes everything listed in the “Of type” drop-down, plus extensions and many other items
(including kitControl objects not subclassed from Control Points, for example, “NumericConst,”
“DegreeDays,” and “LeadLagRuntime,” as a few examples).
About Bql Query Match filters
Use the Match filter when you wish to further limit proxy point candidates. For example, you may wish
to filter on object names (this translates to displayNames).
To see the match dialog options, click the plus (“+”) icon in the far right corner of the Bql Query Builder
dialog, and use Match entry fields as needed (Figure 4-75).

Figure 4-75 Expand Match to see fields, use entry fields as needed

In the Figure 4-75 example above, the Match filter is set to: displayName, like, “Fan*”. This point
discover returns components (within the Find parameters) that are named beginning with “Fan”.
This match would include all components named “Fan”, “FanAhu1”, “Fan21”, “Fantastic”, and so on.
However, components named “FAN” or “FAN21” would not be included (case-sensitivity), nor would
components named “AhuFan” or “BFan” be included—no leading wildcard (“*”) was used.
Note: You can click the Match plus (“+”) icon multiple times to add multiple match lines, and configure each
match line differently, as needed. Click the minus “–” icon to remove a match line.

NiagaraAX-3.x
4-57
User Guide
About the Niagara Network Chapter 4 – Driver architecture
About the Bql Query Builder May 1, 2007

If you have multiple match lines, note the drop-down selection beside Match (“All”, “Any”) becomes
important, and works as follows:
• All — Works as “AND” logic, where a match must occur as specified on every match line.
• Any — Works as “OR” logic, where a match must occur as specified on any match line.

About Bql Query Save, Load, and Edit


Save the setup of any Bql query by simply clicking the Save query icon (diskette). This produces a
Save Query dialog in which you give the query a unique name (Figure 4-76).

Figure 4-76 Save and name Bql Query

Saving a query allows you to recall it later to either use directly, or to modify further as a “starting point”
for another query. You can save as many Bql queries as you need. You can also edit a saved query
(meaning rename it or reorder it in your list of saved queries).
Note: Saved queries are unique to your Workbench instance, and not to any particular station.
To recall a saved query, click the Load saved query icon (folder), and make a selection, as shown in
Figure 4-77.

Figure 4-77 Load saved Bql Query

This loads that query into the Bql Query Builder dialog, where Find and Match entries automatically
change to reflect how that query was constructed.
To edit saved queries, click the Edit saved query icon (note pad). This produces a Save Query
dialog in which you can rename and/or reorder the queries in the list (Figure 4-78).

NiagaraAX-3.x
4-58
User Guide
Chapter 4 – Driver architecture About the Niagara Network
May 1, 2007 Niagara proxy point notes

Figure 4-78 Edit saved Bql Queries

Note: If you are interested in the Baja Query Language (BQL), you can learn about queries within the Edit dialog.
Make the dialog window wider, and study the syntax of a saved queries. For detailed information about
queries, see “BQL” in the Niagara Developer Guide.

Niagara proxy point notes


Niagara proxy points are always read-only types (BooleanPoint, EnumPoint, NumericPoint, and String-
Point), see “About point types” on page 3-2. No other types are available.
However, if the source component is a writable point type, any actions (commands) for that component
are available in the Niagara proxy point, as shown in Figure 4-79.

Figure 4-79 Niagara proxy point for writable point includes actions

Other concepts about Niagara proxy points are explained in the following sections:
• Proxy of a proxy, other candidates
• Link control and Niagara proxy points
Proxy of a proxy, other candidates
Often, the (remote) source component of a Niagara proxy point is itself a proxy point, typically under the
Points extension of device in a field bus driver network (Lonworks, Bacnet, and so on). Or, if the remote
station is in a JACE with its own I/O, the source component may be an Ndio proxy point.
Another possibility is for the (remote) source component to be a specific slot of a point extension under
a point, for example, the Total property of a NumericTotalizerExt. In other cases, the (remote) source
component may be a kitControl type, such as one of the Math or Logic types, or one of the other more
complicated types (for example, a LoopPoint or DegreeDays object).
Regardless of the source component, you model all remote Niagara data selecting from the “atomic”
model of the four read-only point types. If you need multiple pieces of data from the same source Niagara
object, you will need to create that many Niagara proxy points.
Link control and Niagara proxy points
Because Niagara proxy points have no inputs, you cannot link into them from local station logic (even if
the remote source component is a writable type). If you need this “inter-station link control,” you must
make another Niagara proxy point (in the remote station) that proxies whatever local source component
you need for the link.

NiagaraAX-3.x
4-59
User Guide
About the Niagara Network Chapter 4 – Driver architecture
Station Alarms notes May 1, 2007

Consider a Niagara proxy point for a BooleanWritable that controls a fan. You wish to provide link
control from a local And object, controlling at priority level 7. Figure 4-80 shows these objects.

Figure 4-80 Local object cannot link into Niagara proxy point

In the example above, you cannot link into the Niagara proxy point “BFanBO_1.”
So in the other (remote) station, you must make a Niagara proxy point for the And object, then link its
output to the source point for “BFanBO_1.” Figure 4-81 shows the wire sheet views with these objects.

Figure 4-81 Source control object now a Niagara proxy point in remote station

In a typical Supervisor station (with many Niagara proxy points), usually not much direct link control is
needed, so this rarely applies. In addition, the schedule import/export mechanism allows for central
scheduling control using local (imported) schedule components.
However, if you are engineering applications between JACE stations that require link control, please
understand you must always use Niagara proxy points in this fashion.

Station Alarms notes


To configure alarms in one station to be received in another station, you must add a StationRecipient in
the AlarmService container of the “sending” (source) station. See “About the station recipient” on page
7-22 for configuration details. You then link whatever AlarmClass components are needed to that
StationRecipient. See “About alarm class” on page 7-15 for more details.
It is not necessary to use the same AlarmClass components in the two stations (although that is one
approach). In the receiving station (often, the Supervisor), if desired you can configure all alarms from a
remote station to route to a single local AlarmClass. Do this in the Alarms extension under the Niagar-
aStation that represents the remote JACE. See “Alarms extension properties” on page 4-26.
Note: In the receiving station’s AlarmService, if you want the remotely-generated alarms to appear in any alarm
consoles, make sure to link the associated AlarmClass components to the necessary AlarmConsole compo-
nents.

Station Schedules import/export notes


You configure sharing of NiagaraAX schedule components between stations from the “receiving side”
station using the Niagara Schedule Import Manager. After you import each schedule component, a
corresponding “schedule export descriptor” is automatically created in the “sending side” station. If
necessary, you can review and adjust these export descriptors using the Niagara Schedule Export Edit
dialog.

NiagaraAX-3.x
4-60
User Guide
Chapter 4 – Driver architecture About the Niagara Network
May 1, 2007 Station Schedules import/export notes

Under a NiagaraStation device, the Schedule Export Manager works uniquely from other drivers, so it is
explained in more detail in the following sections.
• Niagara schedule import/export default configuration
• Schedule Export Edit
• “Schedule Import or Export “gang” edits” on page 4-47
Niagara schedule import/export default configuration
By default, when you import a schedule under a NiagaraStation using the Schedule Import Manager, the
import/export setup is initially configured on both sides as follows:
• Receiving (slave) side:
Niagara schedule component with a ScheduleImportExt configured with “Execution Time” of Man-
ual. The source schedule’s configuration is imported (“pulled”) only once, upon creation. If desired,
you can manually Import it again.
• Sending (master) side:
Corresponding schedule export descriptor with an “Execution Time” of Interval, at 5 minute rate.
You can adjust this in the export descriptor using Schedule Export Edit.
To review all properties of a schedule export descriptor, including status properties, you can view
its property sheet—in the Nav tree under Schedules, simply double-click its Export icon.
Note: Default configuration does not mean the same schedule configuration is continuously
exported (“pushed”) to the remote schedule at this rate. Instead, the export descriptor keeps a “Subor-
dinate Version” timestamp from the last export. If a configuration change occurs, the export descriptor
compares the subordinate version time against the configured interval, and if necessary exports the
schedule to the remote station.
The default “master push” configuration is the most efficient (and recommended) way to keep imported
schedules synchronized. However, if the stations are installed on a network configured such that this
method is not allowed (perhaps firewall issues), you can configure things in reverse. This means config-
uring receiving side ScheduleImportExts with “Interval” execution times (to periodically “re-pull”
schedule configuration), and set corresponding schedule export descriptors to be disabled.
Schedule Export Edit
In the Schedule Export Manager, you adjust any schedule export descriptor(s) shown by selecting
(highlighting) it and clicking the Edit button at the bottom of the view (or on the toolbar).
Note: Unlike in other Manager views, a double-click on a descriptor is not the same as Edit. Instead, double-click
provides the Scheduler view for that exported schedule component. This can be useful to review and if
necessary, make changes to its configuration. For details, see “Schedule component views” on page 10-2.
Edit The Edit dialog appears with the schedule export descriptor listed (Figure 4-82).

Figure 4-82 Edit dialog in Schedule Export Manager

Note: The Edit dialog shows some configuration properties of the schedule export descriptor.
To access all properties, (including all status properties) go to its property sheet. Note that if you double-
click the Nav tree icon for an export descriptor, its property sheet displays.
The following related topics also apply:
• Niagara Schedule Export properties
• Niagara schedule import/export default configuration
• “Manager table features” on page 4-19
Niagara Schedule Export properties Properties in the Edit dialog of a schedule export descriptor are:
• Enabled
By default true. While set to false (export descriptor disabled), export connections are not attempted

NiagaraAX-3.x
4-61
User Guide
About the Niagara Network Chapter 4 – Driver architecture
Station Schedules import/export notes May 1, 2007

to update the remote (imported) schedule.


• Execution Time
Determines when an export update is made to the remote (imported) schedule, providing that a con-
figuration change occurred in the local schedule that requires synchronization (export). For more de-
tails, see “Niagara schedule import/export default configuration” on page 4-61.Options are either
Daily, Interval (default), or Manual. If Manual, the following properties are unavailable:
• Time of Day (Daily)
Configurable to any daily time. Default is 2:00am.
• Randomization (Daily)
When the next execution time calculates, a random amount of time between zero milliseconds
and this interval is added to the Time of Day. May prevent “server flood” issues if too many
schedule exports are executed at the same time. Default is zero (no randomization).
• Days of Week (Daily and Interval)
Select (check) days of week for archive execution. Default is all days of week.
• Interval (Interval)
Specifies repeating interval for export execution. Default is every 15 minutes.
• Time of Day (Interval)
Specifies start and end times for interval. Default is 24-hours (start 12:00am, end 11:59pm).

NiagaraAX-3.x
4-62
User Guide
CHAPTER 5
Field Bus Integrations
For purposes here, a field bus integration is any NiagaraAX driver besides the niagaraDriver (Niagara
Network). All Niagara AX drivers resemble each other in basic architecture, including the Niagara
Network. For more details, see “About Network architecture” on page 4-2, and “About the Niagara
Network” on page 4-49.
Field bus integrations such as BACnet, LON, Modbus, as well as various “legacy” drivers (typically serial-
connected) each have unique characteristics and features. This section provides a collection of topics that
apply to some of these drivers.
The following main sections are included:
• Port and protocol variations
• Learn versus New devices and points
• Serial tunneling

Port and protocol variations


With one exception, each field bus driver (network) associates with only one physical communications
port on the host platform, and uses a specific communications protocol. The exception is the BACnet
driver (BacnetNetwork), where multiple ports (Ethernet, RS-485 for MS/TP) and protocol variants
(BACnet-Ethernet, BACnet-IP, BACnet-MS/TP) may be used. See the Bacnet Guide for details.
Generally, field bus drivers can be categorized as one of the following:
• Ethernet-connected driver
• Serial-connected driver
• Special-port driver

Ethernet-connected driver
Many field bus drivers are Ethernet (port) connected, typically using some TCP/IP protocol for transport.
For example, the Modbus TCP driver (ModbusTcpNetwork) uses the Modbus TCP protocol—essentially
the Modbus protocol “wrapped” in TCP/IP. The SNMP driver (SnmpNetwork) uses SNMP, an appli-
cation-layer protocol within the TCP/IP protocol suite. These and other Ethernet-connected drivers
operate from a single Ethernet port without difficulty, due to the high bandwidth and efficiencies of IEEE
802 network (and TCP/IP) standards.
In addition to JACE platform usage, Ethernet-connected drivers are available for the AxSupervisor (PC)
platform as well, for “direct device integrations.” These are specially-licensed versions of the AxSuper-
visor (by default, an AxSupervisor is licensed only for JACE device communications, via the Niagar-
aNetwork).

Serial-connected driver
Serial-connected drivers use a specific serial port on the host (JACE) platform. For example, the Modbus
serial driver (ModbusAsyncNetwork) requires association with a specific COMn port on the JACE, which
you do from the property sheet of this network component (Figure 5-1).
Note: Only one network can be assigned to any one serial port (COMn) of the host JACE platform. That driver
network essentially “owns” that communications port.

NiagaraAX-3.x
5–1
User Guide
Learn versus New devices and points Chapter 5 – Field Bus Integrations
Special-port driver May 1, 2007

Figure 5-1 Serial port configuration for a serial-based driver

Slots under the “Serial Port Config” (SerialHelper) must be set to match the communications parameters
of other devices on the attached network. Note that in this ModbusAsync example, you also select either
the Modbus ASCII or Modbus RTU protocol (the driver supports either one, which you set according to
the type of networked Modbus devices).
Often, serial-connected drivers support “legacy type” device networks. In this case, the “serial tunneling”
feature may be useful to run vendor-specific legacy Windows applications to do device configuration and
maintenance (all from an IP station connection). See “Serial tunneling” on page 5-2.

Special-port driver
JACE controllers may include one or more special-use ports, for example one or more Echelon (LON)
FTT-10 ports. Usage of such a port requires a specific driver. In this example, the Lonworks driver (each
LonNetwork) associates with a specific LONn port, which is configured under that network component.
For details, see the Lonworks Guide.
Other special-use ports may appear as the evolution of JACE products continue.

Learn versus New devices and points


Many, if not most, field bus drivers provide the ability to “learn” devices and data points while connected
to that particular field bus. Exceptions include drivers where the field bus protocol does not provide the
ability for this, for example, any of the Modbus drivers.
For specific learn procedures, see the “Quick Start” section in the various driver documents.

Serial tunneling
A NiagaraAX station running one or more serial-based drivers can provide “tunneling” access to its
connected devices. This allows you to use a vendor’s Windows serial-based application (via the serial
tunnel client) to perform device-specific operations. Examples include application downloads or other
device configuration.
The tunneling client is separate from NiagaraAX Workbench—meaning that you can install it on various
PCs, as needed. The key advantage is that serial tunneling requires only a standard IP connection (to the
station), yet provides access as if the client PC was attached to the target serial network via a physical
COM port, for example RS-232.
Note: No special licensing is required to use tunneling features in NiagaraAX.
The following sections provide more details:
• Serial tunnel overview
• Client side (PC application)
• Station side (TunnelService)
• Serial tunneling usage notes

Serial tunnel overview


As shown in Figure 5-2, tunneling in NiagaraAX uses a client-server architecture.

NiagaraAX-3.x
5-2
User Guide
Chapter 5 – Field Bus Integrations Serial tunneling
May 1, 2007 Client side (PC application)

Figure 5-2 Serial tunnel architecture

Serial tunneling uses the following components:



Client (PC application) side
The NiagaraAX Serial Tunnel client installs on any Win32-based PC (independent of Nia-
gara Workbench). It provides a “Niagara AX Serial Tunneling” applet in the Windows Control Pan-
el, corresponding to a “virtual” COMn port. For details, see “Client side (PC application)” on page 5-3.
• Server (station) side
The host JACE must have the “tunnel” module installed to support serial tunneling. In addition, its
station must be configured with a TunnelService and a child SerialTunnel component. For
details, see “Station side (TunnelService)” on page 5-5.
Note: A LonTunnel (“lontunnel” module) is also available, and uses the same basic architecture. It allows
Lonworks application tunneling to connected LON devices on a JACE’s FTT-10 network. For details, see
“Lon tunneling” in the Lonworks Guide.

Client side (PC application)


The serial tunnel client is a self-installing executable: Install_Serial_Tunnel.exe, found in the
root of the NiagaraAX distribution CD (Figure 5-3). As needed, you may install it on any Windows XP/
2000 PC on which you use a Windows serial-based application.

Figure 5-3 Serial Tunnel Client installation file is in NiagaraAX CD root

See the following additional sections:


• Installing the serial tunnel client
• Serial tunnel client configuration
• Serial tunnel client installation details
Installing the serial tunnel client

To install the serial tunnel client


To install the serial tunnel client, at the Windows XP/2000 PC do the following:
Step 1 Access the file Install_Serial_Tunnel.exe, as found on the NiagaraAX CD (Figure 5-3).
Step 2 Double-click this file to launch the installation.
Click Yes to install (a command prompt window opens), and other popup appears (Figure 5-4).
Click Yes again to configure.
Step 3 In the Niagara AX Serial Tunnel dialog, enter any known information, or simply accept defaults
(Figure 5-5). Do not duplicate any existing serial (COMn) port already used by Windows. You can always
reconfigure using this dialog, by returning via the Windows Control Panel.
See “Serial tunnel client configuration” on page 5-4 for details on all fields in this dialog.
Step 4 Click OK to finish the install.

NiagaraAX-3.x
5-3
User Guide
Serial tunneling Chapter 5 – Field Bus Integrations
Client side (PC application) May 1, 2007

The “Installation Finished” dialog appears (Figure 5-6)—click OK again. See “Serial tunnel client instal-
lation details” on page 5-5 for a listing of installed components.

Figure 5-4 Serial tunnel client installation

Figure 5-5 Serial tunnel client configuration defaults

Figure 5-6 Serial tunnel client installation finished

Serial tunnel client configuration


After installation, access the serial tunnel configuration dialog from the Windows Control Panel. As
shown for an example session in Figure 5-7, all fields require a valid entry.

Figure 5-7 Serial tunnel client session example

Fields in this dialog are described as follows:


• Serial Port
The “virtual” COM port provided by this tunnel client. This should not conflict with any existing
COM port assignment, as known to Windows, for a physical serial port (e.g. COM1).
When you tunnel from a serial-based Windows application, you specify this “virtual” COM port.
• Host Address
The IP address (or hostname) of the tunnel server, meaning the target JACE running a station with
a serial-based network, TunnelService, and SerialTunnel.
• Tunnel Name
The COMn device name (identifier) of the JACE’s driver network to access. This will vary depending
on the configuration of the network and its corresponding SerialTunnel.

NiagaraAX-3.x
5-4
User Guide
Chapter 5 – Field Bus Integrations Serial tunneling
May 1, 2007 Station side (TunnelService)

• User Name
User in the target JACE station, where this station user must have admin write permissions for the
station’s TunnelService and child SerialTunnel(s).
• Password
Password for this station user.
• Interactive (checkbox)
If checked, this dialog reappears each time a serial-based application first opens this “virtual” COM
port. If cleared, this dialog displays only if an open fails to establish a connection to the tunnel server
(as stored from last entry). Typically, you leave Interactive checked.
Note: When this dialog appears interactively, the Serial Port setting is read-only. To change it,
you must access the Serial Tunneling applet from the Windows Control Panel.
Serial tunnel client installation details
You can install a newer version of the serial tunnel client without uninstalling the current version. The
following files are installed, with services referenced in the Windows registry:

Control Panel
<WINDOWS_SYSTEM_DIR>\vserax.cpl
• Network Tunnel Service
<WINDOWS_SYSTEM_DIR>\vserax.exe
Service name: vseraxSvc (vserax dependency)
• Serial Driver Service
<WINDOWS_SYSTEM_DIR>\vseraxx.sys
Service name: vserax
• Uninstaller
<WINDOWS_SYSTEM_DIR>\vseraxun.exe
Executable via “Add/Remove Programs” in Windows Control Panel
Note: If uninstalling (Start > Control Panel > Add or Remove Programs), and the uninstall
appears to fail, try reinstalling the tunnel client, and then uninstall again.

Station side (TunnelService)


To be a serial “tunnel server,” a JACE must have the tunnel module installed, and its station must have
a TunnelService (under its Services folder), as well as a child SerialTunnel component.
The following sections provide more details on the “station side” of serial tunneling:
• Configuring the serial tunnel server
• About serial tunnel connections
Configuring the serial tunnel server

To configure the station for serial tunneling


To configure the station for serial tunneling, do the following:
Step 1 In the palette side bar, open the tunnel palette.
Step 2 Open the JACE station and expand its Services folder.
• If no TunnelService exists, paste one from the palette into the Services folder.
• If a TunnelService does exist, go to next step.
Note: Only one TunnelService is needed in a station’s services, and it can hold multiple tunnel components
(SerialTunnel and LonTunnel). The TunnelService in the (serial) tunnel module is identical to the
TunnelService in the lontunnel module.
Step 3 From the palette, paste a SerialTunnel under the station’s TunnelService.
The station should now have a TunnelService and a child SerialTunnel component.
Step 4 In the SerialTunnel’s property sheet, expand the “Serial Port Config container” (Figure 5-8).
Here, type in the COMn “Port Name” used by the target driver network, and specify other parameters as
defined in the network’s configuration.
See SerialHelper on page 31 for details on various properties.
Note: If the JACE has multiple serial-type driver networks (and corresponding COM ports), you can copy the
same number of SerialTunnel components under the TunnelService. You can then associate each Serial-
Tunnel with a particular network (by its COMn port name), and set the other parameters accordingly.

NiagaraAX-3.x
5-5
User Guide
Serial tunneling Chapter 5 – Field Bus Integrations
Station side (TunnelService) May 1, 2007

Step 5 For any station user that needs to serial tunnel, make sure that they have admin write permissions for the
SerialTunnel(s). Following this and the review of SerialTunnel properties, tunneling is now provided by
the station.

Figure 5-8 TunnelService with child SerialTunnel (copied from tunnel palette)

About serial tunnel connections


Under any SerialTunnel, only one tunnel connection is supported at any one time—if a tunnel connection
is active and another tunnel client (PC) attempts to connect, that remote user sees a popup dialog saying
that the “Desired tunnel is busy.”
In the station (tunnel server), any active tunnel connection results in a TunnelConnection child
component, named as the remote (client’s) IP address or hostname, with a “#1” suffix (Figure 5-9).

Figure 5-9 TunnelConnection is dynamically created/removed

In the Figure 5-9 example, the remote host that is currently serial tunneling is “192.168.1.103.” When
a tunnel connection is terminated, this Tunnel Connection component is removed.

NiagaraAX-3.x
5-6
User Guide
Chapter 5 – Field Bus Integrations Serial tunneling
May 1, 2007 Serial tunneling usage notes

In addition to its statistical properties, a TunnelConnection has an available Disconnect action. This
disconnects the active tunnel connection, removing the parent TunnelConnection component. A popup
dialog “Connection closed by remote host” is seen on the client tunnel side.

Serial tunneling usage notes


Serial tunneling may not work with all vendor’s serial-connected Windows applications. Also, serial
tunneling is not supported for BACnet MS/TP usage—however, BACnet router functionality provided by
a station running a BacnetNetwork with multiple network ports (e.g. IpPort, MstpPort) provides IP
access to MS/TP connected devices.
When initiating a connection through the serial tunnel, client-side usage is transparent except for the
“virtual COMn” port used, and if “Interactive” is left enabled (typical) the resulting dialog right before the
connection is attempted. Figure 5-10 shows an example serial connection being initiated from the
Windows Hyperterminal application. Tunneling client messages appear if the connection fails.

Figure 5-10 Example Windows serial application (Hyperterminal) initiating tunnel connection

Speed of the tunnel connection may be slower that a direct serial connection, due to the overhead of
wrapping and unwrapping messages in Niagara Fox and TCP/IP protocols. Tunneling is not recom-
mended if using a “dialup modem” for connection to the target JACE station.
Tunneling client messages
When using a tunnel client, the specified user must be “authenticated” by the station’s UserService before
a connection is granted (established). If the user is not found, or if the entered password is incorrect, a
popup message appears on the client PC (Figure 5-11).

Figure 5-11 Authentication issue

Note: As in any station connection, note that User Name and Password are case-sensitive.
Currently, only one tunnel connection is allowed per SerialTunnel. If another client application attempts
a connection to that tunnel, a popup message appears on that PC (Figure 5-12).

Figure 5-12 Tunnel busy

NiagaraAX-3.x
5-7
User Guide
Serial tunneling Chapter 5 – Field Bus Integrations
Serial tunneling usage notes May 1, 2007

NiagaraAX-3.x
5-8
User Guide
CHAPTER 6
About Histories
In Niagara, a data log is referred to as a history. Histories are ordered collections of timestamped records.
A single “history” is a collection of specific data values from a component within any station - local or
remote. Histories are organized by their source station (device), as shown in Figure 6-1.

Figure 6-1 History files organized by station

The following topics are relevant to understanding histories:


• History Services
The History Service, the Audit History service and the Log History service provide support for log-
ging data in a Niagara station. In order to provide database support for histories in a Niagara station,
the station must contain the History Service. Refer to “About the history service” on page 6-2 for de-
tails about the History Service. Refer to “About the audit history service” on page 6-3 and “About the
log history service” on page 6-4 for information about those services.
• History ORD scheme
Once you have a history service running, you can access histories that you create in the database us-
ing the “history” ORD scheme. The unique history scheme name “history” and each unique his-
tory ID provide identification for the individual histories. All history collections are identified by
this unique id. For information on using the ORD scheme to access individual histories, refer to
“About ORDs” on page 1-16.
• History space
History space provides a means for viewing and working with history files in the history database.
History space is visually represented in Workbench as a node in the nav tree and may be accessed by
using the nav tree or by using the Open ORD dialog box. Views on the History space include the fol-
lowing: History Chart Builder, Database Maintenance, Nav Container View. For more information
about history space and history space views, refer to “Types of history space views” on page 6-5.
• History views
History views present the history information in various formats for both analysis and editing. Refer
to “Types of history views” on page 6-9.
• History logging process
Using histories involves a process of collecting, storing and archiving data. You can configure the
history collection process to collect the data that you need and store the history records where you
want them - locally or remotely. This process is described in more detail in “About the history pro-
cess” on page 6-13.
• History Configuration
History configuration includes working with parameters such as ID, history source, timezone,
record type, and more. For more details on configuration, refer to “Configure history extensions” on
page 6-16.

NiagaraAX-3.x
6–1
User Guide
Types of History Services Chapter 6 – About Histories
About the history service May 1, 2007

• History data editing


You can edit and filter the history data in workbench using the history editor view (described in
“About the history editor view” on page 6-12). The editing process is described in more detail in
“About editing history data” on page 6-19.

Types of History Services


History services are available in the History Palette, as shown in Figure 6-2.

Figure 6-2 History services in the history palette

Each service is described in the following sections:


• “About the history service” on page 6-2
• “About the audit history service” on page 6-3
• “About the log history service” on page 6-4

About the history service


To use histories, each station must contain a single history service that provides http access to all of the
histories in a station. This service is responsible for creating the history database, as well as enabling the
collection and storage of histories in the database. If you do not have the history service in your active
station, you can add it by dragging and dropping a copy from the History Palette, as shown in Figure 6-3.

Figure 6-3 Adding the history service

The history service manages histories in ways that are not always visible to the user, including the
following:
• identifies histories
when the service is started (normally this is whenever the station is started) all existing histories are
added to the service.
• life cycle management
handles history management functions, such as creation and deletion of individual histories.
• namespace
maintains the naming convention (namespace) for all histories.
• configuration
maintains a global default configuration for the histories.
The history extension manager and the history property sheet are two views of the history service that
provide ways to work with history extensions. Refer to the following sections for more information about
these views:
• About the history extension manager
• About history service property sheet

NiagaraAX-3.x
6-2
User Guide
Chapter 6 – About Histories Types of History Services
May 1, 2007 About the audit history service

About the history extension manager


As the default view of the history service, the history extension manager shows all history extensions in
the station and displays their current status. Using this view as both a management and navigational tool,
you can double-click on any entry-row to go directly to the property sheet view of that extension. This
table has the standard table features. Use the Table Options menu in the top right corner of the
history table to modify the table view or to export the data in the view, as desired. Refer to “Table controls
and options” on page 2-17 for information about using the tabular view, including the Table Options
menu.

Figure 6-4 History extension manager

You can also Enable, Disable, or Rename any collection from this view by selecting the desired
history extension in the table and using the History Ext Manager menu, popup menu, or toolbar icons, as
described in the sections listed below:
• “About the History Ext Manager menu” on page A-8
• “About the history extension manager popup menu items” on page A-11
• “About the history extension manager toolbar icons” on page A-14
Note: If a history is disabled, its row is dimmed with a gray background in the history extension manager view.
About history service property sheet
The history service property sheet, shown in Figure 6-5, includes the following property:
• Max Open Time
this is an editable parameter for setting the amount of time that the history database may remain
open without being accessed before it is subject to being closed by the Close Unused Histo-
ries action. If the history is accessed more frequently than the Max Open Time, it is not closed
when Close Unused Histories action is invoked.

Figure 6-5 History service properties

History service actions


History service actions are available from the popup menu when you right-click the HistoryService node
in the nav side bar pane. Available actions include:
• Save Db
this action initiates a save of all histories to the history database.
• Close unused histories
this action closes any histories that have not been accessed within the Max Open Time (this time is
set in the history service property sheet).

About the audit history service


The Audit History Service keeps a history of the changes that are made by users. If this service is enabled,
it registers itself as the auditor for the system when the service is started. The easiest way to add the audit
history service (if not already present) is through a simple drag and drop method from the History Palette
(under the HistoryService) to the services area of the nav side bar pane, as shown in Figure 6-6.

NiagaraAX-3.x
6-3
User Guide
Types of History Services Chapter 6 – About Histories
About the log history service May 1, 2007

Figure 6-6 Adding audit history service

When enabled, the Audit History Service logs all property changes and all actions taken on a component,
such as the following:
• Property changed
• Property added
• Property removed
• Property renamed
• Properties reordered
• Action invoked
You can view the Audit History Service properties, enable or disable the Audit History Service, and set
record capacity parameters from the Audit History Service Property Sheet, as shown in Figure 6-7.

Figure 6-7 Audit history service properties

Refer to “About user audits” on page 9-7 for more details.

About the log history service


The Log History Service keeps a History of Niagara log records when it is enabled. This service maintains
a buffered history (“LogHistory”) of some of the messages seen in the station’s standard output. This can
be very helpful when you are troubleshooting problems with a station. If a station has Log History Service
enabled, you can check the log history for recent error messages. Refer to the Platform Guide section
“Station output” for more information about output messages.
The Log History Service is available in the History Module. The easiest way to add this service (if not
already present) is through a simple drag and drop from the History Palette (under the HistoryService)
onto the services area of the nav side bar pane, as shown in Figure 6-8.

NiagaraAX-3.x
6-4
User Guide
Chapter 6 – About Histories Types of history space views
May 1, 2007 About the log history service

Figure 6-8 Adding log history service

You can edit the Log History Service properties and set configuration properties in the property sheet, as
shown in Figure 6-9.

Figure 6-9 Log history service properties

In addition to the standard HistoryConfig properties, the following properties are available for editing:
• Enabled
select the true option to enable or the false option to disable the Log History Service.
• Minimum Severity
you can choose the level of output that you want to record by setting the log level Minimum Severity
property. This property is the lowest-level station output message that you want to log. The default
log level for Minimum Severity is Error. You can change this to Warning., Trace, or Message.

Types of history space views


The history space views shown in Figure 6-10 and listed below are particularly helpful in working with
multiple histories:

Figure 6-10 History space views

• Chart builder view


This is the default view of the History Space node (in the nave tree). Use this view to build any one
of several types of chart options from the data that is stored in one or more histories. See “About the
chart builder view” for details.
• Database maintenance view
Use this view to clear records or delete histories. Refer to “About the database maintenance view” on
page 6-8 for more information about this view.
• Nav container view
Use this view to display all histories in the station. See “About the nav container view” on page 6-9
for more details about this view.

NiagaraAX-3.x
6-5
User Guide
Types of history space views Chapter 6 – About Histories
About the chart builder view May 1, 2007

About the chart builder view


The chart builder view displays in Workbench, in all Workbench (Wb)Web profiles, and with
NiagaraAX-3.2 and later, the Default Hx, and Basic Hx profiles, as well.
Note: The following description discusses the Chart Builder view in terms of the Wb Web and the desktop
Workbench display profiles. Stations using NiagaraAX-3.2, can display the Chart Builder view in the
browser using the Default and Basic Hx (non-Java applet) profile views. Views displayed using Hx look
different but behave very similarly to the Workbench view. All field descriptions apply to both views.
The Chart Builder Workbench view (also Wb Web profile view) is shown in Figure 6-11, the Chart
Builder Hx view is shown in Figure 6-12. Using this view, you can select the histories, title, and configure
the charts that you want to generate.

Figure 6-11 Chart builder view (NiagaraAX-3.1 and later)

Figure 6-12 Chart builder view (NiagaraAX-3.2 and later Hx Web profile)

The display of the Chart Builder view is divided into three primary areas:
• Display configuration fields
• Time Range
Select a time parameter option from the list, including an option that allows you to set a specific
time range using the Edit Time Range dialog box.
• Title
Type a title for your chart in this text field.
• Grid Lines
Select Show or Hide to show or hide grid lines on the history chart.
• Rollup
Rollup (or Rollup Interval) is an interval of time that is used to determine what (and how) data
is presented in your chart. Each point displayed, using the rollup, represents a designated time
interval before the specified plot time. A rollup value of 1 hour will present data at a granularity
level of every one hour, while a rollup value of 15 minutes will show data for every 15 minutes
of logged data. Rollup options are:
– Average
This option plots the average value for the selected rollup period.

NiagaraAX-3.x
6-6
User Guide
Chapter 6 – About Histories Types of history space views
May 1, 2007 About the chart builder view

– Min
This option plots the minimum value for the selected rollup period.
– Max
This option plots the maximum value for the selected rollup period.
– Sum
This option plots the total of the values in the selected rollup period.
• Histories pane
This is the lower left area of the Chart Builder view. It displays all histories that are available in your
local station or any station histories that you import by means of the Niagara network or other net-
work driver (for example, BacnetNetwork). Histories are grouped under the station by station name.
Double-click (Wb Web profile) or click (Hx Web profile) on a history name to copy it to the Current
Charts pane.
Note: The histories that are displayed in this pane are the same histories that are displayed under
the history space node in the Workbench nav sidebar.
• Current Charts pane
This pane displays the histories that are selected to be plotted. For each history, you may select the
type of chart to generate, using the chart type option list, as displayed in Figure 6-13.
Note: NiagaraAX-3.2 has more chart type options than earlier versions.
Adjacent to the histories in this pane are icon-type controls that allow you to reorder histories in the
pane or remove histories from the pane.

Figure 6-13 Current chart pane options and controls

• Control buttons
The following control buttons are located at the bottom of the Chart Builder view:
• Build button
Click this button to build the chart using the histories that are in the selected Current Histories
pane.
• Clear button
Click this button to remove all histories from the Current Histories pane.
Figure 6-14 shows an example of chart that displays two histories.

Figure 6-14 Two different history line charts using chart builder view (Wb and Hx Web profiles)

NiagaraAX-3.x
6-7
User Guide
Types of history space views Chapter 6 – About Histories
About the database maintenance view May 1, 2007

Figure 6-15 History pie chart and area chart using chart builder view

About Time Zones and the Chart Builder view


When charting multiple histories that include different timezones, the Chart Builder uses a “zoneless”
time range configuration so that it can plot each history with reference to its own timezone. This means
that the resulting charts are aligned by local time. For example, if you select a time range of 8:00 AM
through 5:00 PM for two histories—one in EST and another in CST—then the values at 8:00 AM align so
that the 8:00 AM values may be visually compared.

About the database maintenance view


The database maintenance view is shown in Figure 6-16. Using this view, you can clear records and delete
complete histories from your history database. Select the database maintenance view by selecting the
history space node in the nav sidebar and using the view selector menu or the popup menu to choose the
database maintenance menu item.

Figure 6-16 Database maintenance view

The left side of the histories area contains the available histories window. This window
displays all histories that are available in your local station or any station histories that you import by
means of the Niagara network or other network driver (for example, BacnetNetwork). Histories are
grouped under the station by station name.
Note: The available histories are the same histories that are displayed under the history space node in the nav
sidebar.
The right side of the histories area contains the targeted histories window. This window displays the
histories that are affected when you click the Run Maintenance button. Move the histories that you
want manage into this window using the control buttons, as described below:
Controls and options for the database maintenance view are described in the following list:
• Add history button (right arrow)
Click this button to move histories that are selected in the available histories window to
the targeted histories window.
• Remove history button (left arrow)
Click this button to move histories that are selected in the targeted histories window to the
available histories window.

NiagaraAX-3.x
6-8
User Guide
Chapter 6 – About Histories Types of history views
May 1, 2007 About the nav container view

• Clear Old Records option


Select this option and use the Before date selector to remove records, based on date, from the his-
tories that are in the targeted histories window.
• Before date field
Use this field with the Clear old records option to set the year, month, day, and time param-
eters that you want to use for removing old records.
• Clear all records
Select this option to delete all records from the selected history database.
• Delete Histories
Select this option to delete all histories that are in the targeted histories window.
• Run Maintenance button
Click this button to execute the option that you have selected on the histories in the targeted histo-
ries window.

About the nav container view


The nav container view is shown in Figure 6-17. This view displays a row for each station that is repre-
sented in the history space. You can double-click on any of the station icons to display the individual
histories that are children to the station that is represented in the Name column of the nav container
view. Double click on a history in this view to display the history in the History Chart view.

Figure 6-17 Nav container view

In this view you can select any history and switch to any other view of that history (see “Types of history
views” on page 6-9) using the view selector or the popup menu. In this view you can also rename histories,
using the popup menu.

Types of history views


You can view histories in different ways in Workbench. Figure 6-18 shows a menu of views that are
available using either the Workbench view selector or a view popup menu. These views are listed and
described in the following sections.

Figure 6-18 History views available from popup menu

• History Chart
This view shows a plotted chart of the history data. This is the default history view. Refer to “About
the history chart view” on page 6-10 for more details.
• History Table
This table shows a view of history data that you can export and view in the following formats: PDF,
CSV, Text. In addition, you can modify the tabular view of history data by choosing to show or hide
columns and by filtering the data based on date and time. Use the Table Options menu in the
top right corner of the history table to modify the history table view or to export the data in the view,

NiagaraAX-3.x
6-9
User Guide
Types of history views Chapter 6 – About Histories
Types of history data fields May 1, 2007

as desired.
• Collection Table
This view shows a table of any data (in this case history data) that you can export and view in the
following formats: PDF, CSV, Text. Use the Table Options menu in the top right corner of the
collection table to modify the table view or to export the data in the view, as desired.
• History Summary
This view shows a summary of the history’s status and configuration properties.
• History Editor
This view allows you to actually edit data and filter histories.

Types of history data fields


The following types of data are common to several history table views and appear as columns that may
be hidden or displayed using the Table Options menu. Refer to “Table controls and options” on page
2-17 for information about using the Table Options menu.
• Timestamp
This data field indicates the time that the recorded value occurred.
• Trend Flags
This data field displays trend flag information about the recorded data - for trend record types.
These flags provide extra context information about the record data. For example: “Start”,
“OutofOrder”, “Hidden”, “Modified”, and “Interpolated” are possible trend flags.
• Status
This data field displays the status of the history’s parent component; for example, “OK” or “null”.
• Value
This data field displays the record value.

About the history chart view


The history chart view plots the data of the selected history log along x and y axes. This is the default view
of the history, so if you double-click on a history in the nav sidebar, the history chart view will appear. An
example of the history chart view is shown in Figure 6-19.

Figure 6-19 History chart view

The history chart view contains the standard chart controls and options to help you customize and view
the data. Refer to “Chart controls and options” on page 2-18.

About the history table view


The history table view displays history records with columns of data that you can customize by displaying
or hiding selected columns. An example of the history table view is shown in Figure 6-20. Refer to “Table
controls and options” on page 2-17 for details about table controls and options that are common to many
table views.

NiagaraAX-3.x
6-10
User Guide
Chapter 6 – About Histories Types of history views
May 1, 2007 About the collection table view

Figure 6-20 History table view

In addition to a title bar that displays the history name and number of records in the table, the history
table has the following four columns that are described in “Types of history data fields” on page 6-10.
• Timestamp
• Trend Flags
• Status
• Value
Use the Table Options menu in the top right corner of the history table to modify the table view or
to export the data in the view, as desired. Refer to “Table controls and options” on page 2-17 for a
description of the Table Options menu.

About the collection table view


The collection table view displays records with columns of data that you can customize by displaying or
hiding selected columns. Refer to “Table controls and options” on page 2-17 for details about table
controls and options that are common to many table views.
An example of the collection table view is shown in Figure 6-21.

Figure 6-21 Collection table view

In addition to a title bar that displays the history name and number of records in the table, the history
table has the following four columns that are described in “Types of history data fields” on page 6-10.
• Timestamp
• Trend Flags
• Status
• Value
Use the Table Options menu in the top right corner of the history table to modify the table view or
to export the data in the view, as desired. Refer to “Table controls and options” on page 2-17 for a
description of the Table Options menu.

About the history summary view


The history summary view is shown in Figure 6-22. This view displays the details of the history’s status
and configuration properties in two groups, as follows:

NiagaraAX-3.x
6-11
User Guide
Types of history views Chapter 6 – About Histories
About the history editor view May 1, 2007

Figure 6-22 History summary view

• Status parameters
these parameters display data that is updated as of the time you select the history summary view.
• Record count
this is the current number of total records, as of the Last Timestamp.
• First Timestamp
this is the date, time and timezone information for the initial history record.
• Last Timestamp
this is the date, time and timezone information for the latest recorded history record.
• Configuration parameters
these parameters display data that identifies and characterizes the specific history. Refer to “Config-
ure history extensions” on page 6-16 (see the History Config bullet item) for a description of the con-
figuration parameters.

About the history editor view


An example of the history editor view is shown in Figure 6-23. The history editor view allows you to edit
data and filter histories. This view also allows batch editing (selecting multiple rows and using the popup
menu or the Edit menu).

Figure 6-23 History editor view

The history editor view is comprised of the following main areas:


• Title bar
this area displays the history name and number of records in the history.
• Toolbar icons
these icons are available on the toolbar when the history editor view is displayed. Refer to “About the
history editor toolbar icons” on page A-15 for descriptions of these toolbar icons.
• Time range options
this menu is located in the top left corner of the history editor view. You can select one of the pre-
defined times or select the Time Range option that allows you to set a specific time range using
the Edit Time Range dialog box.
• Table options menu
Use the Table Options menu in the top right corner of the history editor view to change which
columns are displayed or to export the data in the view, as desired. The history table op-

NiagaraAX-3.x
6-12
User Guide
Chapter 6 – About Histories About the history process
May 1, 2007 About the history editor view

tions menu includes the following items:


• Table columns
In addition to a title bar that displays the history name and number of records in the table, the history
table has the following four columns that are described in “Types of history data fields” on page 6-10.
• Timestamp
• Trend Flags
• Status
• Value
Use the Table Options menu in the top right corner of the history table to modify the table view
or to export the data in the view, as desired. Refer to “Table controls and options” on page 2-17 for
a description of the Table Options menu.
• Control buttons
The following two control buttons are used to initiate record editing in the history editor view:
• Edit
this button is available when one or more records are selected in the history editor table. When
you click this button, the Edit Records dialog box appears.
• Select Outliers
this button is available when the outlier configuration parameters are active (when the option
box is selected in the Configure Outliers dialog box). When you click this button, the
Configure Outliers dialog box appears.
Use the Table Options menu in the top right corner of the history table to modify the table view or
to export the data in the view, as desired. Refer to “Table controls and options” on page 2-17 for infor-
mation about using the Table Options menu.

About the history process


There are essentially three steps in the “history logging” life cycle, as shown in Figure 6-24:

Figure 6-24 Simplified history process

• collect
involves defining the parameters that specify what data will be recorded and when (or how often) it
will be recorded. For example, you can collect data whenever a change of value occurs - or at a reg-
ular time interval that you specify.
To collect history information you need to:
• Add history extensions to a component (refer to “Add history extensions to a component”)
• Configure the extensions (refer to “Configure history extensions” on page 6-16)
• Use a valid history name (part of configuration, see, “About history names” on page 6-17)
Refer to “Add history extensions to a component” on page 6-15 for more details.
• store
involves defining the parameters of the history database file. For example, you can customize the
name of the database file, define the maximum number of records to save, and choose metadata to
add to the records. Refer to “Configure history extensions” on page 6-16 for more details.
• archive (transfer)
includes importing and exporting records from one station to another station. For example, you can
limit your local station records to a small number that you specify and archive all records to another
station. Refer to “Archiving” on page 6-18 for more details.
You can add extensions to a component’s property sheet in order to extend the functionality of the
component. By adding a history extension, the real-time value or status of the component’s output can
be collected as a time-stamped entry in the associated history table. History extensions are available in
the history palette, as shown in Figure 6-25. The history table is not stored as part of the component’s
data but is a separate collection of data simply referred to as the history.

NiagaraAX-3.x
6-13
User Guide
About the history process Chapter 6 – About Histories
About delta logging May 1, 2007

Figure 6-25 History extensions

About delta logging


When you are logging data, such as electric consumption (kWh) or other information that uses a running
total, you may want to know the difference between consecutive timestamped values instead of the actual
running total. The delta logging feature is provided for this type of calculation. For delta logging, data is
logged (as normal) using the appropriate NumericChangeOfValue or NumericInterval extension. Then,
in the history chart or history table view, you simply select the Delta option box (or use the toolbar icon)
to display the delta values instead of the running total value, as shown in Figure 6-27. Delta values are
computed by taking the difference between one numeric record and the next. The timestamp of the last
record (of the two) is used as the timestamp for the delta value.

Figure 6-26 Delta logging history values

Two other parameters that apply to delta logging are related to the concept of rollover.
Rollover occurs when a running total reaches a defined maximum number and then resets to “zero” or
another defined number. The defined maximum number is represented in the history extensions by the
Max Rollover Value parameter. The reset value (which is often zero) is represented in the history exten-
sions by the Min Rollover Value parameter. These parameters allow you to specify the behavior of the
delta logging when the rollover occurs. If you do not know these values or if they are not specified, then
select the null option for these parameters.

NiagaraAX-3.x
6-14
User Guide
Chapter 6 – About Histories About the history process
May 1, 2007 Add history extensions to a component

Figure 6-27 Using rollover value parameters with delta logging

Consider the following example. If you are logging energy consumption with the Max Rollover Value
parameter set to 999,999 and the Min Rollover Value set to 100, then when a rollover is detected, the delta
logging bases its delta calculations on a maximum value of 999,999 and a subsequent initial value of 100.
Refer to “Configure history extensions” on page 6-16 for a list and short description of all the history
extension parameters.

Add history extensions to a component


Extensions come in different types to match the data type of the component and the collection method
desired. You can add history extensions by dragging them onto your property sheet or into your nav side
bar pane from the history palette (see Figure 6-29). Refer to “To add an extension to a component
property sheet view:” on page 12-16 for steps for adding an extension.

Figure 6-28 History extensions in Workbench the history palette

Figure 6-29 History extensions in the property sheet

Extension types include:


• BooleanChangeOfValue
used to collect boolean values whenever those values change.
• BooleanInterval
used to collect boolean values at specified time intervals.
• NumericChangeOfValue
used to collect numeric values whenever those values change.

NiagaraAX-3.x
6-15
User Guide
About the history process Chapter 6 – About Histories
Configure history extensions May 1, 2007

• NumericInterval
used to collect numeric values at specified time intervals.
• EnumChangeOfValue
used to collect integer values (enumerations) whenever those values change.
• EnumInterval
used to collect integer values (enumerations) at specified time intervals.
• StringChangeOfValue
used to collect a string of characters whenever the characters change.
• StringInterval
used to collect a string of characters at specified time intervals.
For more details about extension types, refer to “Types of history extensions” on page 3-14.

Configure history extensions


When a history extension is first added to a component, it is set to be disabled by default. All that is really
necessary to enable collection is to change the 'Enable' property to 'true.' Of course, you may desire some
other property changes to better configure the collection to suit your actual needs.
Some configuration properties are common among all history extension types. A few properties are
unique to the data type or the collection type. Following, is a list of all the properties available.
• Status
read-only field that tells the user the current status.
• Fault Cause
read-only field that displays a reason that the extension is not working.
• Enabled
set either 'true' or 'false' to disable or enable the history extension.
• Active Period
specifies the days of the week as well as start and end times for record collection.
• Active
read - only value that indicates whether or not (true or false) the history collection is active (as de-
fined by the Active Period parameters.
• History Name
is a formatting convention used to provide a way to consistently name histories using a standardized
formatting pattern.
The history name format field provides a way to automatically name histories any time a new history
is created. The format %parent.name% is the default history name format and this will create a
name based on the parent object. Refer to “About history names” on page 6-17 for more details about
naming histories.
• History Config
These properties set up the attributes of the History record.
• Id
a unique identification for each history. The id value is the name that was automatically created
by the History Name Format or manually created in the name field or rename dialog box.

Figure 6-30 History Id

• Source
a read-only field that displays the ORD of the active history extension.
• Time Zone
a read-only field that displays the time zone of the active history extension.
• Record Type
displays the data that the record holds in terms of: extension type (history) and data type:(Bool-
eanTrendRecord, NumericTrendRecord, and so on).
• Capacity
allows you to set a finite number of records to collect or to choose to collect an unlimited num-
ber of records. If you choose the Record Count option, an additional “records” field displays.
In the “records” field, type in the maximum number of records that you want to save in the his-
tory database.
• Full Policy - (Roll or Stop)
allows you to choose what to do when the Capacity number is reached. The Roll option drops
off the oldest record to make room for the newest record. The Stop option simply causes the

NiagaraAX-3.x
6-16
User Guide
Chapter 6 – About Histories About the history process
May 1, 2007 About history names

history to stop recording.


• Interval
a read-only field that displays the selected collection type: regular on interval.
• valueFacets
allows you to use the Edit Facets dialog box to choose how you want to display the logged data.
• Change Tolerance
for COV based collections, the monitored variable has to change at least this much to be logged as a
changed value.
• Interval
for Interval-based collection, the cycle time, or how often the history parameters are checked. Any
time you change this parameter, a new history is created (or “split-off”) from the original history be-
cause histories with different intervals are not compatible.
• minRolloverValue
this is a number that is used as the starting point for calculations for cumulative logging after a roll-
over. Rollover occurs after a running total maximum value is reached. Select the null option if a
minRolloveValue is unknown. Refer to “About delta logging” on page 6-14 for more details about
rollover and delta logging.
• maxRolloverValue
this is a number that is used as a maximum value for calculations when a rollover is detected by the
history logging process. Using this parameter and the minRolloverValue parameter helps you avoid
getting negative numbers when you are logging running total data, such as energy usage. Refer to
“About delta logging” on page 6-14 for more details about rollover and delta logging.
• precision
this option allows you to select 32 bit or 64 bit options for the history data logging. 64 bit allows for
higher level of precision but consumes more memory.

About history names


By default, when a history extension is added to a component, a history format default string is set to the
following: “%parent.name%”. This string automatically names any histories with the name of the parent
component and appends a sequential number to additional names, as necessary. For example, a history
extension on a NumericWritable component will, by default, create a history name “NumericWritable” -
then if that component is duplicated, the name for the history will be duplicated and incremented to
“NumericWritable1”. You may add a literal name in front of, or after, the “%parent.name%” string, as
shown in Figure 6-31, to customize it without losing the automatic naming feature.
Note: If you use a literal name and not a script to name a history, you lose the automatic incrementing feature
that the script provides. Duplicating extensions that have a literal name duplicates the exact literal name
and therefore creates an invalid (non-unique) name. In this case, you must rename each duplicated history
manually to create a unique name and avoid a fault condition.

Figure 6-31 History naming relationships

As described in “Configure history extensions” on page 6-16, and illustrated in Figure 6-30, history names
are part of the unique history extension property “Id”. When you rename a history at the history
extension, you are renaming the history at its “source”. Therefore, the history configuration and the
history Id both change. This concept is illustrated in Figure 6-32.

NiagaraAX-3.x
6-17
User Guide
About the history process Chapter 6 – About Histories
Archiving May 1, 2007

Figure 6-32 Renaming a history in the history extension

If, however, you rename a history in a “history space” view, such as under the history space node in the
nav sidebar, or in the nav container view, you are changing the name of the history as it has been saved in
the history space–not at the configuration (or origination) level. Therefore, the history Id is not changed
and the history extension continues to produce records under the original history name as long as that
history extension is active and enabled. This results in a history “split”; the newly-named history is no
longer updated, as of the time of the renaming, but it contains all the records up to that time. In this
scenario, a history under the original name begins with the first record after the renaming and continues
recording as configured. This concept is illustrated in Figure 6-33.

Figure 6-33 Renaming a history in the history space

Renaming Summary:
• No history split
If you rename a history in either the property sheet view or the history extension manager view, you
are editing the actual history extension and therefore not forcing a history split.
• History split
If you rename a history in either the nav side bar view or the nav container view you are editing the
name in the history space and not actually changing the history ID – the history is split.

Archiving
Archiving is the process of saving a history out to a different location (station) from where it was origi-
nated. There are two general methods (or directions) for archiving, as described below:
• Pushing data (exporting histories)
is the process of exporting history data and is done using the history export manager, shown in
Figure 6-34. For details about exporting histories, refer to “History Export Manager” on page 4-41.

Figure 6-34 Niagara history export manager

NiagaraAX-3.x
6-18
User Guide
Chapter 6 – About Histories About editing history data
May 1, 2007 Archiving

• Pulling data (importing histories)


is the process of importing history data and is done using the history import manager, shown in
Figure 6-35. For details about importing histories, refer to “History Import Manager” on page 4-37.

Figure 6-35 Niagara history import manager

About editing history data


The history editor view, as described in “About the history editor view” on page 6-12, provides the ability
to review and modify the history data that you have collected.
In some cases, you may want to search through the history data and look for unusual data or “outliers.”
An “outlier” is a data value that is far apart from the rest of the data; an extreme value that is either much
lower or much higher than the rest of the values in the data set. Outliers are known to skew means or
averages, so it may be helpful to identify and edit or hide this data. This doesn’t mean that the data point
is necessarily bad – but in most cases the information is more helpful without the inclusion of this
“unusual” data.

Caution It is possible to alter good data and miss filtering some bad data points using the history editor view.

Workbench provides the ability to find and edit outliers based on parameters that you specify. The
Configure Outliers dialog box, shown in Figure 6-36, appears when you click the Configure
Outliers icon in the toolbar menu. Refer to “About the history editor toolbar icons” on page A-15 for
a list of toolbar icons specific to the history editor view.

Figure 6-36 Configure Outliers dialog box

• Configure Outliers check box


Outlier filtering is disabled by default. Select the check box to enable the outlier filtering feature and
use the parameters that are displayed in the dialog box. Clear the check box to disable outlier data
filtering. When outlier parameters are enabled, the Window and the Percent of Std Devia-
tion fields are available and allow you to specify the “intensity” of the search for outliers in the data.
• Window
Enter an integer in the Window field to define the number of surrounding data points to consider
when determining whether a given point is an outlier. For example, if you use the default value of
“4”, it will look at the two points before and after the point under investigation (PUI). This is a sur-
rounding “window” of 4 points–from which a standard deviation will be calculated and used with
the percentage parameter, as described, below.
• Percentage
Enter a value in this field to specify the percent of standard deviation (calculated from the window
of points) to apply for identifying whether or not the PUI should be considered a valid value (not an
outlier). If the PUI falls outside of this valid range, then it is considered to be an outlier and its value

NiagaraAX-3.x
6-19
User Guide
About editing history data Chapter 6 – About Histories
Archiving May 1, 2007

is replaced by the linear interpolation of the surrounding 2 valid points. If the PUI falls within the
range, then the data point is used and considered valid.

NiagaraAX-3.x
6-20
User Guide
CHAPTER 7
About alarms
Figure 7-1 Typical alarm table display

Alarms notify personnel that a predefined set of parameters has been met. Typically, these are
“offNormal” or “Fault” parameters that are configured to notify specified recipients about the specified
condition and to record the conditions that exist when the monitored point meets these parameters. The
“normal” parameters for an individual point are properties that may be set and edited, as desired, by a
user with proper access and privileges.
• Alarm
An alarm is used to indicate that some value is not within an appropriate or expected range. For ex-
ample, the normal operating temperature range of a device may be 70 to 100 degrees F. You can set
the “out of range” parameters to generate an “alarm” if the operating temperature exceeds the upper
limit or goes below the lower limit of this range.
• Alert
This is an alarm that does not have a “normal” state. For example, a motor may require lubrication
after every 400 hours of operation (this is not an “out of range” condition). Using the alarming func-
tion in Workbench, you can configure an extension to send an email alert to you when the 400 hours
runtime has accumulated on the motor.
Alarm examples
The following are examples of possible ways that alarms are used:
• Out of operating range notification (offNormal)
An alarm is most commonly used to indicate that some value is not within an appropriate or expect-
ed range. For example, the normal operating temperature range of a device may be 70 to 100 degrees
F. You can set the “out of range” parameters to generate an “alarm” if the operating temperature ex-
ceeds the upper limit or goes below the lower limit of this range.
• Advisory notification (alert)
You may use an alarm in situations to report on a parameter that does not really have a “normal”
state. For example, a motor may require lubrication after every 400 hours of operation (this is not an
“out of range” condition). Using the alert function, a system integrator can setup an control point
that monitors accumulated device run-time and sends an email alert notification at or before the 400
hours run-time has occurred.
• Device fault notifications (fault)
Some devices may report values that are so far out of range that it is obvious that there is a device or
system “fault” that needs attention. For example, if a device with a normal operating temperature of
between 70 to 100 degrees reports a temperature of 0 degrees F or 1000 degrees F, then it is probable
that there is a device or system fault and that the reported temperature is not the actual temperature
at the device. The system engineer or supervisor can set parameters and enable alarms for a separate
notification for values that are judged to be “faults” as opposed to simply “out of range”.

NiagaraAX-3.x
7–1
User Guide
Overview of the alarming process Chapter 7 – About alarms
May 1, 2007

Overview of the alarming process


Each alarm is a single record in the alarm database that changes throughout its life cycle. An alarm has
four general “life cycle” states that it may be in:

new alarm
is the initial state of an alarm and this state remains in effect until that alarm is acknowledged.
• acknowledged alarm
is an alarm that has been acknowledged by the recipient. Acknowledged alarms may be normal
alarms.
• normal alarm
is an alarm that has a current status of “normal”.
• acknowledged normal alarm
is a normal alarm that has been acknowledged.
Note: An “Open Alarm” is an alarm that is in normal status and is not acknowledged (or acknowledged and in
alert status).
Typically, an alarm provides some visual and audible indication that a limit or value is met or exceeded.
Alarm notifications may be routed and displayed in a variety of ways, including the following:
NiagaraAX alarming is comprised of three primary actions:
• Creating alarms (refer to “About alarm sources” on page 7-3)
• Routing alarms (refer to “About the alarm service” on page 7-6)
• Managing alarms (refer to “About the alarm database maintenance view” on page 7-13

Figure 7-2 Simplified alarm process

Under these three processes NiagaraAX provides highly specific and flexible alarming life cycle
management, including the following alarming functions:
• creating alarms
Alarms are generated by components using an alarm extension (refer to “About alarm extensions
and components” on page 7-3). The alarm extensions create the alarm whenever specified values are
outside of “normal” range. Those alarms are then handled by the alarm service (refer to “About the
alarm service” on page 7-6).
• routing alarms
Alarms are handled by the alarm service which, in addition to allowing you to specify routing des-
tinations (including archiving destinations), provides notification and acknowledgement parame-
ters.
• notification
Alarms are routed to one or more recipients based on their alarm class. This includes notifica-
tion by email, at the alarm console, a lineprinter, or at remote stations.
• acknowledgment
Alarms may require a response from those who are notified. If a required acknowledgement is
not received within an optionally-specified time, alarms can be “escalated” and re-routed to
other designated alarm recipients.
• managing alarms
alarms are archived in records that are managed by the alarm database management interface.
The following list outlines the basic steps in the alarming process:
• add alarm extensions to components
Choose alarm extensions to match the component data type.
• configure alarm extensions
Configure the alarm parameters to define when a component is in an alarmed state.
• route alarms
Configure the alarm parameters to define where an alarm record is sent.
• manage the alarm archive
Use the alarm archive management tools to manage the storage of all alarms.

NiagaraAX-3.x
7-2
User Guide
Chapter 7 – About alarms About alarm sources
May 1, 2007 About alarm extensions and components

About alarm sources


The parameters that are set in a point’s “alarm point extension” determine when that point is in an
“alarmable” condition. You use the alarm extension to configure routing options, issue alarms to the
alarm service, and update the alarm to reflect a status change when the parent point goes back to a normal
state. The extension also notifies the point that an acknowledgement has been received. To set up the
alarm source on an object you need to:
• add a proper alarm extension to the component (see About alarm extensions and components)
• configure the alarm extension to meet your needs (see About alarm extensions)

About alarm extensions and components


To set up alarming on a component you need to add an alarm extension to the component’s property
sheet. Refer to “About alarm extensions” on page 3-12 for more details about the alarm extensions. Alarm
extension types must match their parent component type. For example, an OutOfRangeAlarmExt goes
with a Numeric point type and a BooleanChangeOfStateAlarmExt goes with a Boolean point type. For a
list of alarm extensions types and their associated point types, refer to “Types of alarm extensions” on
page 3-12.
Alarm extensions are contained in the alarm Palette, as shown in Figure 7-3.

Figure 7-3 Alarm extensions in alarm palette

For details on adding extensions to a property sheet, see “To add an extension to a component property
sheet view:” on page 12-16. Once the extension is added, configure the extension to meet your alarming
requirements. Refer to “About alarm extension properties” on page 7-3 for more details.

About alarm extension properties


Each alarm extension has a set of configurable properties that allow you to specify the alarming condi-
tions and certain routing options. Figure 7-4 illustrates and the following list describes each alarm
extension as it appears in a component property sheet.

NiagaraAX-3.x
7-3
User Guide
About alarm sources Chapter 7 – About alarms
About alarm extension properties May 1, 2007

Figure 7-4 Alarm extension properties

Following, are the alarm extension properties descriptions:


• Alarm Inhibit
A true value in this field prevents alarm generation due to any transition or state change.
For example, if there is a true value in this field and an Offnormal value is reached, a “toOffNormal”
status will not be communicated. When the state returns to Normal, a “toNormal” status will also
not be communicated. A false value in this field will prevent alarms from being inhibited (even if
an Inhibit Time is set).
Note: The purpose of the Alarm Inhibit property is to prevent unintended alarms, such as in after-
hours situations where a piece of equipment is turned off. A difference between Alarm Inhibit and
Alarm Delay is that the Alarm Inhibit is a boolean value (true/false) and may be controlled by
another device (for example, an ON/OFF value of a fan).
If the Alarm Inhibit value is set to true, the Inhibit Time property qualifies the behavior.
• Inhibit Time
The value of this property affects the length of time that the current Alarm Inhibit state will remain
in effect after an Alarm Inhibit state change. For example, when an Alarm Inhibit value changes from
true to false, alarm generation continues to be inhibited for a time that is specified by the Inhibit
Time property value. When an Alarm Inhibit value changes from false to true, alarm generation
may continue to be inhibited for a time that is dependent on the point type, as shown in Table 7-1.

Table 7-1 Time until Alarm Inhibit state change affects alarm generation
Alarm Inhibit tran- Point type
sition Discrete point Numeric point
True to False Inhibit Time property value Inhibit Time property value
False to True 3 x Inhibit Time property value 0 (zero)
• Alarm State
This field displays the current alarm state of the component: Normal, Low Limit, High Limit, Fault.
• Time Delay

NiagaraAX-3.x
7-4
User Guide
Chapter 7 – About alarms About alarm sources
May 1, 2007 About alarm extension properties

Note: Time Delay does not affect alarms generated by a Fault. There is no delay when transitioning
in or out of a Fault generated alarm.
This is the minimum time period that an alarm condition must exist before the object alarms. In oth-
er words, the object status must meet the “alarm” criteria for a continuous period equal to or greater
than defined in the Time Delay property value before an alarm is generated. The general purpose of
the Time Delay property is to provide a means to prevent nuisance alarms that may be caused by a
momentary change in a state value (Normal, Low Limit, High Limit).
Time Delay applies to properties that transition both in and out of alarm states. Therefore, an alarm
status may continue to display as Offnormal (for example) for a time (equal to the Time Delay) after
the value has come back into Normal parameters. The Time Delay is the minimum time period that
a normal condition must exist before the object comes out of alarm.
Note: Typically, when both Alarm Delay and Alarm Inhibit properties are used, Time Delay is less
(shorter) than Alarm Inhibit.
• Alarm Enable
Select any of the options to individually enable the generation of alarms when the following transi-
tions occur:
• toOffnormal
This is the time that the offNormal event occurred.
• toFault
This is the time that the Fault event occurred
Note: No alarms will be generated unless an Alarm Enable option is selected.
• To Offnormal Times
This property displays four pieces of information that are related to the time that the component sta-
tus changed to Offnormal. A “null” value means that the event has not occurred. See Figure 7-5.
• Alarm Time
This property displays the time that the To Offnormal event occurred.
• Ack Time
This property displays the time that the alarm was acknowledged.
• Normal Time
This property displays the time that the To Normal event occurred.
• Count
This field displays the total number of Offnormal events.

Figure 7-5 To Offnormal times

• To Fault Times
This property displays four pieces of information that are related to the time that the component sta-
tus changed to a Fault state. A “null” value means that the event has not occurred. See Figure 7-6.
• Alarm Time
This property displays the time that the To Fault event occurred.
• Ack Time
This property displays the time that the alarm was acknowledged.
• Normal Time
This property displays the time that the To Normal event occurred.
• Count
This field displays the total number of To Fault events.

Figure 7-6 To Fault times

• To Normal Times
This property displays the time that the component transitioned to a normal state.

NiagaraAX-3.x
7-5
User Guide
About the alarm service Chapter 7 – About alarms
About alarm instructions May 1, 2007

• Time in Current State


This property displays the elapsed time since the component transitioned to the current state.
• Source Name
This property displays the name of the alarm source. If you use the default script setting %parent.dis-
playName%, the source name field will show the “display name” of the alarm extension parent. You
can edit this script or type in a literal string to display.
• To Fault Text
This property enter the text that you would like to display when the component is in a fault state.
• To Offnormal Text
This property enter the text that you would like to display when the component is in a Offnormal
state.
• To Normal Text
This property enter the text that you would like to display when the component is in a Normal state.
• Hyperlink Ord
Use this property enter or choose an Ord, a BQL Query or a path to a component that you would
like to associate with an alarm status on the component you are configuring. When an alarm is re-
ported in the console, the Hyperlink button is active and uses this path. Use the folder icon to browse
to the file that you want to link to. Click the arrow icon to the right of the folder icon to test the Ord
that you enter.
• Sound File
This property enter or choose the path to a sound file that will execute when the current component
is in an alarm state. Use the folder icon to browse to the file that you want to use. Click the arrow
icon to the right of the folder icon to test the path that you enter.
• Alarm Icon
Use this property to enter or choose the path to a graphic file that will added to the display in the
“timestamp” column of the alarm table in the Console Recipient view. Use the folder icon to browse
to the file that you want to use. Click the arrow icon to the right of the folder icon to test the path
that you enter.
• Fault Algorithm
This property when available, displays fault parameters. Different options are available here, de-
pending on the alarm extension being used.
• Offnormal Algorithm
Use this property to enter high and low limit parameters for numeric components and select the
alarm value (on or off) to designate the alarm state for a boolean component. Different options are
available here, depending on the alarm extension being used.
• Alarm Class
Use this property to select an alarm class from the option list. The alarm class specifies the alarm
routing options for this component. Refer to “About alarm class” on page 7-15 for details about alarm
class.
• Meta Data
Use this property to enter new facets using the meta data property. See “About point facets” on page
3-7 for details about facets.

About alarm instructions


Each alarm can have “instructions” assigned to it so that any time an alarm is generated, the instructions
are presented with the alarm notification to provide information that may be important or helpful to the
user. Instructions are created, assigned, and edited from the Instructions view. Refer to “About the
Instructions Manager view” on page 11 for details about the Instructions view.

About notes
Notes are simple text entries that are associated with a particular alarm. It is possible to add a Note to one
alarm or to multiple alarms. Alarm records that have notes are indicated by a “note” icon”. Refer to “Types
of alarm details view dialog boxes” on page 20 for more information about Notes.

About the alarm service


Note: In addition to the standard file-based alarm service, described in this section, there is a memory alarm
service available. These two services should not run in the same station. Refer to “About memory alarm
service” on page 7-7 for details about the memory alarm service.

NiagaraAX-3.x
7-6
User Guide
Chapter 7 – About alarms About memory alarm service
May 1, 2007 About notes

Each station may contain a single alarm service that coordinates the routing of alarms within the
NiagaraAX framework and maintains the alarm database. The alarm service is available in the alarm
palette, as shown in Figure 7-7.

Figure 7-7 Alarm service in the alarm palette

If you do not have the alarm service in your active station, you can add it by dragging and dropping a copy
from the alarm palette, as shown in Figure 7-8.

Figure 7-8 Adding the alarm service

The alarm service may contain one or more alarm classes (refer to “About alarm class” for more infor-
mation about alarm class). An alarm class may route alarms to one or more alarm recipient types (refer
to “Types of alarm recipients” on page 7-18 for more information about alarm recipient).
The routing process includes getting alarm acknowledgements from the recipients back to the source,
and alarm notifications from the source to the recipients. The default view (wire sheet view) of the alarm
service makes it easy to visualize the relationships between the alarm class and the alarm recipient. These
relationships are created by linking the alarm class to the alarm recipient, as described in “About alarm
class” on page 7-15. In addition to the wire sheet and property sheet views, there are several other views
of the alarm service. See “Types of alarm service views” on page 7-9 for a description of the alarm service
views.

About memory alarm service


Note: MemoryAlarmService is an alarm service that provides an alternative to the standard file-based Alarm-
Service. A station should have only one alarm service. Do not enable both the standard AlarmService and
MemoryAlarmService on the same station.
Each station may contain a single alarm service that coordinates the routing of alarms within the
NiagaraAX framework. The memory alarm service is available in the alarm palette, as shown in Figure 7-
9.

Figure 7-9 Memory alarm service in the alarm palette

NiagaraAX-3.x
7-7
User Guide
Common alarm controls and indicators Chapter 7 – About alarms
About notes May 1, 2007

If you do not have the memory alarm service in your active station, you can add it by dragging and
dropping a copy from the alarm palette, as shown in Figure 7-8.

Figure 7-10 Adding the alarm service

Like the alarm service, the memory alarm service may contain one or more alarm classes. An alarm class
may route alarms to one or more alarm recipient types.
The routing process for the memory alarm service is the same as the standard file-based alarm service
and includes alarm acknowledgements from the recipients back to the source, and alarm notifications
from the source to the recipients. The default view (wire sheet view) of the alarm service makes it easy to
visualize the relationships between the alarm class and the alarm recipient. These relationships are
created by linking the alarm class to the alarm recipient, as described in “About alarm class” on page 7-
15. The memory alarm service has the same views available as the standard alarm service.
The main distinction of MemoryAlarmService is that when you use this service, alarms are not stored
persistently on the station host (typically a JACE) as they are with the standard file-based alarm service.
Choosing MemoryAlarmService might be appropriate for situations where you do not want to keep a
large store of alarms on your host and are looking primarily for immediate alarm notifications. Alarm
records are stored in memory and therefore they are lost in the case of a power failure.

Common alarm controls and indicators


The following alarm controls and indicators are common to several alarm views:
• Alarm control buttons
The following buttons appear in one or more alarm views:

Use the Acknowledge button to acknowledge all selected alarms.

Use the Hyperlink button to change the current view to the hyperlinked target associated
with the selected alarm. If no hyperlink is associated with the alarm, the Hyperlink button is not
available.

Click the Notes button to display the Notes dialog box and add a note to the selected alarm
or alarms.

Click the Silence button to stop the audible notification associated with the selected alarm.

Click the Filter button to display the Filters dialog box for setting the filter parameters.

Click the Close button to cancel the current interface actions without saving changes.
• Alarm icons
Alarm icons appear with color coding and symbolic images:
• A red alarm icon in the table indicates that the current state of the alarm source is not
“offnormal” and “not acknowledged”.
• An orange alarm icon in the table indicates that the current state of the alarm source is
“alert” and is “not acknowledged”.
• A yellow alarm icon in the table indicates that the current state of the alarm source is “not
acknowledged” and “acknowledged”.
• A green alarm icon in the table indicates that the current state of the alarm source is “nor-
mal” and “not acknowledged”.

NiagaraAX-3.x
7-8
User Guide
Chapter 7 – About alarms Types of alarm service views
May 1, 2007 About alarm extension manager

• A white alarm icon in the table indicates that the current stat