Technical Document

NiagaraAX-3.6 Platform Guide

Updated: April 4, 2011

NiagaraAX Platform Guide

Confidentiality Notice
The information contained in this document is confidential information of Tridium, Inc., a Delaware corporation (“Tridium”). Such
information, and the software described herein, is furnished under a license agreement and may be used only in accordance with
that agreement.
The information contained in this document is provided solely for use by Tridium employees, licensees, and system owners; and,
except as permitted under the below copyright notice, is not to be released to, or reproduced for, anyone else.
While every effort has been made to assure the accuracy of this document, Tridium is not responsible for damages of any kind,
including without limitation 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 latest
product specifications can be found by contacting our corporate headquarters, Richmond, Virginia.

Trademark Notice
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, Niaga-
raAX Framework, and Sedona Framework are registered trademarks, and Workbench, WorkPlaceAX, and AXSupervisor, are trade-
marks of Tridium Inc. All other product names and services mentioned in this publication that is known to be trademarks, regis-
tered trademarks, or service marks are the property of their respective owners.

Copyright and Patent Notice

This document may be copied by parties who are authorized to distribute Tridium products in connection with distribution of those
products, subject to the contracts that authorize such distribution. It may not otherwise, 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 Trid-
ium, Inc.
Copyright © 2011 Tridium, Inc.
All rights reserved. The product(s) described herein may be covered by one or more U.S or foreign patents of Tridium.
 CONTENTS

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Document Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Niagara platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1

Platform overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
About a platform connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Platform daemon on PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Provisioning versus platform interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3
Types of platform views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3
About platform differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
QNX-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
Sun Hotspot JVM or IBM J9 JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
Backup Battery (or not) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–5
Platform view differences, QNX-based vs. Windows-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–5
Dialup Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–5
Platform Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–5
Windows-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Dialup Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Platform Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7
Win64-based Supervisor notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7
Linux-based Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
NiagaraAX platform rights on Linux Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Default Linux Supervisor platform administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Linux Supervisor platform views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–9
Linux Supervisor port usage notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–9
Models of platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–9
Application Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Installed applications (stations) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–11
Application selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Application output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–12
Standard output overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Station log levels (spy:/logSetup) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–13
Station LogHistory (LogHistoryService) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14
Application and output controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–14
Start checkboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14
Application control buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–15
Output control buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–15
Output Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16
Ddns Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16
DDNS core configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–17
Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–17
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–17
Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–17
About TZO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–17
Dialup Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–18
Platform dialup configuration sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–18
Modem section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–18
Listener section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19
Captive Network section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–20
About the dialup daemon and service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–21

NiagaraAX-3.6
i
Platform Guide
 April 4, 2011

Dialup daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–21

DialupService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–21
About dialup operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–22
Dialup addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–22
Calling from Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–24
Distribution File Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–24
Operation of the Distribution File Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–25
Dist file selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–25
Distribution file install process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–26
Restoring a backup dist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–26
Downgrading a JACE (Clean Dist) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–28
Upgrading a JACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–29
File Transfer Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–30
GPRS Modem Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–31
GPRS modem configuration sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–32
Modem Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–32
Provider Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–32
SMS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–32
Status and Runtime Data area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–32
GPRS Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–33
GPRS Runtime Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–33
Lexicon Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–33
License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–34
License operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–35
Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–36
Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–36
License Import results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–37
About the licensing server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–37
Platform Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–38
Types of Platform Administration functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–39
View Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–40
Update Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–40
Digest platform authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–41
Basic platform authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–41
Change HTTP Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–43
Change Date/Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–44
Use Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–45
FTP/Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–45
Change Output Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–45
Log filter settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–46
View Daemon Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–46
Set Module Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–47
Operations from a change in module content level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–47
Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–48
Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–49
Reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–49
Software Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–50
Software Manager AX-3.5 changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–51
About your software database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–51
Default module listing and layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–52
Software Manager table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–52
Software Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–53
Filtering displayed software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–54
Filter by status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–54
Filter by name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–54
Software Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–54
Import vs. copy into modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–55
Software actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–55
Upgrade All Out of Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–56
Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–56
Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–56

NiagaraAX-3.6
ii
Platform Guide
April 4, 2011

Re-Install, Upgrade, Downgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–56

Commit and Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–57
Right-click option to install earlier version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–57
Station Copier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–57
Station copy direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–58
Station Copier dependencies check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–58
Station Transfer Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–59
Name step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–59
Delete step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–59
Content step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–60
Disposition step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–60
Station settings step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–60
Details step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–61
Modules step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–62
Stop station step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–63
Review step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–63
Transferring station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–63
Renaming stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–64
Deleting stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–65
TCP/IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–66
TCP/IP changes in AX-3.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–66
IPv6 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–66
JACE WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–67
TCP/IP Host fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–67
TCP/IP DNS fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–68
TCP/IP Interface fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–68
IPv4 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–69
IPv6 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–70
User Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–71
Users management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–71
Review user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–71
Add user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–71
Delete user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–72
Change user password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–72
Drag and drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–72
Groups management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1–72
Review group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–73
Add group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–73
Delete group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–73
Add member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–73
Remove member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–74
WiFi Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–74
WiFi Certificate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–75
Remote File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–75

Platform Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1

About Platform Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
Component differences for platform services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
PlatformServiceContainer parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
PlatformServiceContainer status values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
PlatformServiceContainer configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–4
Additional PlatformServiceContainer properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–5
Model-specific PlatformServiceContainer properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
PlatformServiceContainer actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
SystemService (under PlatformServices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–7
Platform service types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–7
Using platform services in a station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
JACE power monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–9
JACE-NXT (and JACE-NXS) power monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–9

NiagaraAX-3.6
iii
Platform Guide
 April 4, 2011

JACE-NXT hardware monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–9

JACE-NXS hardware monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–10
JACE-NX hardware monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–10
PlatformServices binding and link caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–10
About the NtpPlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–11
Interaction with station’s TimeSyncService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–11
NTP port/firewall considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–12
About the Ntp Platform Service Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–12
About the Ntp Platform Service Editor Win32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–12
About Ntp Platform Service Editor Win32 settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
About Ntp Platform Service Editor Win32 time servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–13
About the Ntp Platform Service Editor Qnx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–14
About Ntp Platform Service Editor Qnx settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
About Ntp Platform Service Editor Qnx time servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
Sync Now action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–15
About the Ntp Platform Service Editor Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2–16
About Ntp Platform Service Editor Linux settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
About Ntp Platform Service Editor Linux time servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–17

Platform Component Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1

Component Reference Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Components in platDataRecovery module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
platDataRecovery-DataRecoveryService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Components in platDialup module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
platDialup-DialupPlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Components in platGprs module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
platGprs-GprsPlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
platGprs-GprsHostSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
platGprs-GprsRuntimeData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Components in platform module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
platform-DaemonFileSpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
platform-DaemonSession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
platform-LicensePlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
platform-NtpPlatformServiceLinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
platform-NtpPlatformServiceQnx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
platform-NtpPlatformServiceWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
platform-Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
platform-PlatformAlarmSupport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
platform-PlatformServiceContainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
platform-SystemPlatformServiceQnxJavelina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–3
platform-SystemPlatformServiceQnxNpm2xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
platform-SystemPlatformServiceQnxNpm6xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
platform-SystemPlatformServiceWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Reboot action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
platform-TcpIpPlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Components in platPower module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
platPower-ExternalSlaBattery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
platPower-JaceSlaBattery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
platPower-JavelinaBatteryPlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
platPower-NimhBattery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
platPower-Npm2NimhBattery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
platPower-NpmDualBatteryPlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
platPower-NpmExternalSlaBattery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
platPower-PowerMonitorPlatformServiceQnx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
Components in platPowerNxs module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
platPowerNxs-PowerMonitorPlatformServiceNxsWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
Components in platSerialQnx module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
platSerialQnx-SerialPortPlatformServiceQnx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
platSerialQnx-SerialPortPlatformServiceQnx403 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6

NiagaraAX-3.6
iv
Platform Guide
Chapter i –
April 4, 2011

platSerialQnx-SerialPortPlatformServiceQnx404 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
platSerialQnx-SerialPortQnx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Components in platSerialWin32 module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
platSerialWin32-SerialPortPlatformServiceWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
platSerialWin32-SerialPortWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Components in platSysmonNx module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
platSysmonNx-HardwareMonitorNxPlatformServiceWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Components in platSysmonNxs module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
platSysmonNxs-HardwareMonitorNxsPlatformServiceWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
Components in platSysmonNxt module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
platSysmonNxt-HardwareMonitorNxtPlatformServiceWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
Components in platUsbmon module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
platUsbmon-UsbMonotorPlatformServiceQnx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
Components in platWifi module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7
platWifi-WifiPlatformService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7

Platform Plugin Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1

Plugin Reference Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Plugins in platDaemon module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
platDaemon-ApplicationDirector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
platDaemon-DaemonLogSettingsView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
platDaemon-DistInstaller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-DistributionView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-FileTransferClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-LexiconInstaller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-LicenseManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-SoftwareManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-SoftwareView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-PlatformAdministration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-PlatformTextSummaryEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-StationCopier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-StationDirector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-StationTextSummaryEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
platDaemon-TcpIpConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platDaemon-UserManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
Plugin in platDataRecovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platDataRecovery-DataRecoveryServiceEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
Plugin in platDDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platDdns-DdnsConfigurationView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
Plugins in platDialup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platDialup-ConfigureDialup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platDialup-DialupEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
Plugins in platform module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platform-ActivityView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platform-LicensePlatformServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3
platform-NtpPlatformServiceEditorLinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platform-NtpPlatformServiceEditorQnx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platform-NtpPlatformServiceEditorWin32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platform-PlatformServiceContainerPlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platform-PlatformServiceProperties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platform-SystemPlatformServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platform-SystemPlatformServiceQnxPlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platform-TcpIpPlatformServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
Plugins in platGprs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platGprs-GprsConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
platGprs-GprsPlatformServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4

NiagaraAX-3.6
i-v
Platform Guide
 Chapter i –
April 4, 2011

Plugins in platWifi module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5

platWifi-WifiConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5
platWifi-WifiPlatformServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5
platWifi-WifiSecurityManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–5

License Tools and Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–1

Workbench License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–2
Import File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–2
Export File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–3
Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–4
Sync Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–4
Request License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–5
About the local license database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–6
Local license database rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–6
Local license inbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–6
About license archive (.lar) files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–7
Licensing server use of license archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–7
About NiagaraAX license files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–7
Items common to all license files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–8
license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–8
about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–8
brand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–8
signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–9
JACE hardware features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–9
maxheap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–9
mstp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–9
ndio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–9
serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–9
Driver attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–9
name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
device.limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
history.limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
point.limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
schedule.limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
Driver types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–10
aaphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
aapup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
bacnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–10
bacnetws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
dust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
fileDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
lonworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
modbusAsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
modbusSlave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
modbusTcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
modbusTcpSlave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
obixDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
opc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
niagaraDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
rdbDb2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
rdbOracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–11
rdbSqlServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–12
snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–12
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–12
station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–12
web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–12
workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–12
crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–12
eas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–12
email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–13
genericAppliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–13

NiagaraAX-3.6
i-vi
Platform Guide
Chapter i –
April 4, 2011

provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–13
tenantBilling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A–13

Time Zones and NiagaraAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B–1

Time zones and terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B–1
UTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B–1
DST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B–1
Selecting a time zone in NiagaraAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B–2
About timezones.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B–2
DST start and end syntax variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B–3
Using Workbench to edit and transfer timezones.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B–3
About the historical time zone database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B–4
Issue example and fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B–4
Parts of the historical time zone database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B–4
Updating a historical time zone database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B–4

Platform Tunneling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–1

Platform tunneling overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–1
Platform tunneling requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–1
Supervisor configuration to support platform tunneling . . . . . . . . . . . . . . . . . . . . . . C–2
WebService settings for platform tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–2
FoxService settings for platform tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–2
Platform tunneling usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–3
Open Platform dialog if tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–3
Connected in Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–4
Notes on platform tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–4

NiagaraAX-3.6
i-vii
Platform Guide
 Chapter i –
April 4, 2011

NiagaraAX-3.6
i-viii
Platform Guide
 CONTENTS

Preface
• Document Change Log

Document Change Log

Updates (changes/additions) to this NiagaraAX Platform Guide document are listed as follows.
• Updated: April 4, 2011
Document updates to cover platform-related changes made in NiagaraAX-3.6 (AX-3.6), such that
this document now applies to both AX-3.5 and AX-3.6 platform functions. Some (but not all) screen
captures were updated. Note that references are still occasionally made to prior NiagaraAX versions.
AX-3.6-related changes to this document are many, but are mainly in the following sections:
• “Platform overview” on page 1-1, in various notes, and in subsection “Types of platform views”.
• “About platform differences” on page 1-4, notably new subsections under the “QNX-based” sec-
tion: “Sun Hotspot JVM or IBM J9 JVM” on page 1-4 and “Backup Battery (or not)” on page 1-
5. Other updates were made in the “Windows-based” section (previously “Win32-based”), in-
cluding its subsection “Win64-based Supervisor notes” on page 1-7. More detail was added in
the section “Models of platforms” on page 1-9, including an entry for the JACE-NXT.
• Section on the “Application Director” on page 1-10 was modified to remove Niagara platform
support of Sedona devices/apps (Sedona device platform support now uses a Sox connection).
• The “GPRS Modem Configuration” view section was reworked to reflect GPRS platform chang-
es made in AX-3.6 and maintenance builds of AX-3.6 and AX-3.4. Only summarized data is in-
cluded—refer to the latest Engineering Notes document GPRS modem option for more
complete details.
• The Platform Administration view section was modified to remove Sedona enable/disable func-
tions, and its subsection “Change Output Settings” on page 1-45 was updated.
• The “TCP/IP Configuration” view section was updated to reflect IPv6 support for some QNX-
based JACEs, starting in AX-3.6. A new section “TCP/IP changes in AX-3.6” summarizes these
changes, with other changes made in sections “TCP/IP Host fields” on page 1-67, “TCP/IP DNS
fields” on page 1-68, and “TCP/IP Interface fields” on page 1-68, with separate “IPv4 Settings”
and “IPv6 Settings” subsections.
• The “Platform Services” section was updated in several spots to mention/describe new possible
platform services for recent JACE hardware options, including the “SRAM option card” (Da-
taRecoveryService) and “WiFi option” for the JACE-700 controller (WifiPlatformService). Note
that separate, specific “Engineering Notes II” documents are also available that describe these
topics in depth. Also in this section, other subsections were updated, including a few minor
changes under “PlatformServiceContainer status values” on page 2-2, “PlatformServiceCon-
tainer configuration parameters” on page 2-4, and “Additional PlatformServiceContainer prop-
erties” on page 2-5. Various sections about the NtpPlatformService were also updated,
including the section “About the Ntp Platform Service Editor Qnx” on page 2-14, with a related
section added; “Sync Now action” on page 2-15.
• Various additions were made in the summary descriptions in the “Platform Component
Guides” and “Platform Plugin Guides” (platform views) sections towards the end of this docu-
ment, for items like the DataRecoveryService and WifiPlatformService.
• Publication: January 29, 2010
Document is a “version-split” from previous Platform Guide revisions, and applies to NiagaraAX-3.5
(AX-3.5) and later platform functions. Many platform-related changes were made in AX-3.5. With
this version split, most notes and references about older revisions of NiagaraAX (AX-3.0 - AX-3.3)

NiagaraAX-3.6
3
Platform Guide
 April 4, 2011

were removed. However, document references to the previous (AX-3.4) changes remain, as well as
few references to older NiagaraAX versions.
AX-3.5-related changes to this document are many, but are concentrated in the following sections:
• “Platform overview” on page 1-1, in various notes in subsections.
• “About platform differences” on page 1-4, notably changes in “Models of platforms” on page 1-9.
• “Distribution File Installer” on page 1-24, covering many differences starting in AX-3.5 Work-
bench. Note a previous subsection about upgrading a JACE was moved “up” one level, as doing
this is no longer possible from the Distribution File Installer. See “Upgrading a JACE” on page
1-29.
• The Platform Administration view section about changing authentication on a Windows host,
noting a new login dialog starting in AX-3.5 when changing from digest to basic authentication.
See “Basic platform authentication” on page 1-41. Other related notes mention changes about
the handling of domain groups for a host on a Windows domain.
• “Software Manager” on page 1-50, with numerous differences starting in AX-3.5 Workbench.
A new subsection summarizes these changes, see “Software Manager AX-3.5 changes” on page
1-51.
• “Station Copier” on page 1-57, reflecting differences when installing a station on a host that
does not already have all modules used by that station. See “Station Copier dependencies check”
on page 1-58.
• “TCP/IP Configuration” on page 1-66, reflecting new separation of “traditional” IP (IPv4) and
IPv6 properties, starting in this AX-3.5 Workbench platform view.
• The “User Manager” view section about group management now notes that AX-3.5 and later
hosts on a domain no longer show “all possible” domain groups. See “Groups management” on
page 1-72. This noted again in a couple of other User Manager subsections.
• A new “Platform Tunneling” appendix was added to cover this new feature starting in AX-3.5.

NiagaraAX-3.6
4
Platform Guide
 CHAPTER 1
Niagara platform
Platform is the name for everything that is installed on a Niagara host that is not part of a Niagara station.
The platform interface provides a way to address all the support tasks that allow you to setup and support
and troubleshoot a Niagara host.
The following main sections provide more platform details:
• Platform overview
• About platform differences
• Application Director
• Ddns Configuration (If a QNX-based JACE)
• Dialup Configuration
• Distribution File Installer
• File Transfer Client
• GPRS Modem Configuration (If a QNX-based JACE)
• Lexicon Installer
• License Manager
• Platform Administration
• Software Manager
• Station Copier
• TCP/IP Configuration
• User Manager (If a Windows-based platform)
• Remote File System

Platform overview
In Workbench, when you open a platform connection to a Niagara host (whether JACE or Supervisor),
that host’s available platform functions are listed in the platform’s Nav Container View, see Figure 1-1.

Figure 1-1 Platform functions listed in platform’s Nav Container View

Note: The former “Sedona Manager” platform view introduced in AX-3.4 is no longer available in AX-3.6, or
in later maintenance builds of AX-3.5 or AX-3.4. That view had limited practical application—Sedona
platform support now requires a Sox connection, for example to Jennic (wireless) platforms like the SEDs
(Sedona Embedded Devices), or to other Ethernet-connected Sedona-based devices.

NiagaraAX-3.6
1–1
Platform Guide
Platform overview Chapter 1 – Niagara platform
About a platform connection April 4, 2011

Each platform function has its own Workbench view (plugin); you access it by simply double-clicking.
Most of the same platform views exist whether a platform connection to a JACE or a Supervisor, with
these exceptions:
• If you open a local platform connection at your computer, note that some platform views are “miss-
ing,” e.g. the Distribution File Installer, File Transfer Client, and Station Copier. The views have no
real application when working at your computer—instead, you simply use Windows Explorer.
• For any Windows-based platform, a “User Manager” view is available. This view is not available if
the platform is a QNX-based JACE or a Linux-based Supervisor.
• For any AX-3.4 or later QNX-based platform, a “GPRS Modem Configuration” view is available.
This view is not available if the platform is a Windows-based JACE or any Supervisor.
• Starting in AX-3.6, a JACE with an installed WiFi option has two related platform views: “WiFi Con-
figuration” and “WiFi Certificate Manager”. Currently, a JACE-700 is the only applicable platform.
Also, a few platform views differ depending on platform type. See “About platform differences” on page
1-4 for details.
The following sections provide additional background:
• About a platform connection
• Provisioning versus platform interface
• Types of platform views
• About platform differences

About a platform connection

A platform connection is different than a station connection. When connected to a Niagara platform,
Workbench communicates (as a client) to that host’s platform daemon (also known as “niagarad” for
Niagara daemon), a server process.
Unlike a station connection that uses the Fox protocol, a client platform connection ordinarily requires
full Workbench, meaning it is unavailable using a standard Web browser (i.e. “Web Workbench” applet).
Note: Browser access of a Supervisor station can provide platform connectivity, albeit indirectly, through its
ProvisioningService. See “Provisioning versus platform interface” on page 1-3.
Also, starting in AX-3.5, Workbench can “tunnel” a platform connection to a JACE through a station
connection to a Supervisor—providing that the Supervisor host is licensed for web tunneling. However, note
that full Workbench is still required. For details, see “Platform Tunneling” on page C-1.
The platform daemon is a compact executable written in native code, meaning the daemon does not
require the Niagara core runtime, or even a Java virtual machine (JVM). The platform daemon is pre-
installed on every JACE controller (even as factory-shipped), and runs whenever the JACE boots up.
Also, a Niagara host’s platform daemon monitors a different TCP/IP port for client connections than
does any running station. By default, this is port 3011. Finally, as a platform client, you sign on using “host
level” credentials for authentication. This means a user account and password separate from any station
user account. Consider it the highest level access to that host.
Note: A station user with admin-level permissions on the “Services” container (in the component Config space)
of a running station also has access to a special subset of platform functions, via “Platform Services.” For
details about this different type of platform access, see “Platform Services” on page 2-1.
Platform daemon on PC
When you install NiagaraAX on your PC, one of the last “Would you like to?” install options is:
Install and Start Platform Daemon
The default selection is to install. You need the platform daemon locally installed and running in order
for any of the following:
• To host a Niagara station on your local PC, such as for a Supervisor. This lets you open a Workbench
client platform connection to your local (“My Host”) platform. It also allows remote client platform
connections to your PC as well.
• To use Workbench to open a remote JACE platform (or station) using a dialup connection, that is,
using your PC’s modem. (The platform daemon is not used to open a LAN-connected platform).
• For a PC to run as an AX SoftJACE, essentially a JACE running on a PC dedicated to this application.
(Note that the AX SoftJACE Install wizard automatically installs and starts the platform daemon.
Also, in this particular case, Workbench is not available to run locally at that PC.)
Once installed and started on a PC, you can see the platform daemon listed as a Niagara service from the
Windows Control Panel, by selecting Administrative Tools > Services.

NiagaraAX-3.6
1-2
Platform Guide
Chapter 1 – Niagara platform Platform overview
April 4, 2011 Provisioning versus platform interface

Note: Following NiagaraAX installation on your PC, you can alternately install and start the platform daemon
at any time, if needed. From the Windows Start menu, do this with Start > All Programs >
Niagara <3.n.n> > Install Platform Daemon (shortcut for “plat.exe installdaemon”).
In summary (except for dial-out support), your Workbench PC’s local platform daemon is not used in
making client connections to other Niagara hosts, only to provide the ability to run a station locally.

Provisioning versus platform interface

The focus in this document is about the NiagaraAX platform user interface, meaning the different
platform views and functions available when you (a Workbench user) open a direct platform connection
to a Niagara host. (Starting in AX-3.5, these same views and functions are available when you open a
“tunneled” platform connection to a host, through an opened Supervisor station.)
However, be aware that a Supervisor station can perform “provisioning”, which can automate some
platform tasks. Provisioning typically applies to its subordinate JACEs, which are represented as Niagar-
aStations (devices) under its NiagaraNetwork.
For more details, please see “Niagara Provisioning overview” in the NiagaraAX Provisioning Guide for
Niagara Networks document.
Note: Some of the provisioning views provided by a Supervisor are nearly identical to platform views described
in this document, including the Software Manager and Application Director (Station Director), and work
in the same fashion. However, if new to NiagaraAX, it is recommended that you become familiar with
“direct” platform views described in this document, before using provisioning in a Supervisor.

Types of platform views

A Workbench direct (or tunneled) platform connection to a Niagara host, either JACE or Supervisor,
provides various functional views, as shown in Figure 1-1.
Note: In addition to the platform views listed below, a Commissioning Wizard is available as a right-click
platform option. This wizard provides a “step-by-step” method to perform a sequence of platform tasks
used for commissioning a new JACE controller, or when upgrading an existing JACE. For more details, see
“About the Commissioning Wizard” in the JACE NiagaraAX Install & Startup Guide.
The following sections summarize the various platform functions and views, including typical usage:
• Application Director
To start, stop, restart, or kill a station on the Niagara platform. Output from the station displays in
the view pane, useful for monitoring and troubleshooting. You also configure a station’s “Auto-Start”
and “Restart on Failure” settings from this view.
• Ddns Configuration
Allows for DNS IP addresses to by dynamically updated (DDNS), an option sometimes used for
JACE hosts, typically in a dialup connection scenario—although infrequently.
• Dialup Configuration
To configure the platform’s dialup modem, including settings for a “captive network.” If a QNX-
based JACE, separate “listening” settings apply for receiving dialup connections.
• Distribution File Installer
Used to restore a “backup” .dist file to the target JACE, or to install a “clean dist” file to downgrade
a JACE to a known bare minimum state.
(Starting in AX-3.5, this view can no longer be used to upgrade a JACE—instead, you must use the
Commissioning Wizard, mentioned in the previous Note:).
• File Transfer Client
To copy files between your Workbench PC and the remote Niagara platform (in either direction).
• GPRS Modem Configuration
(When connected to a QNX-based JACE) To configure the wireless GPRS modem option card (Gen-
eral Packet Radio Service) that may be installed in a JACE-2,-6,-7 series controller.
• Lexicon Installer
To install Niagara lexicon files from your Workbench PC to the remote Niagara platform, to either
provide non-English language support, or customize English lexicons to globally change display tags.
• License Manager
To review, install, save, or delete licenses and certificates on the remote Niagara platform.
• Software Manager
To review, install, update, or uninstall “Niagara modules (.jars)” on the remote Niagara platform.
The Software Manager compares modules installed on the connected platform against those avail-
able (locally) on your Workbench PC.

NiagaraAX-3.6
1-3
Platform Guide
About platform differences Chapter 1 – Niagara platform
QNX-based April 4, 2011

• Platform Administration
To perform configuration, status, and troubleshooting of the Niagara platform daemon. Included
are commands to change time/date, backup all remote configuration, and reboot the host platform.
• Station Copier
To install (copy) a station from your Workbench PC and the remote Niagara platform, including dif-
ferent file-level options. Also to backup (copy) a station in a remote platform to your Workbench
PC, or to delete a remote station. You can easily rename any copied stations.
• TCP/IP Configuration
To review and configure the TCP/IP settings for the network adapter(s) of the Niagara platform.
• User Manager
Applies to remote Win32 platforms (e.g. JACE-NXS). To access host Windows OS user and group
accounts, including ability to add or delete users/groups, change passwords and group members.
• WiFi Certificate Manager, WiFi Configuration
Applies to remote AX-3.6 or later JACE with installed WiFi option (currently, a JACE-700 only).
Used to configure the 802.11b/g wireless interface provided by the WiFi option.
• Remote File System
To navigate among all files and folders under the platform’s Niagara root (system home) directory,
including the ability to make local copies on your PC.

About platform differences

Depending on the platform type opened, some platform views differ. There are three main categories of
platforms, by OS (operating system) used. In order of frequency, these include:
• QNX-based (most JACE controllers)
• Windows-based (Supervisor host, AX SoftJACE, and select JACE controllers)
• Linux-based Supervisor
Among the first two types, there are various JACE host models, each with a “model” string descriptor. For
a list of host models that are current with this document, see “Models of platforms” on page 1-9.

QNX-based
Sometimes called “embedded” JACE controllers, these include JACE-2,-6,-7 series controllers as well as
older JACE-4 and JACE-5 series models, all shipped with the QNX operating system. These devices use
onboard flash memory for file storage. An option for an onboard dial-up modem is available, or if needed,
an external modem can be used. The newer JACE-2,-6,-7 series also offer an option for an onboard
wireless (GPRS) modem. Starting in AX-3.6, the JACE-700 offers a wireless 802.11b/g (WiFi) option.
See the following for further details on QNX-based JACEs:
• Sun Hotspot JVM or IBM J9 JVM
• Backup Battery (or not)
• Platform view differences, QNX-based vs. Windows-based
Sun Hotspot JVM or IBM J9 JVM
Before AX-3.6, all QNX-based JACE controllers used the IBM J9 JVM (Java Virtual Machine) to host the
Niagara Runtime Environment (NRE). In AX-3.6 and later, the latest (JACE-6, JACE-7) series controllers
now use the Sun Hotspot JVM—the same VM type used in Windows-based NiagaraAX platforms.
For one of those JACEs upgraded from an earlier NiagaraAX release to AX-3.6, the core software distri-
bution automatically replaces the J9 JVM with the Hotspot JVM. The associated license upgrade also
includes the required “sunj2se” feature, needed to allow the JACE to operate.
Note: Due to space limitations, the JACE-2 series (all NPM2-based) controllers and previous (JACE-4, JACE-5)
series continue to use the IBM J9 JVM, regardless of NiagaraAX release level.
The Hotspot JVM provides a significant performance improvement. Plus, for developers and system
integrators skilled in creating Program components or custom applications (written in Java), the Hotspot
JVM provides J2SE support. This allows many of the newer Java APIs, which have never been supported
by the J2ME version in the IBM J9 JVM.
Otherwise, this JVM difference is typically “transparent” to the normal configuration of the JACE’s
hosted station or platform.
Note: An exception is the added support for IPv6 in the TCP/IP platform configuration of a Hotspot JACE.
See “TCP/IP changes in AX-3.6” on page 1-66 for related details.
For reasons like the above, the two QNX-based JACE subgroups are sometimes referred to as either
“Hotspot JACE” or “J9 JACE” in this document.

NiagaraAX-3.6
1-4
Platform Guide
Chapter 1 – Niagara platform About platform differences
April 4, 2011 QNX-based

Backup Battery (or not)

By default, all QNX-based JACE models have an integrated backup battery, typically a NiMH (nickel
metal hydride) onboard battery. A few models also support an additional external 12V SLA (sealed lead
acid) battery. The backup battery allows continuous operation during brief power outages.
The JACE provides a “power monitoring” component to track its AC power and backup battery level,
with a configurable delay for orderly shutdown of the JACE upon AC power failures. Access power
monitoring of a QNX-based JACE in the PowerMonitorService in a running station, see “About
Platform Services” on page 2-1.
Battery-less JACE Starting in AX-3.6, an “SRAM option card” became available for any JACE-2,-6,-7
series controller. If installed, the allows the JACE controller to operate without any backup battery, either
onboard NiMH or otherwise. In this case, a platform “DataRecoveryService” automatically replaces the
“PowerMonitorService” in the JACE’s station. For software details, refer to the Engineering Notes II
document JACE Data Recovery Service (SRAM support).
Platform view differences, QNX-based vs. Windows-based
For any QNX-based platform, the following platform views differ from Windows-based platforms:
• Dialup Configuration
• Platform Administration
Also, in the Application Director, you cannot Start a station after manually stopping it—you must
reboot the JACE instead. See“Application and output controls” on page 1-14.
Dialup Configuration
Dialup Configuration for a QNX-based platform has 3 sections (Figure 1-2):

Figure 1-2 Dialup Configuration for QNX-based platform

Unique to QNX platforms

Same as in Win32 platforms

• The Modem section includes properties to select JACE Comm port used, as well modem initializa-
tion strings and baud rate.
• A Listener section allows configuration for receiving calls.
• A Captive Network section is available (same as for a Windows-based JACE-NXT or JACE-NXS).
See “Dialup Configuration” on page 1-18 for more details.
Platform Administration
Platform Administration for a QNX-based platform (Figure 1-3) differs as follows:

NiagaraAX-3.6
1-5
Platform Guide
About platform differences Chapter 1 – Niagara platform
Windows-based April 4, 2011

Figure 1-3 Platform Administration for QNX-based platform

• An FTP / Telnet button is available. For details, see “FTP/Telnet” on page 1-45
• Selections possible in the Update Authentication function are simpler.
• Various data in summary information (repeated in View Details) differs greatly from Win32 hosts.
See “Platform Administration” on page 1-38 for more details.

Windows-based
Windows-based platforms include Win-32-based JACE hosts like the JACE-NXT (and previous JACE-
NXS and discontinued JACE-NX models), and most Windows-based “Supervisor” PC hosts and AX
SoftJACE hosts. File storage is a hard drive, and the operating system is typically either Windows XP
Professional, or more recently, Windows 7 Professional or Windows Vista Business. In some cases, a
Supervisor may be running Windows Server 2003 or later.
• Starting in AX-3.4, NiagaraAX Supervisor support began being added for Windows 64-bit OS
(Win64-based), including Win64 editions of Windows XP, Windows Vista, and Windows Server
2003. This support continued in AX-3.5, and in AX-3.6, Win64 support includes Windows 7.
Although a Win64 Supervisor uses a 64-bit JVM (Java Virtual Machine) and different NRE core bi-
naries, its NiagaraAX platform interface is nearly identical to any Win32-based Supervisor. There-
fore, you can equate a Win64-based Supervisor as a “Windows-based” host in various discussions in
this document, unless particularly noted. For further details, see “Win64-based Supervisor notes” on
page 1-7.
• The JACE-NXT, like the preceding JACE-NXS model, is a Win32-based platform, is available in both
a CompactFlash-memory based model and a hard-drive based model. In either case, “Windows XP
Embedded” is the operating system.
For any Windows-based platform, the following platform views differ from QNX-based platforms:
• Dialup Configuration
• Platform Administration
Note: When connected to any Windows host, a User Manager platform view is also available. Intended use is for
a Windows-based JACE only. On a Windows Supervisor, you typically configure Windows users and
groups using normal Windows administrative tools.
Dialup Configuration
Dialup Configuration for a Windows-based platform has 2 sections (Figure 1-4):

NiagaraAX-3.6
1-6
Platform Guide
Chapter 1 – Niagara platform About platform differences
April 4, 2011 Windows-based

Figure 1-4 Dialup Configuration for Win32-based platform

Same as in QNX platforms

• The Modem section provides only a drop-down list to select a modem known to Windows.
• No “Listener section” to configure for receiving calls (you must do this instead using Windows Dia-
lup Networking).
• A Captive Network section is available (the same as for any QNX-based JACE).
Note: Captive Network applies mostly to configuration of a JACE, vs. a Supervisor PC.
See “Dialup Configuration” on page 1-18 for more details.
Platform Administration
Platform Administration for a Win32-based platform (Figure 1-5) differs as follows:

Figure 1-5 Platform Administration for Windows-based platform

• No FTP / Telnet button is available (this configuration can be done directly using Windows).
• Choices available from the Update Authentication function are more involved.
• Various data in summary information (repeated in View Details) differs greatly from QNX hosts.
Note: If you have your local PC platform open, such as a Supervisor, buttons Commissioning, Reboot and
Set Module Filter are unavailable.
• Setting the Module Filter is intended only for initial configuration in a remote JACE. For more de-
tails, see “Set Module Filter” on page 1-47.
• The Commissioning Wizard is intended only for initial Niagara installation and startup in a re-
mote JACE, or whenever upgrading a JACE. For more details, see “Commissioning” on page 1-49.
• Reboot is intended only for remote JACE platforms (see “Reboot” on page 1-49). To locally reboot a
Supervisor, you should stop its local station, exit Workbench, then restart the operating system.
See “Platform Administration” on page 1-38 for more details.
Win64-based Supervisor notes
Starting in AX-3.4, Supervisor support was added for installation on PCs running 64-bit Windows
operating systems, for example Windows Server 2003 or Windows XP Professional x64 Edition. Support
for 64-bit Windows OS was expanded in AX-3.6 for Windows 7 Professional and Windows Server 2008.
The primary application is for a Supervisor station that has a very large NiagaraNetwork (job has large
numbers of JACEs, each with many Niagara proxy points), and thus, a large station database.

NiagaraAX-3.6
1-7
Platform Guide
About platform differences Chapter 1 – Niagara platform
Linux-based Supervisor April 4, 2011

In particular, the 64-bit JVM (Java Virtual Machine) does not have a 2GB memory limit, unlike the JVM
on a Win32-based Supervisor. Typically, any PC with 64-bit Windows also has 4GB or more of RAM
installed, as (unlike with a 32-bit Windows PC), the 64-bit OS can effectively utilize all of it. Therefore, a
64-bit Windows host may be the solution for the largest “enterprise level” Supervisor. See the following
sections “Known Limitations” and “Installation and interface differences” for more details.
Known Limitations Please note that at the time of this document update, there are several known
limitations for a Supervisor running on a 64-bit Windows operating system. Although most of these do
not apply to a “typical Supervisor”, they should be understood before installation time. These 64-bit
Windows platform limitations include the following:
• OPC client driver support for 64-bit platforms is currently unavailable—the OPC client driver re-
quires a Win32-based platform.
• Serial-based drivers (e.g.modbusAsync, flexSerial, various legacy drivers) are not supported on any
64-bit Windows platform. Typically, a Supervisor is not licensed for these drivers anyway.
• Lonworks FTT-10 is not supported on a 64-bit Windows platform —there are no Echelon 64-bit
drivers, and a Supervisor is not typically licensed for this driver. However “LonIP” is supported.
• Serial tunneling and LON tunneling drivers may not be available for 64-bit Windows platforms.
• Dialup modem support for 64-bit Windows platforms is not available, or severely limited.
Installation and interface differences Installation of the Win64-based Supervisor is like the Win32-
based installation, except that separate executables in the root of the Supervisor product CD are used to
install or uninstall (setup_x64.exe and uninstall_x64.exe).
A platform connection to a Win64-based Supervisor provides the identical collection of views as with a
Windows-based host. The one area of change is under the PlatformServices provided by the Supervisor’s
station, where the child “SerialPortService” is not seen.

Linux-based Supervisor
Starting in AX-3.4, Supervisor software is available targeted for a specific Linux-based platform: an Intel-
based PC platform running the OS of Red Hat Enterprise Linux 5. NiagaraAX installation on this
platform is done as user “root” using the supplied “Bash” install script. This results in a “niagarad” user
and group added, where almost all of the installed software files use niagarad as both owner/group.
During the install script process, existing users of the Linux host platform can be added as Workbench
users. This includes menu options to start Workbench and/or the Niagara Console application at the
Supervisor machine.
Note: Refer to the Engineering Notes document “Linux AX Supervisor Notes” for further installation details.
The following sections provide platform-related details about a Linux Supervisor:
• NiagaraAX platform rights on Linux Supervisor
• Default Linux Supervisor platform administrator
• Linux Supervisor platform views
• Linux Supervisor port usage notes
NiagaraAX platform rights on Linux Supervisor
During the install script process for the Supervisor Linux platform, a choice is presented as to whether
NiagaraAX users should be allowed to perform certain “root-privileged” tasks. These include tasks such
as specifying the host’s date and time, time zone, TCP/IP settings, and NTP settings, as made available in
various platform views. Note that in addition to the single NiagaraAX platform administrator, these items
may be available to Supervisor station users too, via views of the different Platform service types (for users
with admin-level permissions on PlatformServices).
The default install choice for this is “no,” such that related items in the platform views appear as read-only.
However, if this is changed to “yes” at installation time, NiagaraAX is installed such that the Niagara
platform administrator user will have the ability to modify these settings, as well as any Supervisor station
users with admin-write permissions on the station’s PlatformServices.
Default Linux Supervisor platform administrator
Following installation, the (single) default NiagaraAX platform administrator has these credentials:
• Username: tridium
• Password: niagara
On any real job, these credentials should always be immediately changed, by opening a platform
connection and using the Update Authentication option in the Platform Administration view.
Note this is particularly important if the “root-privileged” tasks were enabled at installation time.

NiagaraAX-3.6
1-8
Platform Guide
Chapter 1 – Niagara platform About platform differences
April 4, 2011 Models of platforms

Linux Supervisor platform views

At the time of this document update, a platform connection to a Linux-based Supervisor provides the
same collection of platform views as to an AX-3.4 or later Windows-based Supervisor, except the
following views are not present:
• DDNS Configuration
• Dialup Configuration
• User Manager (always specific to Windows-based hosts only)
Platform service types in the Supervisor’s station also include fewer types than in other host platforms,
currently limited to the TcpIpService, LicenseService, and NtpPlatformServiceLinux.
Linux Supervisor port usage notes
Note that the station running on a Linux Supervisor is “owned” by a specially created user/group
niagarad:niagarad, and therefore cannot bind to Linux “root owned” software ports 1- 1024. This is
not an issue for the conventional port (3011) used for a platform connection, but does affect the standard
port used by the station’s WebService (Http Port), which cannot be used at the default port (80) setting.
In addition, other software ports potentially used by various drivers must be adjusted above port 1024.

Models of platforms
Among the two groups of JACE controllers (QNX-based and Windows-based), there are different
models, each of which has a “model” text descriptor. You see this model descriptor in the Station
Manager view of a Niagara Network (Host Model column), and also in platform views such as
Platform Administration, as well as the PlatformServices container of a station running on that host.
Table 1-1 lists various platform models (including JACEs), known at the time of this document, starting
with the model text descriptor.

Table 1-1 Host models of JACE platforms

Model desc. Actual Model Notes
J402 JACE-402P QNX-based. Uses the IBM J9 JVM (Java Virtual Machine).
J403 JACE-403 series See the JACE NiagaraAX Install and Startup Guide for commissioning details.
J404 JACE-545 series,
J5-R-AX (Rack
Mount)
J511 JACE-511 series Discontinued models, QNX-based. Uses the IBM J9 JVM (Java Virtual Machine).
J512 JACE-512 series See the JACE NiagaraAX Install and Startup Guide for commissioning details.

JNX JACE-NX series Discontinued model, Win32-based.

See the JACE-NX NiagaraAX Install and Startup Guide for commissioning details.
JNXS JACE-NXS series Win32-based, previous model before latest JACE-NXT series.
See the JACE-NXS NiagaraAX Install and Startup Guide for commissioning details.
JNXT JACE-NXT series Latest Win32-based JACE controller.
See the JACE-NXT NiagaraAX Install and Startup Guide for commissioning details.
JVLN JACE-7 series QNX-based, with more processing power than JACE-2/6 series. Introduced in the AX-3.5
(JACE-700) time frame. See the JACE NiagaraAX Install and Startup Guide for commissioning details.
Note: Starting in AX-3.6, this JACE series uses the Sun “Hotspot” JVM instead of the IBM J9
JVM, and also supports IPv6. A 802.11b/g wireless (WiFi) option is also available.
NPM2 JACE-2 series, includ- QNX-based. Uses the IBM J9 JVM (Java Virtual Machine). Among the most popular.
ing Security JACE Includes the JACE-202 Express, or “M2M JACE 2” with onboard I/O points.
(SEC-J-201), See the JACE NiagaraAX Install and Startup Guide for commissioning details. For Security
JACE-202 Express JACE (SEC-J-201) commissioning details, see the Security Enterprise Guide.
(M2M JACE 2)
NPM6 JACE-6 series, includ- QNX-based, with more processing power than the JACE-2 series. Among the most popular.
ing Security JACE Includes the JACE-602 Express, or “M2M JACE 6” with onboard I/O points.
(SEC-J-601), See the JACE NiagaraAX Install and Startup Guide for commissioning details. For Security
JACE-602 Express JACE (SEC-J-601) commissioning details, see the Security Enterprise Guide.
(M2M JACE 6) Note: Starting in AX-3.6, this JACE series uses the Sun “Hotspot” JVM instead of the IBM J9
JVM, and also supports IPv6.

NiagaraAX-3.6
1-9
Platform Guide
Application Director Chapter 1 – Niagara platform
Models of platforms April 4, 2011

Model desc. Actual Model Notes

Jsoft AX SoftJACE Windows-based. This is different than a Supervisor for example, which appears instead as
installed on “Workstation”.
user-supplied PC
Workstation User-supplied PC, Windows-based customer supplied PC that runs Workbench, minimally.
either a Supervisor or
engineering worksta-
tion.
Linux ver- Linux-based Supervi- Red Hat Linux Enterprise 5 operating system.
sion sor

Application Director
The Application Director is one of several platform views. You use it to start or stop a station in any
Niagara host (whether a remote JACE or a local or remote Supervisor PC), as well as see station output
for troubleshooting purposes. From the Application Director, you also define a station’s “restart” settings,
plus have access to other station actions.
Note: NiagaraAX platform support for Sedona Framework apps, including the ability to access apps from this
view, was removed in AX-3.6 and later maintenance builds of AX-3.5 and AX-3.4.

Figure 1-6 Application Director view, looking at station

As shown in Figure 1-6, the Application Director is split into three main areas:
• Installed applications (stations) — at top
• Application output — main area
• Application and output controls — right-side checkboxes and buttons
Note: In the Application Director for any JACE, the “installed applications” area should show (at most) only one
station, as shown in Figure 1-6. However, the Application Director for a PC platform (Supervisor,
NiagaraAX engineering workstation) may show multiple stations, as shown in Figure 1-7.

NiagaraAX-3.6
1-10
Platform Guide
Chapter 1 – Niagara platform Application Director
April 4, 2011 Installed applications (stations)

Figure 1-7 Application Director for Supervisor host showing multiple stations

Note: Prior to AX-3.6, the Application Director could show a maximum of 32 stations—regardless if
more stations were under the host’s stations directory. Starting in AX-3.6, the Application Director was
changed to allow access to all stations, even if over 32.

Installed applications (stations)

The top area of the Application Director shows a table of installed applications (stations), as shown in
Figure 1-8. Apart from the data shown in the table, application selections are possible.

Figure 1-8 Application Director installed applications

Every 1.5 seconds, the platform daemon fetches data about the station(s) and updates this in the following
columns:
• Name
The name of the station directory.
• Type
This is always “station” for a Niagara station.
Note: In earlier AX-3.4 and AX-3.5 builds, a type of “app” was also possible, for a Sedona app.
However in AX-3.6 and later maintenance builds of AX-3.5 and AX-3.4, NiagaraAX platform support
for Sedona was dropped. Platform-level operations for a Sedona device now require a Sox connection.
• Status
One of the following, as applied to a station:
• Idle — Station is not running, but can be started without a reboot.
• Running — Station is running.
• Starting — Platform daemon has started the station, but the station has not reported back its
status back to the daemon.
• Stopping — Daemon has ordered the station to stop, but its process has not yet terminated.
• Halted — Station is not currently running, and cannot be restarted without a reboot.
• Failed — Station terminated with a failure exit code.
• Details
For any station, shows two items:
• fox= The TCP/IP port monitored for Fox connections to Workbench and other Niagara sta-
tions. Shows “n/a” if station is not running, or if it does not run the Fox service.
• http= The HTTP port that the station’s WebService monitors for browser connections to the
station. Shows “n/a” if station is not running, or if it does not have a running WebService.
• Auto-Start
Either true or false. If true, the station starts whenever the platform daemon starts. Configured with
a right-side checkbox (see “Start checkboxes” on page 1-14).
• Restart on Failure
Either true or false. If true, the daemon automatically restarts the station after it terminates with a
failure exit code. Configure with a right-side checkbox (see “Start checkboxes” on page 1-14).

NiagaraAX-3.6
1-11
Platform Guide
Application Director Chapter 1 – Niagara platform
Application output April 4, 2011

Application selections
Click in the installed applications table for different results, as follows:
• click
Click a station to select it, highlighting it. When a station is selected, its standard output appears, and
all enabled right-side buttons apply to it. For details, see “Application output” on page 1-12 and “Ap-
plication and output controls” on page 1-14.
• right-click
Right-click a station for its shortcut menu (a subset of the application and output actions buttons).
For details on included menu commands, see “Application and output controls” on page 1-14.
• double-click
If running, double-click a station to open a Workbench (Fox) connection to it, showing its Station
Summary view. Or, press Ctrl and double-click for a new tab showing the station connection.
If not running, a station double-click does not change the view.

Application output
The largest area in the Application Director view shows the “standard output / standard error” output
text for the selected station (Figure 1-9).

Figure 1-9 Station output in Application Director’s application output area

Depending on the status of the station selected, the standard output text is one of the following:
• If a running station, output updates in real time. As more text is written by the station, it is appended
to the bottom of the output area.
• If the station is not running, output text is from the most recent execution of that station.
• If no station is selected, output text area is blank.
Note: Use the Windows copy shortcut (Ctrl + C) to copy output text to the clipboard.
As needed, use scroll bars to view all text, and use the right-side output control buttons. For more details,
see “Output control buttons” on page 1-15.
The following sections provide more details related to a station’s standard output:
• Standard output overview
• Station log levels (spy:/logSetup)
• Station LogHistory (LogHistoryService)
Standard output overview
Station output messages can include errors and warnings that let you why something is not working, as
well as simple informational messages about events as they occur. If needed, you can also change the
“level” of station output—see “Station log levels (spy:/logSetup)” on page 1-13.
The general format of a station output message is:
TYPE [timestamp] [station_process] message_text
For example:
MESSAGE [13:53:08 08-Mar-05][fox] Service started on port 1911
Message types seen in station output include the following, by leading text descriptor
• MESSAGE
Typically comprise most default station output messages. Usually, each message lets you know some
process milestone was started or reached, such as a service or the station itself.

NiagaraAX-3.6
1-12
Platform Guide
Chapter 1 – Niagara platform Application Director
April 4, 2011 Application output

• WARNING
Informs you of a potential problem, such as inability to open a specific port. Typically, warnings do
not keep a station from starting.
• ERROR
Informs you of a problem that might keep the station from starting. Or, if it can start, an error that
prevents some function of the station from operating correctly.
• TRACE
A verbose debug-level message that may be generated upon every process transaction. Useful only
in advanced debugging mode. You see these for station processes only if you have set the log level at
“Trace”.
In addition to the “typed” output messages described above, occasionally you may see a string of “java
exception” text in the a station’s output. This indicates an unforeseen station execution issue, which can
range from a licensing problem, a misconfiguration, or some other unexpected problem. If an
unexplained exception reoccurs, copy the exception text and report the problem to Systems Engineering.
Station log levels (spy:/logSetup)
A running station is a combination of many ongoing processes. Using the station’s spy “logSetup” page
(Figure 1-10), you can change the “log level” of the station processes of interest in order to “tune” station
output.

Figure 1-10 Station spy logSetup (from Station Summary)

Note: To get to a running station’s logSetup page in Workbench, double-click the station in the Nav tree for its
Station Summary view. From there, double-click Spy, then click logSetup.
By default, all station processes have a “Message” log level (level selection denoted by [X]). To change the
level of any listed process, click in the desired level column.
Level selection columns are ordered left-to-right in decreasing order of message volume, as follows:
• Trace
Returns all message activity (verbose). This includes all transactional messages, which may result in
too many messages to be useful. Be careful using Trace!
• Message
(Default) Returns informational “MESSAGE”s, plus all “ERROR” and “WARNING” types.
• Warning
Returns only “ERROR” and “WARNING” type messages (no informational “MESSAGE”s).
• Error
Returns only “ERROR” type messages (no “WARNING” or informational “MESSAGE”s).
• None
No messages are returned to the station’s output.

Caution Increasing station output by assigning trace levels consumes extra station resources and exacts a
performance penalty! After troubleshooting, return log levels to default values.

NiagaraAX-3.6
1-13
Platform Guide
Application Director Chapter 1 – Niagara platform
Application and output controls April 4, 2011

Station LogHistory (LogHistoryService)

If a station is configured with the LogHistoryService (under its Services container), it maintains a
buffered history (“LogHistory”) of some of the messages seen in the station’s standard output. In the
LogHistoryService’s configuration, you specify its log level, meaning the minimum message type (from
station output) to log. By default, the log level (property “Minimum Severity”) is Error. You may wish to
change this to Warning.
This is mentioned because when looking at a station’s output, you are usually troubleshooting. As part of
troubleshooting, you should always check the station’s histories for LogHistory. It should contain recently
recorded station errors and (if configured) warnings. This information may help when evaluating “live”
output from the station.

Application and output controls

Unlike in most Workbench views, where changes are entered first and then applied with a “Save” button,
in the Application Director when you click checkboxes and buttons (Figure 1-11), changes are applied
immediately to the selected station.

Figure 1-11 Application Director checkboxes and buttons

From top-to-bottom, these controls are grouped as follows:

• Start checkboxes (Auto-Start, Restart on Failure)
• Application control buttons (Start, Stop, Restart, Reboot, Kill, Dump Threads, Save Bog, Verify Soft-
ware)
• Output control buttons (Clear Output, Pause Output, Output Dialog)
• Output Settings button
Start checkboxes
For the currently selected station in the Application Director, you can enable (check) or disable (clear)
two start settings using checkboxes (Figure 1-11). Typically, for any JACE station you enable both check-
boxes. In certain troubleshooting scenarios, you may clear Restart on Failure in order keep the
station from constantly restarting (or host rebooting) after successive failures.
Note: Changes are reflected in the corresponding column of the Application Director’s installed applications
area.
The two start settings for a station are as follows:
• Auto-start
Specifies whether the station starts following platform daemon startup. This means following a host
reboot, perhaps as a result of a power cycle, but possibly from a Reboot command.
Note: For any QNX-based JACE, a reboot also occurs following any installed dist file(s), as well any
TCP/IP-related changes. However, starting in AX-3.5, installing new modules from the Software
Manager—say, for a new driver, typically does not result in a reboot. At the same time, note that
changing an existing module (upgrading or downgrading) does result in a reboot.
• Restart on Failure
Specifies whether the platform daemon restarts the station if its process exits with a nonzero return
code (e.g., engine watchdog had killed the station because of a “deadlock” condition).

NiagaraAX-3.6
1-14
Platform Guide
Chapter 1 – Niagara platform Application Director
April 4, 2011 Application and output controls

Note: QNX-based JACEs cannot have a station restart without a reboot. Therefore, if this setting is
enabled on such a JACE, if the station fails (terminates with error), the JACE reboots.
If a JACE continues to have 3 “automatic reboots” like this within an hour (or however many specified
in the station’s PlatformService “Failure Reboot Limit” property), it remains in a “Failed” state,
regardless of the setting above. For related details, see “PlatformServiceContainer configuration
parameters” on page 2-4.
Application control buttons
For the selected station in the Application Director, application control buttons (Figure 1-11) apply as
follows:
Note: Be careful about using station controls, and understand the difference between them before using them.
• Start
Enabled only if the station has an “Idle” or “Failed” status in the installed applications area. When
pressed, that host’s platform daemon immediately starts that station. Text in the standard output is
cleared, and output messages begin with the new startup of that station.
Note: If you manually stop a station on a QNX-based JACE (using Stop button), it has a status of
“Halted.” In this case, the Start button will not be available. You must Reboot the platform to restart
the station. This differs from a manually stopped station on a Windows-based host or Linux-based
Supervisor, which then shows a status “Idle.”
• Stop
Enabled only if the station has a “Running” status in the installed applications area. When pressed, a
popup confirmation appears. If you confirm, the host’s platform daemon shuts the station down
gracefully (saving its configuration to its config.bog file, and potentially saving history data). See
the preceding note about stopping the station on a QNX-based host.
• Restart
(Available Windows-based platforms only) Enabled only if the station has a “Running” status in the
installed applications area. When pressed, a popup confirmation dialog appears. If you confirm, the
host’s platform daemon shuts the station down gracefully, then restarts it.
• Reboot
Always enabled. When pressed, a popup confirmation dialog appears. If you confirm, the selected
host is rebooted. This is considered a drastic action. For details, see “Reboot” on page 1-49.
• Kill
Enabled only if the station has a status of “Starting”, “Stopping”, or “Running” in the installed appli-
cations area. When pressed, a popup confirmation dialog appears. If you confirm, the host’s platform
daemon terminates the station process immediately.
Note: Always use Stop instead of Kill, unless unavailable (stuck for a long time as either
“Starting” or “Stopping”). Unlike a station stop, a station kill does not cause the station to save its
database (config.bog), histories or alarms, nor does it update the standard output area.
• Dump Threads
(station only) Enabled only if the station has a “Running” status in the installed applications area.
When pressed, the host’s platform daemon has the station send a VM thread dump to its standard
output.
• Save Bog
Enabled only if the station has a “Running” status in the installed applications area. When pressed,
the host’s platform daemon has the station locally save its configuration to config.bog.
• Verify Software
Enabled regardless of station status. When pressed, Workbench parses the station’s config.bog
file and the host’s platform.bog file, looking for module references. Workbench then checks to
see if those modules (and any other software upon which they depend) are installed. Any missing
software is listed in a popup dialog, and if available in your Workbench installation, the dialog offers
to install the missing software into the remote host.
Note: Starting in AX-3.5, only modules (or versions of modules) needed by the station are installed
that do not require commissioning. If the station needs modules that require commissioning, meaning
an upgrade of core NiagaraAX software, those modules are not copied.
Output control buttons
For the selected station in the Application Director, output control buttons (Figure 1-11) apply as follows:
• Clear Output
Enabled regardless of station status. When pressed, all text in the standard output area is cleared.

NiagaraAX-3.6
1-15
Platform Guide
Ddns Configuration Chapter 1 – Niagara platform
Application and output controls April 4, 2011

Note: Data in the standard output area is fetched from a memory buffer in the platform daemon.
Clearing the output does not actually clear the daemon’s buffer. Therefore, if you change the selection
away from, and then back to the station, it re-fetches all buffered data.
• Pause Output
Enabled only if the station has a “Running” status in the installed applications area. When pressed,
the button toggles to “Load Output”, and the next press back to “Pause Output” (and so on).
• During a paused output, text remains frozen in the standard output area. This is useful when
the station is rapidly writing output.
• When you press Load Output, text in the standard output area is reloaded with the station’s
buffered output, and output remains updating in real time.
• Output Dialog
Enabled regardless of station status. When pressed, this produces a separate “non-modal” output
window displaying the same output text as in the Application Director’s standard output area. In-
cluded are buttons to Dump Threads, Pause Output, Clear Output, and Close the win-
dow.
Note: You may find this “compact” version of a station’s standard output easier to work with than in
the main area of the Application Director. Also, if needed you can open multiple output dialogs for
comparison purposes.
Output Settings
For the currently selected station in the Application Director, the Output Settings button produces
a dialog (Figure 1-12) in which you specify how the platform daemon buffers the output from that station.

Figure 1-12 Output Settings dialog

The two available settings are in bytes, and are:

• Memory Buffer Size
Size of the memory buffer for the station output. If the station creates more output that the size of
the memory buffer, the oldest output is lost.
• Maximum File Size
When the station stops, its output buffer is written to a console.txt file. This setting defines the
maximum size of that file.
Note: Changes to either output setting may result in the output buffer’s contents to be cleared.

Ddns Configuration
Ddns Configuration is one of several platform views, available on any platform running AX-3.1 or later.
DDNS (Dynamic Domain Name System) allows for DNS IP addresses to be dynamically updated.
Typically, these are DHCP (Domain Host Configuration Protocol) addresses (Internet or Intranet) or
dialup addresses. Figure 1-13 shows the default Ddns Configuration view.

Figure 1-13 Ddns Configuration platform view

Note: Refer to the Engineering Notes document “NiagaraAX-3.1 DDNS” for more details and examples.

NiagaraAX-3.6
1-16
Platform Guide
Chapter 1 – Niagara platform Ddns Configuration
April 4, 2011 DDNS core configuration items

The following sections provide a few basic DDNS configuration details:

• DDNS core configuration items
• About TZO

DDNS core configuration items

The platform Ddns Configuration view has the following configuration sections:
• Provider
• Mode
• Captive Network section
Provider
The top property in the Ddns Configuration view is to select from a list of supported DDNS providers.
Currently, the only supported provider is Tzo (see “About TZO” on page 1-17), although future builds
may support other providers.

Figure 1-14 DDNS Provider selection and Provider-supplied configuration properties

Note: A DDNS account with a provider is typically a fee-based subscription, in which you must first register and
pay before your account is active.
Once you select the DDNS Provider, you require information from that provider about your DDNS
account, in order to populate the following properties in the Provider section (Figure 1-14).
• Key
Furnished by provider (TZO) after account creation.
• Email
Email address associated with the provider (TZO) account.
• Domain
Domain name associated with the DDNS account.
Mode
This property in the Ddns Configuration view selects the operational mode of DDNS.
DDNS mode choices include:
• Disabled
DDNS functionality is completely disabled.
• Internet
Uses the IP address assigned to the adapter specified in the Adapter property.
• Intranet
Uses the IP address as seen when connected to the DDNS provider (note that not all providers will
support this).
• Dialup
Use the IP address assigned once a dialup connection has been established.
Adapter
This property in the Ddns Configuration view applies if DDNS Mode is Internet, and selects the
adapter to interrogate for an IP address.

About TZO
You can create a DDNS account with TZO (Tzolkin Corporation) at http://www.tzo.com. Testing of the
NiagaraAX Ddns Configuration has focused primarily with TZO accounts.

NiagaraAX-3.6
1-17
Platform Guide
Dialup Configuration Chapter 1 – Niagara platform
Platform dialup configuration sections April 4, 2011

Dialup Configuration
Dialup Configuration is one of several platform views. It provides platform setup of the host’s modem and
optional settings for “Captive Network” dialup support. For any QNX-based platform, an additional
“Listener” section allows configuration of the modem for receiving calls.
Note: Dialup configuration varies by platform type, see “About platform differences” on page 1-4.

Figure 1-15 Dialup Configuration platform view

The following main sections provide dialup configuration details:

• Platform dialup configuration sections
• About the dialup daemon and service
• About dialup operation

Platform dialup configuration sections

The platform Dialup Configuration view has the following configuration sections:
• Modem section
• Listener section
• Captive Network section
Note: If the platform’s dialup daemon is started when you make configuration changes, a dialup daemon restart
occurs when you Save. See “About the dialup daemon and service” on page 1-21.
Modem section
This section of the platform Dialup Configuration view is to select the modem/port used by the platform
for dialup access. For QNX-based JACEs, other parameters are available too (Figure 1-16).
Note: If a JACE has a GPRS (wireless) modem module installed, note that the GPRS modem implementation is
handled in a separate platform view, see “GPRS Modem Configuration” on page 1-31 for more details.

Figure 1-16 Modem section properties, platform Dialup Configuration (QNX-based JACE only)

QNX-based Modem properties include:

• Init Strings or Init String

NiagaraAX-3.6
1-18
Platform Guide
Chapter 1 – Niagara platform Dialup Configuration
April 4, 2011 Platform dialup configuration sections

The modem initialization string(s) sent to the modem upon station restart, dialup service start, and
any dial out activity. This configures the modem’s options for things like error correction, data com-
pression, flow control, and other parameters. Typically, Hayes-type commands are used.
Support is provided for multiple init strings. In addition, a “wizard” Select Init String Template dia-
log was added (see Figure 1-16) which simplifies selecting and entering init strings for core-support-
ed modems, including US Robotics, Cermetek, Radicom, Netcom Roadster, and Siemens MC75.
Currently, init strings for modems connected to a QNX-based JACE include:
• Cermetek (typical optional onboard modem, see “Init String notes” on page 1-19):
ATE0S0=0Q0V1X4&D2&K3\N3%C2&C1&Q5W2
• US Robotics 33.6 and above modem:
AT&F1E0&A1X4
• Radicom:
ATE0S0=0Q0V1X4&D2&K3\N3%C2&C1&Q5W2
• Netcom Roadster:
AT&FE0\N3&K3&R1
• Siemens MC75 (GPRS type):
AT&D2
AT^SMONG
AT^SGAUTH=0
AT+CREG=1
AT+CGDCONT=1,ip,wwantrial.acfes.org
• Baud Rate
Modem’s baud rate used for all activity. Default is 57600 (compatible with onboard 56K modem).
• Port
COM port name associated with modem. For most QNX-based JACEs, this will be either COM2 for
an onboard dialup modem, or COM1 for an external modem.
Init String notes Due to varying command sets used among modems, determining the needed init
string for any particular modem is often time consuming. For comparison purposes, here is a breakdown
of modem commands used within the “known functional” init string for the Cermetek modem:
• AT — attention sequence
• E0 — echo off
• S0=0 — disable auto-answer
• Q0 — allow result codes to DTE
• V1 — return long form result codes (verbose)
• X4 — report basic call progress codes: OK, CONNECT, RING, NO CARRIER, etc.
• &D2 — interpret DTR On to Off transition per &Q0, &Q5, &Q6
• &K3 — enable RTS/CTS DTE/DCE flow control
• \N3 — elects auto reliable mode
• %C2 — enable v.42bis data compression
• &C1 — profile 1 after warm reset
• &Q5 — modem negotiates an error corrected link
• W2 — report DCE speed in EC mode
Listener section
This section of the Dialup Configuration view is for configuration of receiving calls (QNX-based
platforms only).
Note: In order to receive a call on Windows-based platforms, you must configure standard Windows Dialup
Networking.
As shown in Figure 1-17, you must enable the “Listen For Calls” checkbox to access properties.

Figure 1-17 Listener properties in Dialup Configuration for QNX-based JACE

Listener properties include:

NiagaraAX-3.6
1-19
Platform Guide
Dialup Configuration Chapter 1 – Niagara platform
Platform dialup configuration sections April 4, 2011

• Local IP Address
The local IP address to use once the connection has been established.
Note: This is just a recommendation, there is no guarantee as to what the final address will be.
• Remote IP Address
The remote IP address to use once the connection has been established.
Note: This is just a recommendation, there is no guarantee as to what the final address will be.
• User Name
The dialup user name used when authenticating a dialup connection.
• Password
The dialup password used when authenticating a dialup connection.
Note: User name and password is used to establish the dialup connection itself, before the additional (and
independently maintained) authentication needed to either open the station or a host platform session. On
the remote (calling) side, the corresponding dialup user name and password is part of the “dialup address”
associated with this host platform. See “About dialup operation” on page 1-22 for more details.
Captive Network section
This section of the Dialup Configuration view is for any modem-equipped JACE. A captive network is
where the JACE can try and remain connected to a dialup network.
When used in this fashion, the station is generally not aware that a dialup connection is being used, but
instead simply tries to connect to a dialup address. If the dialup connection breaks, the JACE tries to re-
establish the connection.
As shown in Figure 1-18, you must enable the “Captive Network” checkbox to access properties.

Figure 1-18 Captive Network properties in Dialup Configuration

Captive Network properties include:

• Phone Number
The phone number to dial.
• Alternate Phone Number
An additional phone number to dial if the first one fails.
• User Name
The dialup user name used when authenticating.
• Password
The dialup password used when authenticating.
• Min. Disconnect Time
The minimum amount of time, after a forced hangup, before a new captive network connection can
be initiated (does not apply to Workbench).
• Max. Connect Time
The maximum amount of time a captive network-initiated connection can remain established be-
fore a hangup is forced (does not apply to Workbench).
Note: If configuring a JACE for a captive network connection, to ensure that there is time allowed for incoming
calls, it is recommended that you set the “Min. Disconnect Time” to be greater than the “Max. Connect
Time.” Furthermore, in the station running on the JACE, for each NiagaraStation accessed via dialup, its
dialup address also has similar connection time properties. In this case, you should set each “Min.
Disconnect Time” (both captive network, and that in each NiagaraNetwork dialup address) to be greater
than the sum of all “Max. Connect Times” (the captive network one plus all NiagaraNetwork dialup
address ones).

NiagaraAX-3.6
1-20
Platform Guide
Chapter 1 – Niagara platform Dialup Configuration
April 4, 2011 About the dialup daemon and service

About the dialup daemon and service

Dialup operation is enabled and disabled by starting or stopping the dialup daemon (process) in the host
platform. To provide station access to the dialup daemon, a running station has a corresponding platform
service under its Services container: the DialupService.
Dialup daemon
Any dialup modem-equipped Niagara platform requires you to start the dialup daemon to allow modem
operation. Click the Start button at the bottom of the platform Dialup Configuration view to do this,
as shown in Figure 1-19.

Figure 1-19 Start dialup daemon from bottom of platform Dialup Configuration view

When you start the dialup daemon, platform dialup configuration becomes effective, and modem opera-
tions are enabled. Once successfully started, the Stop button becomes enabled.
Note: If you click Stop to stop the dialup daemon, a confirmation dialog appears (Figure 1-20).

Figure 1-20 Stop dialup daemon dialog

If you click Yes, modem operations are disabled (any active dialup session is dropped).
Dialup daemon restart If the dialup daemon is already started, and you make any platform dialup
changes, the daemon is restarted upon Save. A notification dialog appears, as shown in Figure 1-21.

Figure 1-21 Restart dialup daemon notification

Upon a dialup daemon restart, any active dialup session is dropped.

DialupService
Among a station’s PlatformServices is a DialupService, the station’s interface to the platform’s dialup
daemon. Three slots of interest on the DialupService include:
• Daemon Session
Shows the current connection state to the dialup daemon (not to be confused with a dialup session
with a remote host). The possible values are:
• Init
• Auth
• Active
• Closed
Note: Values are “just-in-time” types and do not change unless some dialup code executes. In other
words, just starting the dialup daemon does not necessarily change this value.
• Block Listen
A StatusBoolean slot you can use to disable or enable listen functionality (if enabled in platform) by
linking to station logic. See Block out functionality.
• Block Connect
A StatusBoolean slot you can use to disable or enable a dialup connection by linking to station logic.
See Block out functionality.

NiagaraAX-3.6
1-21
Platform Guide
Dialup Configuration Chapter 1 – Niagara platform
About dialup operation April 4, 2011

Block out functionality If dialing functionality needs to be disabled programmatically (from the
station), you can link the Block Listen and/or Block Connect slot of the DialupService to the
StatusBoolean out of a controlling object or point.
An example would be to link a BooleanSchedule to one or both slots to disable dialup during certain
periods of time.
Note: Block out functionality only works when a station is running. If no station is running, the defaults of false
are assumed.

About dialup operation

Dialup in NiagaraAX can occur from Workbench (user-initiated call) or from a station. The following
sections provide more details:
• Dialup addresses
• Calling from Workbench
Dialup addresses
When dialing out from Workbench or configuring a station to dial out, the dialup “Host” ord uses a
named dialup address for making the connection. Dialup addresses are local to the platform that initiates
the connection. In other words, dialup addresses used by your Workbench are unique to your instance of
Workbench, dialup addresses used by a JACE station are unique to that station, and so on.
You add dialup addresses for Workbench or a JACE starting in different dialogs, as follows:
• Workbench dialup address
• Station dialup address
In either case, you use a Dialup dialog to add, edit, or delete dialup addresses.
Workbench dialup address In Workbench, you create dialup addresses by starting from the Open
Platform or Open Station dialog, selecting Host type “Dialup,” and then using the >> button on
the right side of the host field, as shown in Figure 1-22.

Figure 1-22 Dialup dialog from Open Platform or Open Station dialog in Workbench

This produces the Dialup dialog, for managing dialup addresses.

Station dialup address In a station, you create a dialup address by manually adding a target NiagaraS-
tation (in the station’s NiagaraNetwork), using the New button.
In the station’s New (or Edit) dialog, you select Address type of “Dialup,” and use the >> button on the
right side of the address field, as shown in Figure 1-23.

NiagaraAX-3.6
1-22
Platform Guide
Chapter 1 – Niagara platform Dialup Configuration
April 4, 2011 About dialup operation

Figure 1-23 Dialup dialog from NiagaraStation New dialog in station

This produces the Dialup dialog, for managing dialup addresses.

Dialup dialog In the Dialup dialog you manage all dialup addresses for use by the platform (Workbench
PC or JACE), as shown in Figure 1-24.

Figure 1-24 Add Address dialog for new dialup address

Buttons in the Dialup dialog allow you to:

• Add — Add a new dialup address.
• Edit — Edit an existing dialup address.
• Delete — Remove an existing dialup address.
• Set Default — Change the current default address.
When adding or editing a dialup address, the following fields are available:
• Name
Name for the dialup address, must be unique within that platform.
• Phone Number
Name for the dialup address, must be unique within that platform.
• User Name
Name for the dialup address, must be unique within that platform.
• Password
Name for the dialup address, must be unique within that platform.
• Min. Disconnect Time
Applies only to dialup address used by a station (not to Workbench). This specifies the minimum
amount of time, following a disconnect from a dialup connection, before another dialup connection
can be initiated.
• Max. Connect Time
Applies only to dialup address used by a station (not to Workbench). This specifies the maximum
amount of time a dialup connection will remain established before a hangup is forced.

NiagaraAX-3.6
1-23
Platform Guide
Distribution File Installer Chapter 1 – Niagara platform
About dialup operation April 4, 2011

Calling from Workbench

You can open a platform or station connection to a JACE from Workbench using a dialup connection,
just like making a LAN (IP) connection.
Note: On your Workbench PC, the platform daemon must be installed and running. Also, the dialup daemon
must be started. See “About the dialup daemon and service” on page 1-21 for details.

To dialup a JACE from Workbench

To dialup a JACE from Workbench, do the following:
Step 1 Select File > Open, then either Open Platform or Open Station.
Step 2 In the Open Platform or Open Station dialog, click the Host drop-down and select Dialup.
Step 3 Click the >> button on the right.
A popup Dialup dialog appears, showing all saved dialup addresses. See “Workbench dialup address”
on page 1-22 for details.
Step 4 Click a dialup address to select it, then click OK.
The dialup address name is now in the “Host” field of the Open Platform or Open Station dialog.
Note: You can also simply type in a known dialup address, without going to the popup dialog. Consequently, you
can type in a phone number in the Host field instead of a dialup address name. This results in the default
address being used, but uses the provided phone number instead of the default phone number.
Step 5 Type in the appropriate user name and password for the platform or station.
Step 6 Click OK to initiate the dial out to the JACE.
If not currently connected, and the modem is not already in use, a dialup connection will be established.
If the connection to the same host already exists, that connection will be reused. If a different connection
already exists, this attempt will be rejected.

Distribution File Installer

Note: Starting in Workbench AX-3.5, you must use the Commissioning Wizard to upgrade a JACE. Previ-
ously, upgrading was possible (but not recommended) using the Distribution File Installer. The wizard is a
right-click option on the platform when opened in Workbench. See “Upgrading a JACE” on page 1-29.
The Distribution File Installer is one of several platform views, used to install dist files. A dist file is a zip
file that contains other files and a “manifest” that describes the contents of the distribution. For technical
details, see the “Distribution” section in the online Niagara Developer Guide.
Use this view for either of these two tasks:
• To restore a locally available “backup” .dist file of a remote JACE. Such a backup can be initiated us-
ing the Backup command from the platform’s Platform Administration view, or directly from the
BackupService in the station running on that host.
• To install a “clean” dist file, in order to downgrade a JACE to an older release level, or restore it to a
“known good” state before installing other software. Note that this wipes the file system (including
all station files), leaving the JACE in a “near factory” state. For details, see “Downgrading a JACE
(Clean Dist)” on page 1-28.

Caution If a station is already running on the remote host, any dist file install requires all applications to be
stopped, after which all are invariably overwritten! After selecting a dist file, the Installer provides a
confirmation dialog for this, as shown in Figure 1-25. When you finalize the install (click Finish), the
Installer automatically stops the station, then continues with the distribution file install process.

Before finalizing any dist installation, make sure that controlled equipment that might be adversely
affected by the JACE’s station stopping (and removal) is put in a manually controlled state.

NiagaraAX-3.6
1-24
Platform Guide
Chapter 1 – Niagara platform Distribution File Installer
April 4, 2011 Operation of the Distribution File Installer

Figure 1-25 Stop station dialog in Distribution File Installer

The following sections provide more details on the Distribution File Installer:
• Operation of the Distribution File Installer
• Restoring a backup dist
• Downgrading a JACE (Clean Dist)

Operation of the Distribution File Installer

The following subsections explain more about dist file selection and the install process:
• Dist file selection
• Distribution file install process
Dist file selection
When you select the Distribution File Installer, it “parses” through the dist files on your local PC, using
the last source folder selected (Figure 1-26).

Figure 1-26 Parsing dialog in Distribution File Installer

By default, the first time you use the Installer, the “backup” folder under the Niagara software location
(!\backups) is parsed. If that folder does not exist yet (no backups have been made), then the
“cleanDist” folder (!\cleanDist) is parsed instead.
At the bottom of the view, the Cleaning and Backups buttons provide shortcuts to these two
folder areas. If needed, you can also click the Choose Directory button for a “Change Directory”
dialog, and point the Installer to that location.
When parsing completes, a table of the found dist files appears, with the appropriate dist files available
for selection in the table, as shown in Figure 1-27 (using default software location).

Figure 1-27 Available dist files in Distribution File Installer

NiagaraAX-3.6
1-25
Platform Guide
Distribution File Installer Chapter 1 – Niagara platform
Restoring a backup dist April 4, 2011

Dist files that are inappropriate, for example that are for a different target platform or have unmet depen-
dencies, are dimmed—the Install button does not become active if you select such a file. For details
on any dist file, double-click it for a popup, including a list of its dependencies (Figure 1-28).

Figure 1-28 Example details dialog for a dist file, showing dependencies.

To be able to restore a backup dist file, your Workbench installation requires the same versions of
software, including modules, to be available in its “software database.” Therefore, it is recommended that
you make and keep frequent backups as you upgrade JACEs.
Distribution file install process
After proceeding with Finish, the dist installation process appears in a dialog that tracks its progress as
it continues, as shown in Figure 1-29.

Figure 1-29 Distribution File Installer progress dialog

After the distribution file (and modules, if selected) are installed on the JACE platform, the JACE is
rebooted, and the progress dialog indicates complete. You must click the Close button to continue. You
can then reopen a platform connection, perhaps to view output in the Application Director.

Restoring a backup dist

A backup dist includes not only the entire station folder, but all other Niagara configuration that may be
customized for that platform. This allows for a complete replication from the one backup file. You can do
a backup from the Platform Administration view—for details, see “Backup” on page 1-48.
Note: More typically, backups are done from Workbench station connections (must be a station running, that has
the BackupService). In the Nav tree, simply right-click the opened station, and select Backup Station.
To restore a backup, in the Distribution File Installer click the Backups button for the !/backups
folder (if not already there), or if needed, click the Choose Directory button to point to another
backup dist file location.

NiagaraAX-3.6
1-26
Platform Guide
Chapter 1 – Niagara platform Distribution File Installer
April 4, 2011 Restoring a backup dist

The Installer parses through the available dist files, and makes selectable only those files available that are
compatible with the opened JACE platform. When done parsing, available backup dists appear listed, as
shown in Figure 1-30.

Figure 1-30 Backup dist files listed in Distribution File Installer

Double-click any dist for more details in a popup dialog. To restore the backup, click Install to
continue. If the host is already running a station, a dialog appears telling you that it must be stopped, as
previously shown in Figure 1-25 on page 25.
If the dist file contains software modules different from (or in addition to) those already installed in the
remote host, another dialog appears to inform you, as shown in Figure 1-31. Click Next to continue.

Figure 1-31 Software dependencies dialog in Distribution File Installer

As shown in Figure 1-32, whenever restoring a backup, another dialog always asks if you wish to restore
the TCP/IP settings stored in the dist file (as displayed) into the remote host.

Figure 1-32 Restore TCP/IP settings in remote host from dist file

TCP/IP settings contained in the dist file are listed, and by default, the checkbox “Update the remote
host’s TCP/IP settings” is cleared.
• If you leave this cleared, after the dist file installs and host reboots, it retains its current TCP/IP set-
tings. This allows you to use the same dist file on differently addressed hosts, if needed.
• If you check (select) this checkbox, after the dist file installs (and host reboots), it will use the TCP/
IP settings stored in the dist file—meaning the same ones shown in this dialog.
When you click Finish, the distribution file install process begins.

NiagaraAX-3.6
1-27
Platform Guide
Distribution File Installer Chapter 1 – Niagara platform
Downgrading a JACE (Clean Dist) April 4, 2011

Downgrading a JACE (Clean Dist)

Although the NiagaraAX Framework has historically provided smooth upgrades between software
releases, downgrading from one software release to an earlier release can present compatibility problems.
This applies particularly to QNX-based JACEs, as binaries for the (QNX) OS are included in dist files.
However, at times it may be necessary to install an older release onto a JACE, or to restore a JACE to a
known good state. “Clean dist” files became available for this. To downgrade a JACE, or otherwise “wipe
it clean to start over,” you can install a clean distribution file.

Caution Installing a clean dist will wipe the file system and install an appropriate version of Niagara platform
daemon, resetting the unit to a “near factory state.” Only the following settings are preserved:

• TCP/IP settings
• license files
• brand.properties
All other data is removed from the file system, including station bog files, Px files, modules, etc. If the JACE
came with an appliance installed, installing a clean dist will remove that application.
In addition, a clean dist restores the factory-default platform credentials and port (3011).
Therefore before installing a clean dist file, make sure to backup station files plus any other modules on the
JACE you wish to keep. Remember, that a “Station Backup” creates a dist file that (when restored) includes
the same level of software installed at backup time, so instead of (or in addition to) this type of backup, you
may wish to use the Station Copier. For related details, see “Station Copier” on page 1-57.
Note that after installing a clean dist, you must recommission the JACE, using the Commissioning Wizard.

A clean dist file has the suffix “-clean” in its name. A clean dist file for most of the various QNX-based
JACE hardware platforms is located under a !\cleanDist folder—apart from other dist files under
your software database.
Clean dist files appear listed in the Installer with a “WARNING” in the Description column, as shown for
the one highlighted in Figure 1-33.

Figure 1-33 Clean dist file shown selected in the Distribution File Installer

Note: Currently, clean dists support re-installation of AX-3.1 or later, but not AX-3.0 (which uses a different file
system). Note that newer QNX-based JACEs require a minimum release level of NiagaraAX for re-instal-
lation, because of dependencies. For example, a JACE-700 requires AX-3.5 or later, a JACE-x02 Express
(M2M JACE) requires AX-3.4 or later, and a JACE-6 requires of AX-3.2 or later.
As for any dist file, only the appropriate one for the currently opened platform will be selectable. The
following step summary describes the downgrade process for a QNX-based JACE from AX-3.6 to an
earlier release.

NiagaraAX-3.6
1-28
Platform Guide
Chapter 1 – Niagara platform Upgrading a JACE
April 4, 2011 Downgrading a JACE (Clean Dist)

Example JACE downgrade from AX-3.6 to an earlier release

To downgrade a QNX-based JACE from any AX-3.6 build to an earlier release:
Step 1 Before installing a clean dist file, make sure you have backed up the station files plus any other data and
modules on the JACE you wish to keep.
Step 2 Start AX-3.6 Workbench and open a platform connection to the JACE.
Step 3 Open the Distribution File Installer and click Cleaning button for the !/cleanDist directory.
Step 4 Select the appropriate clean dist file for the platform and install.
The file system clean will take a few minutes, then the JACE will automatically reboot. Wait for the reboot
to complete.
Note: After reboot from a clean dist install, the JACE is using default platform credentials and port (3011).
Step 5 To re-install the software versions to the JACE:
1. Use a version of Workbench that runs the same software versions that you want on the JACE, and
use the platform Commissioning Wizard to install the desired software build. For details, refer
to the section “About the Commissioning Wizard” in the JACE NiagaraAX Install & Startup Guide.
2. If you have a backup dist file for the JACE that was made when it had the desired older software
versions, use the Distribution File Installer to install it. See the previous section, “Restoring a backup
dist” on page 1-26.

Upgrading a JACE
Starting in Workbench AX-3.5, you must use the Commissioning Wizard to upgrade a JACE. This
means either a minor upgrade (say from build 3.6.27 to 3.6.29), or a full “version” release upgrade, for
example build 3.5.31 to build 3.6.29.
Note: Any JACE to be upgraded a full point version or more, say from 3.5.nn to 3.6.nn, requires a JACE license
upgrade, purchased before starting the upgrade. Otherwise, the Commissioning Wizard in Workbench AX-
3.5 or later will not perform the upgrade. This prevents the scenario where an upgraded JACE cannot start
its station due to a licensing error.
With a platform connection to any JACE, access the Commissioning Wizard by simply right-clicking on
that platform and selecting it from the menu (Figure 1-34).

Figure 1-34 Commissioning Wizard is right-click option of opened platform

If a JACE upgrade, in the wizard’s opening “selection of steps” you typically deselect most items that were
previously run at the JACE’s initial commissioning time—for example to set the module content filter
level, set date and time, install lexicons, and so on. See Figure 1-35.

NiagaraAX-3.6
1-29
Platform Guide
File Transfer Client Chapter 1 – Niagara platform
Downgrading a JACE (Clean Dist) April 4, 2011

Figure 1-35 Typical upgrade selections for existing JACE (already running a station)

To upgrade a JACE, you do select:

• In the case where the upgrade requires an updated license installed:
“Request or install software licenses”
• In the case where a station install also requires commissioning the JACE (i.e. upgrade):
“Install station from the local computer”
• And always:
“Install/upgrade core software from distribution files”
When you proceed in this manner, the wizard automatically finds and selects all core distributions
needed for the JACE. Then, in the pre-selected “Install/Upgrade” modules step, the wizard provides the
option to also upgrade all out-of-date software modules. A final summary step allows you to review the
upgrade before the wizard executes and performs its operations. For further details, refer to the section
“About the Commissioning Wizard” in the JACE NiagaraAX Install & Startup Guide.
Note: Platform tools prior to Workbench AX-3.5 skipped license checks before JACE upgrades. However, following
an upgrade without an adequate license, a license error could keep the JACE’s station from starting.
In addition, other platform views in Workbench AX-3.5 and later were updated to prevent inappropriate
upgrades—checking first that the necessary license is installed. This affects behavior of not only the
Commissioning Wizard and Distribution File Installer, but also other platform views where “inadvertent”
upgrades may have previously occurred, such as when using the Station Copier or Software Manager views.

File Transfer Client

The File Transfer Client is one of several platform views. It allows you to copy files and/or folders between
your Workbench PC and the remote Niagara platform, as needed. You can also use it to delete files and
folders.
This may be useful if you wish to copy graphics images to a JACE, as one example. Or, you can use it to
copy text files from the !/lib folder of a remote JACE to your local PC, to allow editing. Then you can
use the File Transfer Client to copy the edited version back to the JACE’s !/lib folder. Examples for this
type of usage include lib files system.properties and timezones.xml.
The File Transfer Client provides a two-pane view, as shown in Figure 1-36.

Caution Be careful when using the File Transfer Client, especially when copying files to a target JACE platform, or
whenever using the delete (X) control. Note that in either direction, when transferring a file and an
identically-named file already exists, a popup confirmation dialog appears before the copy. A popup
confirmation dialog also appears before any delete. However, after confirmation there is no “Undo.”

NiagaraAX-3.6
1-30
Platform Guide
Chapter 1 – Niagara platform GPRS Modem Configuration
April 4, 2011 Downgrading a JACE (Clean Dist)

Figure 1-36 File Transfer Client

In the File Transfer Client view, the left pane provides access to local (Workbench PC) files, and the right
pane provides access to files on the remote platform.
Use is straightforward, you simply click navigation controls at the top of each pane to go to the appro-
priate location for source and target. Then you click one or more items on one side (as source) to select
for copying to the other side (target). Then, you click the appropriate transfer arrow.
A dialog appears when all files are transferred, as shown in Figure 1-37.

Figure 1-37 Transfer complete dialog

GPRS Modem Configuration

The GPRS Modem Configuration view (Figure 1-38) is one of several platform views for a QNX-based
JACE. It its used to configure the (wireless) GPRS modem option card that may be installed in the host
JACE controller.
• Starting in AX-3.6 or build 3.5.31 or later, an equivalent view was added to the GprsPlatform-
Service in the station running on the JACE. Note this “Gprs Platform Service Plugin”
(and GprsPlatformService) appears only if the JACE actually has the GPRS modem option card in-
stalled—unlike the platform view. Everything in this section about the GPRS Modem Configu-
ration view also applies to the Gprs Platform Service Plugin view.
• Although the GPRS Modem Configuration view appears if platform-connected to a JACE-4 or
JACE-5 series controller, it does not apply to these platforms—in this case, you can safely ignore it.

NiagaraAX-3.6
1-31
Platform Guide
GPRS Modem Configuration Chapter 1 – Niagara platform
GPRS modem configuration sections April 4, 2011

Figure 1-38 GPRS Modem Configuration view

Note: Refer to the Engineering Notes document “GPRS modem option” for complete details, including a reference
section covering all properties and fields in this platform GPRS Modem Configuration view (again,
this also applies to the equivalent Gprs Platform Service Plugin view).
The following sections provide a few basic GPRS modem configuration details:
• GPRS modem configuration sections
• Status and Runtime Data area

GPRS modem configuration sections

As shown in Figure 1-38, the GPRS Modem Configuration view (or the Gprs Platform Service
Plugin view) has the following configuration sections:
• Modem Configuration
• Provider Configuration
• SMS Configuration
Also, a Status and Runtime Data area near the bottom of the view shows data served up from modem.
Note: Refer to the section “Required platform GPRS setup” in the Engineering Notes document “GPRS modem
option” for details on the most important configuration properties in the sections below.
Modem Configuration
This section of the platform GPRS Modem Configuration view includes properties to enable/disable the
modem, set debug level and monitor cycle time, plus other properties.
Provider Configuration
This section of the platform GPRS Modem Configuration view is to specify access properties to the
wireless provider (corresponding to the SIM card installed in the GPRS modem option), along with
numerous properties related to the PPP (point-to-point) protocol used for GPRS connections.
SMS Configuration
This section of the GPRS Modem Configuration view defines the behavior of the SMS (Short Message
Service) handling portion of the GPRS modem driver. Properties include whether to delete SMS
messages or allow remote commands.

Status and Runtime Data area

The bottom area of the GPRS Modem Configuration view contains debug-level data from the low-level
GPRS modem driver (“GPRSD”) on the JACE.

NiagaraAX-3.6
1-32
Platform Guide
Chapter 1 – Niagara platform Lexicon Installer
April 4, 2011 Status and Runtime Data area

Figure 1-39 Tabs near the bottom of the GPRS Modem Configuration view

This data is found on two separate tabs: GPRS Status and GPRS Runtime Data.
• Information on these tabs updates only when you load or refresh this view.
• Refer to the section “GPRS Status and Runtime Data tabs” in the Engineering Notes document
“GPRS modem option” for reference details on the various data sections below.
GPRS Status
Figure 1-40 GPRS Status tab in GPRS Modem Configuration view (or Gprs Platform Service Plugin)

The GPRS Status tab in the platform GPRS Modem Configuration view (or Gprs Platform
Service Plugin) shows data separated into the following categories:
PPPD Data This section in the GPRS Status tab shows “ppp” (point to point protocol) related data.
Modem Data This section shows data about the installed GPRS modem option card.
SMS Data This section shows data about failed SMS messages.
Monitor Data This section in the GPRS Status tab shows various data, using various terms including ME
(mobile equipment), MS (mobile station), and PLMN (public land mobile network).
GPRS Runtime Data
Figure 1-41 GPRS Runtime Data tab in GPRS Modem Configuration view (or Gprs Platform Service Plugin)

The GPRS Runtime Data tab in the platform GPRS Modem Configuration view (or Gprs
Platform Service Plugin) shows status data for the modem, including its RSSI (Received Signal
Strength Indicator, from 0 to 5), whether Roaming is active, and its unique IMSI, IMEI and SIM values.

Lexicon Installer
The Lexicon Installer is one of several platform views. This view lets you install lexicons from your
Workbench PC to a remote JACE platform, as needed.
Lexicons typically have one of two uses, depending on job location:
• International locations: For non-English language support
• Domestic (U.S.) locations: where you have modified the English (en) lexicon in order to change the

NiagaraAX-3.6
1-33
Platform Guide
License Manager Chapter 1 – Niagara platform
Status and Runtime Data area April 4, 2011

wording used in default labels.

Beforehand, you typically use the Lexicon Editor tool in Workbench to review and edit entries (or
keys) in the individual lexicon files with localized values needed for language support. See the User Guide
sections “About lexicons” and “Lexicon editor” for more details.
When you select Lexicon Installer, any existing lexicons (already installed in that platform) are listed in
the view pane. When you click Install, a “Select Directories” dialog appears for you to select lexicons (on
your Workbench PC) to install in the remote platform, as shown in Figure 1-42.

Figure 1-42 Lexicon Installer, selecting lexicon

When you click OK, the selected lexicon directory is installed in the remote JACE platform. An “Instal-
lation Complete” dialog appears when all files are transferred, as shown in Figure 1-43.

Figure 1-43 Lexicon Installer, lexicon installed

License Manager
The License Manager is one of several platform views. This view lets you install (import) licenses and
certificates to a remote JACE platform, sourced either from your Workbench PC or the Niagara licensing
server. You can also view contents of licenses and certificates, and if desired, delete them from a JACE.
Note: Starting in AX-3.5, a “floating license repository” (FLR) option is available, to permit licensing of
Workbench hosts and Supervisors with a “host-independent” client license. Such licenses are “leased” from
a job’s local FLR server station, running on a specially-licensed host with one or more “license packs”. This
different licensing is explained in an engineering notes document “Floating License Repository”.
Please note that the License Manager, as well as the LicenseService under a station’s PlatformServices, does
not work with floating licenses or license packs, only traditional, host-specific, “node-locked” licenses
typical to JACEs. This NiagaraAX Platform Guide describes working with traditional licenses only.

NiagaraAX-3.6
1-34
Platform Guide
Chapter 1 – Niagara platform License Manager
April 4, 2011 License operations

Figure 1-44 License Manager lists existing licenses and certificates

The License Manager lists any existing licenses and certificates (already installed in that platform), as
shown in Figure 1-44.
If selected, you can also view or delete an existing file (View button is the same as simply double-clicking
item, see Figure 1-45), or save (export) a license file as a “license archive” (.lar) file.
Buttons below each side let you install (import) a new license or certificate file. Typically, license files are
imported from either the online licensing server or from your local license database.
Click a license or certificate to select it, or double-click to view in a dialog, as shown in Figure 1-45.

Figure 1-45 Viewing a license in License Manager

A license and a certificate are each a digitally-signed text file, with differences briefly as follows:
• A license file is unique to a specific Niagara host, and enables a set of vendor features. All NiagaraAX
hosts require a branded “Tridium” license. If third-party modules are installed, one or more addi-
tional licenses may be needed. For details about license file contents, see the section “About Niagar-
aAX license files” on page A-7.
• A certificate file varies by vendor, and matches that vendor to a public key used for encryption. It is
used for verifying the authenticity of license files. All NiagaraAX hosts require a “Tridium” certifi-
cate. If third-party modules are installed, one or more additional certificates may be needed.

Caution Do not delete an existing license or certificate without specific reason, as you will likely render the JACE
inoperable until a proper license or certificate is reinstalled!

For further License Manager details, see the following sections:

• License operations
• About the licensing server
Note: Workbench management of licenses uses a structured “local license database” and utilization of a “license
archive file” format. In addition, a Workbench License Manager tool is available, which does not require a
platform (or station) connection to use. These features are explained in an appendix to this document,
“License Tools and Files”, along with details about the contents (features) of license files.

License operations
Below the license-side of the License Manager (Figure 1-44), these two buttons (commands) are displayed
in addition to View and Delete:

NiagaraAX-3.6
1-35
Platform Guide
License Manager Chapter 1 – Niagara platform
License operations April 4, 2011

• Import — Always available, this provides various options for installing a license file from local files,
from the licensing server, or from your “local license database.”
• Export — Available if you have a license selected, to save locally as a “license archive file.”
Import
If you choose Import from the License Manager, the Import License dialog asks you to select where the
source license is, as shown in Figure 1-46.

Figure 1-46 Import dialog from License Manager

Select one of the following options (depending on scenarios, some may be unavailable, as noted):
Note: See “License Import results” on page 1-37 for details on results after making a selection below.
• Import one or more licenses from files
Always an available option, this provides a Select File dialog in which you can navigate to either
a source license archive (.lar) file or an unzipped license file. When you select a license or license ar-
chive file, an attempt is made to install the license in the host platform.
• Import licenses from the local license database
This option will be unavailable (dim) if this host’s license file is not in your local license database, or
if the license in your local license database already matches the currently installed license. With this
option selected, the license is immediately installed in the remote host platform. See “About the local
license database” on page A-6 for related details.
• Import licenses from the licensing server
Typically, this option is available if your Workbench PC has Internet connectivity. When you select
this option, Workbench silently searches the licensing server and installs the license.
Export
With a license selected in the License Manager, the Export button provides a Save License As...
dialog to save that license file locally on your Workbench PC, as a license archive (.lar) file. See Figure 1-
47. For related details, see “About license archive (.lar) files” on page A-7.

Figure 1-47 Save License As dialog

Note: You can use the License Manager’s Import command to install any exported license archive, or the equiv-
alent Import File command in the Workbench License Manager view of Workbench.

NiagaraAX-3.6
1-36
Platform Guide
Chapter 1 – Niagara platform License Manager
April 4, 2011 About the licensing server

By default, a license archive file is saved in the root of your Niagara release directory. If needed, you can
use the dialog’s navigation controls to specify another target folder or drive. Before saving, you can also
rename the license archive file, to make it more identifiable. For example, instead of: licenses.lar,
you could rename it MyJaceNxs.lar.
After exporting a license, a notification dialog appears in Workbench, as shown in Figure 1-48.

Figure 1-48 Exported license archive notification dialog

License Import results

Depending on the Import option chosen in the License Manager (Figure 1-46) and the success of the
import attempt, after you click OK, one of several dialogs may appear to signal completion, as follows:
• Licensing Complete
The license was successfully added, as shown in Figure 1-49.

Figure 1-49 Licensing Complete dialog

Note: If a station is running on the host platform, this dialog informs you that the host must be
rebooted (if a QNX-based platform) or station restarted (if Win32-based platform) to become
effective, and provides a Yes button to do this now. Or, you can select No and do this manually later.
• Licenses and Certificates Already Current
The license currently installed on the host already matches the source license (whether specifying
any of the license import options). A dialog appears as shown in Figure 1-50.

Figure 1-50 License and Certificates Already Current

• File Not Installed

No appropriate license (by host ID) was found in either the license file or the license archive specified
when importing by file, noted with a dialog similar to Figure 1-51.

Figure 1-51 File Not Installed

• (License Request Form, in browser)

If importing from the license server, and an existing license was not found for this host platform, a
separate window (of your default browser) opens with a license request form, showing the host ID
for this host. See Figure 1-52 on page 38.

About the licensing server

For traditional license files validated against the Tridium certificate, installation can be automated from
Workbench. All such purchased licenses (including JACEs, Supervisor, or Workstation-only) are stored
and available to Workbench through the online licensing server.

NiagaraAX-3.6
1-37
Platform Guide
Platform Administration Chapter 1 – Niagara platform
About the licensing server April 4, 2011

Note: The licensing server is the final license authority—the most current version of any NiagaraAX host
platform’s license is always stored there. In addition to accessing licenses via the licensing server when using
the License Manager, operations in other Workbench views access the licensing server too. Examples
include the Workbench License Manager tool of Workbench, or the Network License Summary view of the
“Licenses” slot of the NiagaraNetwork’s ProvisioningExt.
Providing that your PC currently has Internet connectivity while running a platform connection to any
Niagara host, the License Manager allows you to automatically retrieve and install any needed licenses.
Do this with the Import button, then selecting the license server option. See “Import” on page 1-36 for
details. As a side benefit, your “local license database” is also updated.
Note: If sourcing from the license server while platform-connected to a host that has not yet been assigned a
license by the server (or has a “pending” license), a license request form opens in your computer’s default
browser, as shown in Figure 1-52.

Figure 1-52 Submit License (browser) dialog for unlicensed platform.

This lets you submit a license request to the licensing server that includes the platform’s Niagara Host ID.
In this dialog, be sure to enter your name, email address, and other purchase related information for the
license (Figure 1-52).
If you already have been sent a “License Key”, note that a pending “unbound” license already exists on the
licensing server. In this case, you can enter the license key along with the part number to activate that
license, and make it immediately available.
Upon approval, the license file for this JACE will be emailed back to the entered address. This license will
typically be a zipped “license archive” (have a “.lar” extension)—see “About license archive (.lar) files” on
page A-7. At that point forward, it will also be available for automatic retrieval using the corresponding
“licensing server” operations from various views, such as the License Manager, Workbench License
Manager view, and so forth.

Platform Administration
Platform Administration is one of several platform views. This view provides access to various platform
daemon (and host) settings and summary information. As shown in Figure 1-53, available functions
appear as “buttons” on the left side, and summary information is listed in the right side. Typical use is
when commissioning a new JACE, or when troubleshooting platform or host problems.
Note: During a platform connection, upon first access to Platform Administration, a small delay occurs while
downloading data about that platform’s installed modules. You may briefly see a “Loading Modules”
dialog before the main view (Figure 1-53) appears.

NiagaraAX-3.6
1-38
Platform Guide
Chapter 1 – Niagara platform Platform Administration
April 4, 2011 Types of Platform Administration functions

Figure 1-53 Platform Administration view

Note: Some functions vary by platform, see “About platform differences” on page 1-4.
The following sections provide more details:
• Types of Platform Administration functions
• View Details
• Update Authentication
• Change HTTP Port
• Change Date/Time
• FTP/Telnet
• Change Output Settings
• View Daemon Output
• Set Module Filter
• Backup
• Commissioning
• Reboot

Caution Reboot does exactly what it says, regardless of the opened platform. This is a drastic action to take on any
Niagara host. See “Reboot” on page 1-49 for more details.

Note: A former “Enable/Disable Sedona” button was removed in AX-3.6 and later maintenance builds of AX-3.5
and 3.4. Running a Sedona app directly on a NiagaraAX host (e.g. JACE) is no longer supported. Now, a
Sox (Sedona) connection is required to any Sedona device to use Sedona platform tools like the “Kit
Manager” or “App Manager”. The NiagaraAX platform “Sedona Manager” view is thus obsolete.

Types of Platform Administration functions

The following list summarizes platform administration functions, by button in the view:
• View Details
Provides platform summary data, available to the Windows clipboard. Includes all summary infor-
mation shown in main Platform Administration view, plus installed modules, and so on.
• Update Authentication
For dialogs to change platform login access (user name and password). In QNX-based platforms this
is simple, as there is only one platform administrator. Windows-based platforms offer a choice of a
single (digest) platform account, or use of Windows OS user accounts (basic authentication).
• Change HTTP Port
For a dialog to change the HTTP port for the host’s platform daemon from (default) port 3011 to
some other port.
• Change Date/Time
For a dialog to change the hosts’s current date, time, and time zone, as used by that host’s OS.

NiagaraAX-3.6
1-39
Platform Guide
Platform Administration Chapter 1 – Niagara platform
View Details April 4, 2011

• FTP/Telnet
(QNX-based only) For a dialog to enable/disable both FTP and Telnet access to the JACE, or change
the default port number used by each one.
• Change Output Settings
Provides a dialog to change the log level of different processes that can appear in the platform dae-
mon output.
• View Daemon Output
Provides a window in which you can observe debug messages from the platform daemon in real time,
including the ability to pause.
• Set Module Filter
Provides a dialog to change the module content level of the host. Used very infrequently.
• Backup
Make a complete backup of all configuration on the connected host platform, including all station
files as well as other Niagara configuration.
• Commissioning
One way to launch the Commissioning Wizard, as an alternative to right-clicking on Platform in the
Nav tree.
• Reboot
Provides a method to reboot a JACE platform, which restarts all software including the OS and JVM,
then the platform daemon, then (if so configured in the Application Director) the installed station.
If you click this, a confirmation dialog appears. If you answer yes, the JACE is rebooted and the plat-
form connection drops.

View Details
This selection from the main Platform Administration view lists more platform information than shown
in the main view. Included in the View Details window (Figure 1-54) is all installed modules,
lexicons, licenses, and certificates, in addition to all stations (each station line lists configuration for
autostart and autorestart, plus current status).

Figure 1-54 View Details dialog in Platform Administration

Generally, information in this view is helpful when troubleshooting or asking for technical support.
Buttons include:
• Copy to Clipboard puts all details in the dialog on your PC’s Windows clipboard.
• Close exits the dialog, same as Windows close control (contents copied remain on clipboard).

Update Authentication
This selection from the main Platform Administration view lets you change that platform’s authenti-
cation. This affects the login used to access the host’s platform daemon. Depending on the type of
platform currently opened (QNX-based or Windows-based), update authentication provides different
dialogs, as follows:
• QNX-based platforms: Digest platform authentication
• Win32-based platforms, either:
• Basic platform authentication or

NiagaraAX-3.6
1-40
Platform Guide
Chapter 1 – Niagara platform Platform Administration
April 4, 2011 Update Authentication

• Digest platform authentication

Digest platform authentication
Digest platform authentication is the only method for a QNX-based host or Linux-based Supervisor, and
is an alternative for a Windows-based host. The associated Authentication dialog lets you change the
single platform account credentials (user name and password), as shown in Figure 1-55.
Note: Credentials are case-sensitive. For example, MyJACE4 and MyJace4 are not the same.

Figure 1-55 Platform authentication dialog for digest authentication

The following sections provide more details:

• User Name
• Password
• Usage Notes
User Name In digest authentication, platform user name can be as follows:
• If QNX-based host, a maximum of 14 alphanumeric characters (a - z, A - Z, 0 - 9), where the first
character must be alphabetic, and following characters either alphanumeric or underscore ( _ ).
• If Windows-based host, any number of alphanumeric characters, including hyphens and under-
scores.
Password In digest authentication, platform password for both QNX-based and Win32-based hosts can
be any combination of alphanumeric characters, including common punctuation (! @ # $ %). This
permits a “strong password,” if desired.
Usage Notes In digest authentication, when changing credentials (user name or password, or both),
your new credentials become immediately effective when you click Finish.
If you previously had “Remember these credentials,” selected (the default) in the Authentication login
dialog, the cached credentials are automatically updated. For related details, see the “Credentials
manager” section in the User Guide.
Basic platform authentication
A Win-32 based platform can use either digest or basic (native Windows OS user based) authentication
for Niagara platform access.
• Digest platform authentication provides good protection against password eavesdropping. However,
there is only one level of platform login access, using a single platform user account.
• Basic platform authentication provides integration with existing Windows installations, and pro-
vides two levels of platform access. However, it does not protect against password eavesdropping.
For any Win32-based host, including a JACE-NXS, when you update platform authentication, a dialog
asks you to select one of the two methods, as shown in Figure 1-56.

Figure 1-56 Authentication dialog for Win32 Niagara host

NiagaraAX-3.6
1-41
Platform Guide
Platform Administration Chapter 1 – Niagara platform
Update Authentication April 4, 2011

• If you select digest authentication, upon Next you go to the authentication dialog to set the single
platform login account (Figure 1-55 on page 41). There is no linkage between Windows OS users ac-
counts and the platform administrator.
• If you select basic authentication, you go to a different dialog where you can assign one existing Win-
dows user group to each of the two possible levels of platform access.
Note: Starting in AX-3.5, if the host platform is already configured for digest authentication, and
you change to basic authentication, you first see a login dialog, as shown in Figure 1-57. If already
configured for basic authentication, you go directly to the basic authentication dialog (Figure 1-58).

Figure 1-57 Login dialog when changing from digest authentication to basic authentication

Use your standard Windows login credentials—if the host is on a Windows domain, login using the
credentials you use when logging into that domain. This is necessary to limit the number of possible
domain groups to only those groups in which you are a member. Such groups will be selectable in the
next dialog for Basic Platform Authentication (Figure 1-58).

Figure 1-58 Basic platform authentication dialog, group selection

This basic authentication dialog lets you select one Windows group for each of the two levels of plat-
form access. In addition, the “Stations” checkbox determines certain platform writes from a station.
For more details, see the next sections “Station access” and “Levels of platform access”.
Station access A “Stations” checkbox in the basic authentication dialog (Figure 1-58) allows you to
disable any station user from changing TCP/IP settings, system time, or rebooting the host by accessing
the station’s PlatformServices.
Note: In general, if a Windows-based JACE, you should leave the Stations checkbox enabled, as shown. However,
if an Supervisor (PC) platform, you may wish to clear the Stations checkbox, particularly if the local IT
department has host access concerns.
Levels of platform access Basic platform authentication provides two levels of platform access, which
are determined by a user’s group membership(s). The levels of platform access are:
• User
Platform access at this level allows full use of most Workbench platform views. This includes the
ability to install or delete licenses and stations (including the one running), also to install, re-install,
or upgrade the platform dist file and/or modules, and to start, re-start, or stop a station.
• Admin
Full access. This includes all user-level platform operations, plus the ability to configure host TCP/
IP settings and dialup configuration, change platform authentication, change platform daemon
HTTP port, change host date/time settings, use the File Transfer Client, and reboot the host.

NiagaraAX-3.6
1-42
Platform Guide
Chapter 1 – Niagara platform Platform Administration
April 4, 2011 Change HTTP Port

Note: When platform-connected at the user level (vs. admin), some platform views are read only. This includes
views for Dialup Configuration, TCP/IP Configuration, and User Manager. In addition, some Platform
Administration view buttons are unavailable, as shown in Figure 1-59.

Figure 1-59 Platform Administration view if user-level platform login

Platform access to a remote Windows-based host (JACE-NXT, JACE-NXS) also provides a User Manager
view in which you can manage Windows users and groups local to that host.
Privileged group selections For platform admin level access, you can select from a list of user groups
known to Windows on that host, as shown in Figure 1-60.

Figure 1-60 Group selections include Windows built-in user groups

Groups include Windows “built-in” user groups (include “BUILTIN” or “NT AUTHORITY” prefix), as
well as any locally-defined user groups. If the remote host has been added to a Windows domain, groups
defined in that domain are also listed and available.
Note: Starting in AX-3.5, domain groups are limited to only those in which the login user is a member.
If a user has membership in both assigned Windows user groups, upon successful platform login they
have admin-level platform access.
Note: Default group selections for a Niagara Win32 installation (either Workbench/Supervisor installation or a
factory-shipped JACE-NXS) are as follows:
• User Group — BUILTIN/Users
• Admin Group — BUILTIN/Administrators

Change HTTP Port

This selection from the main Platform Administration view lets you change the HTTP port monitored
by the host’s platform daemon. By default, HTTP port 3011 is monitored for platform client connections.
This is a different port than any used for station (Fox) connections. For more details, see “About a
platform connection” on page 1-2.
If needed, you can change the daemon monitored port to another HTTP port. You may choose to do this
for specific firewall reasons, or perhaps for additional security. As shown in Figure 1-61, you can type in
the new port number in the Port field, which enables the OK button.

NiagaraAX-3.6
1-43
Platform Guide
Platform Administration Chapter 1 – Niagara platform
Change Date/Time April 4, 2011

Caution If there is a firewall on the host (or its network), before changing this port make sure that it will allow traffic
to the new port. For JACE-NXT (or JACE-NXS) related details, see the section “Review the Windows XP
Firewall” in the JACE-NXT NiagaraAX Install and Startup Guide.

Figure 1-61 Update Platform Daemon HTTP Port dialog

When you click OK, the platform daemon restarts, and you lose your platform connection (note this does
not affect the operation of any running station). The platform icon is ghosted in the Nav tree, showing
the new HTTP port number (:n) in parenthesis. Double-click the ghosted platform for the platform login
dialog.
Note: Before closing the host (removing it from the Nav tree), carefully note the new (non-default) port number
you entered. You must always specify that port number whenever reopening this platform. You can check
this port number in a station running on the host, by opening its Config, PlatformServices property sheet.

Change Date/Time
This selection from the main Platform Administration view lets you change the date and time in the
Niagara platform, as well as specify its time zone (Figure 1-62). The Save button becomes available after
you change one or more fields in the dialog, or when you click Use Local.

Figure 1-62 Set System Date/Time dialog

Upon Save, any change is processed by that host’s operating system.

The three dialog fields are as follows:
• Date
Click in a day-month-year position to select, then click up/down controls, or click and type in nu-
merals directly, or click the calendar icon for a popup dialog to select the date from a calendar.
• Time
Always displays in 24-hour format. Click in a hour or minute position to select, then click up/down
controls, or click and type in numerals directly.
• Time Zone
Provides a drop-down selection list of all available time zones in NiagaraAX. Each time zone pro-
vides a text description, and in parenthesis the “hour offset” from UTC (and if daylight savings time
is used) the “offset plus daylight savings.” For example: America/New_York (-5,-4).
For more time zone details, see the appendix “Time Zones and NiagaraAX” on page B-1.
Note: Although rare, in some cases a platform’s OS may not support a particular time zone. This relates only to
a few time zones with daylight savings switch-over. For example, America/Santiago (-4,-3)is not
supported in Windows-based hosts because the start and end daylight savings dates are exact dates, versus
a week number and weekday (e.g. 2nd Sunday).
Upon clicking Save for a time zone not fully supported by the host’s OS, a popup dialog (Figure 1-63)
explains that the platform’s OS time zone was set to UTC (+0) during the update.

NiagaraAX-3.6
1-44
Platform Guide
Chapter 1 – Niagara platform Platform Administration
April 4, 2011 FTP/Telnet

Figure 1-63 OS time zone changed to UTC dialog

Use Local
Typically, if your Workbench PC’s current date/time setting are accurate, you click the “Use Local” to
synchronize the remote host’s date, time, and time zone with your Workbench PC. Upon Save, the
remote host will have the identical settings.
Note: To keep time synchronized across multiple Niagara platforms, configure the NtpPlatformService in the
station running on each platform, as appropriate.

FTP/Telnet
This Platform Administration view selection is available for QNX-based JACE only. (For Windows-based
platforms, you configure/enable FTP and Telnet within local Windows TCP/IP configuration.)
As factory-shipped, a QNX-based JACE has the FTP and Telnet service disabled — this may be best,
especially if the platform is exposed to the public Internet. However, in some cases you may wish to
enable one or both services, perhaps to facilitate debugging.
Note that Telnet access to a QNX-based JACE provides “system shell” access, providing (after login using
platform credentials) the same menu as “serial shell access” to its RS-232 port. For related details, see the
“System shell” section in the JACE NiagaraAX Install & Startup Guide.
You can also change the TCP/IP port used by each service from the “well-known” port to some other
port. However, be sure that any firewalls being used on your network will allow traffic to that port.
Figure 1-64 shows the FTP and Telnet dialog with Telnet enabled (both services showing “well-known”
ports).

Figure 1-64 FTP and Telnet dialog

Change Output Settings

This selection from the main Platform Administration view lets you “tune” the amount and content of
the platform daemon output (View Daemon Output). You can do this by changing the log filter settings
of the various daemon processes (Figure 1-65).

Figure 1-65 Daemon Output Settings dialog for QNX-based JACE

By default, all daemon processes have a “Message” log filter level, and include the following:
• niagarad — Log for the platform daemon (niagarad) process, with “high level” entries like “niagar-
ad starting, “baja home = ...”, “niagarad stopping”.

NiagaraAX-3.6
1-45
Platform Guide
Platform Administration Chapter 1 – Niagara platform
View Daemon Output April 4, 2011

• webserver — Log for HTTP server for incoming platform client connections. Entries are often ge-
neric, before the daemon hands off to the appropriate platform servlet.
• stationregistry — Log for platform daemon management of stations, including startup, shutdown,
and watchdog actions.
• logfilter — Logs changes to daemon log states, meaning it tracks changes made in this dialog.
• dialup — Log for the dialupd servlet created by the platform daemon (not the dialup daemon itself).
It echoes requests on dialup changes, made from the platform Dialup Configuration interface.
• reboot — Log for the reboot servlet, one of the servlets the platform daemon manages.
• updatedaemon — Log for handling Workbench requests for current platform daemon configura-
tion, used mainly by Platform Administration view.
• file — Logs requests made to the platform daemon’s file servlet, used in plaform views like the File
Transfer Client, Commissioning Wizard, Software Manager, Station Copier, and so on. Many differ-
ent things can print on this log, like “request for file xxx”, or “wrote file xxx”.
• qnxosupdate — Log for the OS upgrade servlet created by the platform daemon. Workbench uses
this servlet to upgrade the QNX OS in the host JACE when using the Commissioning Wizard or Dis-
tribution File Installer. Entries here can reflect a problem when updating the QNX OS, such as “os
crc isn’t right”, or “waitpid when launching osupdate command failed”.
• appOut — Log for the thread managing buffers associated with station output, making that output
visible in the Application Director view. Entries may reflect buffer size changes (available in Appli-
cation Director interface), or if a problem occurs streaming the output to Workbench.
Log filter settings
For any item, use the Filter Setting drop-down to select one of the following:
• Trace
Returns all message activity (verbose). This includes all transactional messages, which may result in
too many messages to be useful. Be careful using Trace!
• Message
(Default) Returns informational “MESSAGE”s, plus all “ERROR” and “WARNING” types.
• Warning
Returns only “ERROR” and “WARNING” type messages (no informational “MESSAGE”s).
• Error
Returns only “ERROR” type messages (no “WARNING” or informational “MESSAGE”s).

View Daemon Output

This selection from the main Platform Administration view lets you examine standard output from the
host’s platform daemon (Figure 1-66), in real time. It is available for troubleshooting purposes.
Note: Output is different from the output of a running station, as seen in the Application Director.

Figure 1-66 Example Output for platform daemon

Depending on the log filter settings set in platform administration’s Daemon Output Settings
dialog (Change Output Settings), the activity level in the output window will vary. Output is “non-modal,”
meaning that you can leave this window open and still do other Workbench operations (including change
output settings).
As needed, use the scroll bars to navigate through messages, which will have headings “TRACE,”
“MESSAGE,” “WARNING,” or “ERROR,” depending on message type. Each message includes a
timestamp and a thread id number.
Use the Windows copy shortcut (CTRL + C) to copy text of interest to the Windows clipboard.

NiagaraAX-3.6
1-46
Platform Guide
Chapter 1 – Niagara platform Platform Administration
April 4, 2011 Set Module Filter

Click Pause Output to freeze the output from updating further (no longer in real time). When you do
that, note that the button changes to Load Output. This means that daemon messages are still
collected. When you click Load Output, the display loads the collected messages and continues again
in real time.
Click Clear Output to clear all collected messages from the current daemon output window. This not
a “destructive clear,” as another (or new) daemon output window retains daemon messages.

Set Module Filter

This selection from the Platform Administration view lets you globally change the “module content level”
of the connected platform. This determines how much file space is consumed by installed Niagara
modules.
For any Windows-based host (providing it has hard drive for file storage), you typically want the fullest
possible content level, meaning including all documentation (doc+ui+runtime).
For a QNX-based JACE, with more limited flash-based file storage, you may wish to change its module
content level. Clicking this button produces the Update Module Content Filter dialog (Figure 1-
67).
Note: Typically, you specify the module content level once during initial JACE commissioning, then never change
it again.

Figure 1-67 Update Module Content Filter Level dialog

Module content level is one of the following, from largest to smallest:

• doc+ui+runtime — Typically appropriate only for Windows-based platforms.
• ui+runtime — Appropriate for any JACE that is to run the Web Service. This is typical for any
“standalone” JACE, as well as any JACEs that serve PxPages directly to browser clients.
• runtime — Typically only for a QNX-based JACE not running Web Service (all PxPages served in-
stead by a Supervisor).
Operations from a change in module content level differ according to the “direction” of the change.
Operations from a change in module content level
Depending on how you change the module content filter level, operations on the platform vary:
• If you restrict the content level (say, go from “ui+runtime” to “runtime”), modules already installed
are not automatically re-installed (to reduce storage). You simply click the Finish button to close
the dialog, and platform/station operation is otherwise unaffected. However, if you later re-install
existing modules, or install new modules, the new content filter level is applied—typically with re-
sulting savings in storage space.
Therefore, if “freeing” storage space is the goal when restricting module content, after changing the
content level, you should re-install existing modules. Do this using the Software Manager.
• If you increase the content level (say, from “runtime” to “ui+runtime”), this typically requires mod-
ules to be re-installed in that platform. In this case, the dialog provides a Next button and explains
that this automatically occurs, with the station first stopped as a result, as shown in Figure 1-68. Note
that if a QNX-based platform, any module installation also automatically results in a reboot of that
host platform.

NiagaraAX-3.6
1-47
Platform Guide
Platform Administration Chapter 1 – Niagara platform
Backup April 4, 2011

Figure 1-68 Dialog messages resulting from increasing module content level

Backup
This selection from the Platform Administration view performs a complete backup of the connected
JACE, saved as a dist file on your PC. The backup dist contains the entire station folder plus the specific
NRE config used by that JACE platform, including license(s) and certificate(s). The dist also contains
pointers to the appropriate NRE core, Java VM, modules, and OS. If ever needed, you restore a backup
dist using the platform Distribution File Installer view.
Note: The backup dist file also contains the TCP/IP configuration of the host when it is backed up. When
restoring the backup, you can select to restore these settings, or retain the TCP/IP settings currently in use
by the target host. See “Restoring a backup dist” on page 1-26.
You can perform a backup with a station running on the target host, or when no station is running.
• If the JACE is running station, a confirmation dialog appears to connect to it (Figure 1-69). This rou-
tine uses that station’s BackupService to perform an “online backup.” (If the station is not al-
ready open in Workbench, you must then logon as a station user.)
• If no station is running on the JACE, the platform daemon performs its own “offline backup.”

Figure 1-69 Backup with station running, station connection

After connection to the station (or if no station is running), the File Chooser appears (Figure 1-70)
for you to navigate to the target location to save the backup dist file, and to rename if desired.

Figure 1-70 File Chooser to select target folder and dist file name

NiagaraAX-3.6
1-48
Platform Guide
Chapter 1 – Niagara platform Platform Administration
April 4, 2011 Commissioning

By default, the Backup function automatically creates (if not already present) a backups subdirectory
under your Niagara build directory. The default name for a backup file uses a format of:
backup_stationName_YYMMDD_HHMM.dist
For example, “backup_J403IP98b_071012_1500.dist” for a backup made of station “J403IP98b” on
October 12, 2007 at 3:00 pm.
After you click Save the backup starts.
• If the station is running, a Fox Backup job is performed. A notification popup appears in the lower
right of your display when the backup is done. This job is recorded in the station’s BackupService
and visible in that component’s BackupManager view. Details are also available by accessing the
job in the station’s Job Service Manager.
• If doing an “offline backup” (no station running), the platform daemon provides another progress
dialog during the backup to a dist file, as shown in Figure 1-71.
Upon completion, you can click Close to return to the Platform Administration view, or click De-
tails to see another popup with a log of actions performed in the backup (Figure 1-72).

Figure 1-71 Backup from Platform Administration, no station running

Figure 1-72 Available Details from backup using platform daemon (no station running)

Commissioning
This selection from the Platform Administration view launches the Commissioning Wizard, an ordered
sequence of various steps. Included views are similar to a subset of those listed in “Types of platform
views” on page 1-3.
Typically, you use the Commissioning Wizard for the initial Niagara installation and startup of a JACE
controller. For related details, see “About the Commissioning Wizard” in the JACE NiagaraAX Install &
Startup Guide.
You also use the Commissioning Wizard to upgrade a JACE. For related details, see “Upgrading a JACE”
on page 1-29.
Note: The Commissioning Wizard is intended for a remote JACE only. Please note that this button is unavailable
whenever you are connected to your “localhost” (Supervisor) platform.

Reboot
This selection from the Platform Administration view reboots the host of the connected platform. One
confirmation dialog appears, after which the daemon attempts to stop any running station before issuing
the final reboot (Figure 1-73).

Caution For any Windows-based host, never use reboot in place of restart station (from Application Director),
unless there is a specific need for it! Reboot is a drastic action to take on any Niagara host.

NiagaraAX-3.6
1-49
Platform Guide
Software Manager Chapter 1 – Niagara platform
Reboot April 4, 2011

Figure 1-73 Reboot performs operating system reboot

A reboot restarts the host OS, Java VM, platform daemon, and finally the Niagara station (providing that
it is configured to “Auto-restart,” see “Application Director” on page 1-10).
When the platform reboots, your Workbench platform connection to it is dropped. Depending on the
platform type, it may take from several seconds to a couple of minutes before you can connect again.
Note: Reboot is intended for a remote JACE only. Please note that this button is unavailable whenever you are
connected to your “localhost” (Supervisor) platform.

Software Manager
As shown in Figure 1-74, the Software Manager is one of several platform views. This view lets you
install, uninstall, or simply review all software modules installed in a remote JACE platform. By default,
this view compares the platform’s modules against your “locally available” modules, meaning the most
current Niagara modules in the software database on your Workbench PC.
Note: Starting in AX-3.5, the “scope” of installables in the Software Manager is now modules only—whereas in
Workbench AX-3.4 and earlier, all types of software was shown, including “dist” files for NRE, VM, OS, and
so on. Other changes were also made. See “Software Manager AX-3.5 changes” on page 1-51 for a summary.

Figure 1-74 Software Manager compares remotely installed modules to locally available

The first time you run the Software Manager, it copies modules in your Workbench’s !\modules folder
into the build-named subfolder in your “software database” (!\sw), for example !\sw\3.5.12. Note
this can take several minutes, with a popup similar to the one below.

Figure 1-75 Copying modules into your software database

Note: Copying also occurs whenever you “import” software into your Workbench’s software database.

NiagaraAX-3.6
1-50
Platform Guide
Chapter 1 – Niagara platform Software Manager
April 4, 2011 Software Manager AX-3.5 changes

Then every time you access the Software Manager it rebuilds the modules list, reflecting the latest
revision of your available modules, as well modules currently installed in the opened Niagara platform.
The following sections explain further:
• Software Manager AX-3.5 changes
• About your software database
• Default module listing and layout
• Filtering displayed software
• Software actions

Software Manager AX-3.5 changes

Starting in Workbench AX-3.5, the platform Software Manager changed, summarized as follows:
• Only software modules are shown, versus all “installable parts” including dist files, etc.
• Module statuses of “Out of Date” and “Not Installed” can now include “Requires Commissioning”
too, for example “Out of Date (Requires Commissioning)”. You cannot install such modules without
first commissioning (upgrading) the JACE, using the Commissioning Wizard.
• You can install a new module or modules without rebooting the JACE, with its station kept running.
This does not apply if upgrading (or downgrading) an existing module on the JACE.
• If needed, you can install an earlier version of a module, versus its latest “Available” version—pro-
viding earlier versions are in your Workbench’s software database. See “Right-click option to install
earlier version” on page 1-57.
These changes are described and noted in other sections of this document, and are summarized here only
to assist if you are already familiar with previous Workbench versions.

About your software database

The software database for your Niagara Workbench is located under the Niagara build folder’s “sw”
subdirectory. If Workbench was installed using the “use as an installation tool” option, this
directory will contain a several subdirectories, each named using “version numbers”.
You can see your sw subdirectory structure using either Windows Explorer or the local “My File System”
in Workbench, as shown in Figure 1-76.

Figure 1-76 Software database is everything under sw

Note: Numbers of subdirectories and version number names in your sw subdirectories will be different, this is
only a simple example. Do not manually create or rename subdirectories in this area for proper
operation—instead, let the Software Manager automatically administer this database.

NiagaraAX-3.6
1-51
Platform Guide
Software Manager Chapter 1 – Niagara platform
Default module listing and layout April 4, 2011

Using the Figure 1-76 example, this sw software database has many versioned subdirectories, a few of
which are described in this example as follows:
• 1.0.44 — Reflects version of Sedona-related modules. Contains 4 module files.
• 1.6.0.2 — Reflects version of the Sun JVM for Win32 hosts. Contains 1 "sun-jre" dist file.
• 2.3.29 — Reflects version of QNX operating system. Contains 12 different qnx dist files.
• 2.3.20080711 — Reflects version of the IBM J9 JVM used on QNX-based hosts. Contains an
“ibm-j9” dist file.
• 3.4.51 — Reflects a previous Niagara release, by build number. Contains 358 files, including mod-
ule files as well as dist files for nre “core” and “config”. Likely this was created in a software import.
• 3.5.11 — Reflects the current Niagara release, by build number. Contains numerous Niagara nre
“config” and “core” dist files, installed by the “installation tool” Workbench installation option. Also,
after the Software Manager is first used, contents of the build’s modules directory (module .jars)
are automatically copied here too.
• inbox — Provides a means for you to copy any installable file here, and have the Software Manager
automatically create a proper “versioned” subdirectory for it. Or, if the correct subdirectory already
exists, the Software Manager will copy the inbox file(s) there.
As an equivalent to the inbox feature, you can use the Import button at the bottom of the Software
Manager to add to your Workbench software database. For details, see “Software Import” on page 1-54.
When you add different-versioned installable files, the number of different subdirectories under your sw
directory will continue to increase. By default, the Software Manager displays only the most recent
version of any module as the “Avail. Version”.
Note: Starting in AX-3.5, for any module listed in the Software Manager, you can select to install an older version,
if available in your software database. See “Right-click option to install earlier version” on page 1-57.
Note that older software files (modules, dists) are also useful in your software database when restoring a
backup dist for a JACE, if the backup was made using a previous software release. You use the platform
Distribution File Installer to restore a backup.

Default module listing and layout

By default, the Software Manager lists all the JACE’s out-of-date modules at the top of the table, then
uninstalled modules, and lastly up-to-date modules (sorted alphabetically); see Figure 1-77.

Figure 1-77 Software Manager default listing out-of-date, then uninstalled modules

• Out of Date modules are older than what you have in your PC software database.
• Not Installed modules do not exist on the platform, but are in your PC software database.
• Up to Date modules are the same (or possibly newer) than that in your PC software database.
Note: Starting in AX-3.5, both “out of date” and “not installed” modules may also show a “Requires
Commissioning” status. This indicates you must upgrade the JACE first, before installing that module
version. For more details, see status descriptions for Software Manager table columns below.
As needed, you can scroll down the table or click on headers of table columns to resort alphabetically.
Software Manager table columns
The Software Manager lists modules using four columns, from left-to-right labeled as follows:
• File — File name of locally available module file, or blank if the module is on the remote host only.
• Installed Version — Version of the module installed in the remote host, or blank if not installed.
For related details, see “About module versions” in the User Guide.

NiagaraAX-3.6
1-52
Platform Guide
Chapter 1 – Niagara platform Software Manager
April 4, 2011 Default module listing and layout

• Avail. Version — Latest version of locally available module, or blank if the software is on the remote
host only.
• <unlabeled> — Status of the module in the remote JACE platform. For each module, status is one of
the following:
• Not Installed — Module is not in remote platform, but is available locally.
Blue text is used for this status.
• Not Installed (Requires Commissioning)— Module is not in remote platform, but is available
locally. Blue text is also used for this status.
Dependencies prevent you from installing it, unless you first upgrade the JACE, using the Com-
missioning Wizard. See “Upgrading a JACE” on page 1-29.
• Up to Date — Module is installed in the remote platform, and is equal to (or higher) than locally
available module version.
• Out of Date — Module is installed in remote platform, and is older than your local version.
Red text is used for this status.
• Out of Date (Requires Commissioning)— Module is installed in remote platform, and is older
than your local version shown. Red text is also used for this status.
Dependencies prevent you from installing it, unless you first upgrade the JACE, using the Com-
missioning Wizard. See “Upgrading a JACE” on page 1-29.
• Not Available Locally — Module installed in remote platform is not in your software database.
• Cannot Install — Local module is unreadable or has a bad manifest; you cannot install it.
• Bad Target — Remotely installed module is unreadable or has a bad manifest, and is therefore
unusable by a station. Software in this state should probably be fixed, since it could cause the
station to not work correctly.
• Downgrade to <version> — Remotely installed software is intended to be replaced with a mod-
ule having a lower version.
• Install <version> — Module is intended to be installed; it does not currently exist on the remote
platform.
• Re-Install <version> — Remotely installed module is intended to be replaced with a module
having a the same version.
• Uninstall <version> — Remotely installed module is intended to be uninstalled.
• Upgrade to <version> — Remotely installed module is intended to be replaced with a module
having a higher version.
Note: “Intended” status values like “Install <version>” reflect un-committed actions made during
your Software Manager session. Blue text is used to list these statuses.
You can also view software details about any item in the table. In addition, you can filter (reduce) the
number of software items listed, based on text included in file name or the softwares’ status values. See
“Filtering displayed software” on page 1-54 for more details.
Software Details
From the Software Manager, double-click any module to see a popup dialog with details (Figure 1-78).

Figure 1-78 Software Details dialog from Software Manager

NiagaraAX-3.6
1-53
Platform Guide
Software Manager Chapter 1 – Niagara platform
Filtering displayed software April 4, 2011

Details include a brief module description, comparisons between installed and available module, module
file and size, and whatever module dependencies exist, by part names. Dependencies are listed for both
cases: what software is required by this module, plus software dependent on this module.
Note: Essentially, dependency details are for information only. When installing modules from the Software
Manager, all dependent modules are automatically included when you select a module to install.

Filtering displayed software

By default, the Software Manager lists all remotely installed and locally available modules, which can
produce a very large table. A filter control provides an Edit Filter dialog (Figure 1-79), in which you select
items for listing, thereby filtering undesired items.

Figure 1-79 Filter control and dialog to limit displayed modules

You can use either Filter by status or Filter by name, or a combination of the two.
Filter by status
Modules with an “Out of Date” or “Out of Date (Requires Commissioning)” status always appear in the
Software Manager. So do any with uncommitted (intended) status values, such as “Install,” “Uninstall,”
and so on.
When you enable filter by status, you can check other statuses to include (or clear to omit) the listing of
associated items in the table, as follows:
• Not Installed — Modules on your PC that can be installed, but are not in the remote platform.
• Not Installed (Requires Commissioning) — Modules on your PC, but not in the remote platform.
The remote JACE must be upgraded (using Commissioning Wizard) first.
• Up to Date — Modules on your PC and in the remote platform, where the software is not older.
• Cannot Install — Local module is unreadable or has bad manifest, you cannot install it.
• Bad File — Remote module is unreadable or has bad manifest.
Note: With status filtering enabled, you can also simply “check all” and “clear all checked.”
• If all status items are cleared, only “Out of Date” and uncommitted status modules appear.
• If all status items are checked, the display is similar to disabled status filtering, except “non-module”
items are not listed.
Filter by name
Name filtering lets you include or exclude items based on character string portion of module File name.
When enabled (checked), you can type in a string of characters, and then check one of the following:
• Show rows with names containing text — Only items with file name containing this string.
• Show rows with names which do not contain text — Only items with file name that does not contain
this string.
This feature can be useful to filter many modules with common name characters, for example “lon” or
“doc” part-named modules.

Software Import
As shown in Figure 1-80, an Import button at the bottom of the Software Manager provides two menu
choices for you to add new (or earlier) installable software files (module .jars, .dists) in your software
database.
Note: Also see the next section, “Import vs. copy into modules”.

NiagaraAX-3.6
1-54
Platform Guide
Chapter 1 – Niagara platform Software Manager
April 4, 2011 Software actions

Figure 1-80 Import choices to bring in file(s) or entire folders

The two import options are:

• Import software from files
This produces the standard File Chooser dialog, in which you navigate to the proper location
and select one or more software files for import.
• Import software from directory
This produces the standard Directory Chooser dialog, in which you navigate to the proper lo-
cation and select a directory, for inclusion of any contained software files. For example, you might
do this for an earlier installed build of Niagara, selecting its “sw” folder, or a portion thereof.
Upon import, the software list is again rebuilt by the Software Manager (popup dialogs appear while
software files are copied). Afterwards, any modules that are newer-versioned, or that did not previously
exist, will now be represented by default in the software table.
Starting in Workbench AX-3.5, if imported modules are earlier versions, they are also available for instal-
lation in the Software Manager. See “Right-click option to install earlier version” on page 1-57.
Import vs. copy into modules
When receiving updated or new module jar files (say sent from Systems Engineering or downloaded from
Niagara Central), you have two basic options when copying them to your Workbench PC, as follows:
1. Copy directly into your !\modules directory. This makes the module(s) available in your
Workbench environment, and also available to install in other remote platforms (when the installer
runs, the module(s) are also copied into your software database, available for installation). This is the
typical choice.
2. Copy into your !\sw\inbox directory (or, use the equivalent “Software Import” feature in the
Software Manager). In this case, the module(s) are not used in your Workbench environment, but
are available in your software database for installation in remote platforms.
This would be the choice where you want to keep using a newer (or older) version of the received
module(s) in your Workbench environment. A scenario that fits here, is if you received older ver-
sions of modules, perhaps needed to restore an older backup dist file in a certain remote platform.

Software actions
As needed, from the Software Manager you can take actions on modules, such as install, uninstall,
upgrade, downgrade, and re-install. You flag intended actions on software items using action buttons near
the bottom of the manager’s view pane, as shown in Figure 1-81. Action buttons become enabled when
you have one or more items selected.

Figure 1-81 Software Manager action buttons

Included in action buttons are Reset and Commit. When you reset, all flagged module changes (since
the last commit) are cleared. Commit is how you actually launch the flagged changes.
When you Commit, one of these two things happens:
• If upgrading (or downgrading) modules, a confirmation popup dialog appears, telling you the host
must be rebooted and/or station stopped. Then, after the software operation completes, the host is
rebooted (if a QNX-based JACE), or if a Windows-based JACE, its station is restarted.
Note: Before committing, make sure that controlled equipment that might be adversely affected by
the JACE’s station stopping and then host rebooting (from software changes) is put in a manually
controlled state.
• Starting in Workbench AX-3.5, if only installing new module(s), meaning modules not previously in-
stalled, the station continues running on that platform. The software is immediately installed.
The following action buttons are explained in further detail:

NiagaraAX-3.6
1-55
Platform Guide
Software Manager Chapter 1 – Niagara platform
Software actions April 4, 2011

• Upgrade All Out of Date

• Install
• Uninstall
• Re-Install, Upgrade, Downgrade
• Commit and Reset
Note: Also see “Right-click option to install earlier version” on page 1-57.
Upgrade All Out of Date
Whenever one or more local modules are newer than in the opened JACE platform, the Software
Manager enables an Upgrade All Out of Date button. This allows you to flag all out-of-date
modules to be upgraded. Unlike other action buttons, specific item(s) do not need selection first.
When you click it, the status of all out-of-date modules changes to “Upgrade to <version>,” and the button
becomes unavailable. If needed, you can still make additional changes, such as choosing additional
modules to install.
Install
This button is available in the Software Manager when you have one or more modules selected with a
status of “Not Installed.” When you click it, the status of the selected modules changes to “Install
<version>,” and the button changes to Cancel Install.
Note: If a selected module has dependencies on modules not already installed (or also flagged to install), a dialog
appears explaining additional software is needed, as shown in Figure 1-82. After you click OK from this
dialog, the additional modules are flagged, the status of all affected modules changes to “Install <version>,”
and the button changes to Cancel Install.

Figure 1-82 Installing Additional Software dialog

Uninstall
This button is available in the Software Manager when you have one or more installed modules selected
(status of either “Up to Date” or “Out of Date”). If the selected module(s) are not dependencies of other
installed modules, when you click Uninstall the module(s) status changes to “Uninstall <version>,” and
the button changes to Cancel Uninstall.
Note: If other installed modules have dependencies on one or more modules you selected, a dialog appears
explaining the uninstall cannot occur, as shown in Figure 1-83. You can then decide if you want to reflag
another uninstall, selecting also all modules that are dependent.

Figure 1-83 Cannot Uninstall dialog

Re-Install, Upgrade, Downgrade

In the Software Manager, when you have one or more installed software items selected, the “install”
button changes to show one of these options.
• Re-Install appears if the installed item is the same version as your locally available one.
• Upgrade appears if the installed item is an earlier version than your locally available one.
• Downgrade appears if the installed item is an newer version than your locally available one.
When you click this button, the software’s status correspondingly changes to either “Re-Install
<version>”, “Upgrade <version>”, or “Downgrade <version>”, and the button changes to
Cancel <action>, for example: Cancel Re-Install.

NiagaraAX-3.6
1-56
Platform Guide
Chapter 1 – Niagara platform Station Copier
April 4, 2011 Right-click option to install earlier version

Commit and Reset

In the Software Manager, when you have one or more pending actions in place on software items, the
Commit button is available. This is how you initiate the software action.
At any time before you commit, you can also click the Reset button. This removes all pending actions
in place on software items, and makes the Commit button unavailable again.

Right-click option to install earlier version

In addition to button-based Software actions in the Software Manager, you can also select an earlier
version of a module to install, providing one is in your Workbench’s software database.

Figure 1-84 Right-click option to install earlier module version in Software Manager

Simply right-click a module row, and from the shortcut menu select any “Install vendor 3.n.nn”
items shown (Figure 1-84). Note if a “downgrade”, a host reboot/station restart will result after you
commit. For related details, see “About your software database” on page 1-51.

Station Copier
The Station Copier is one of several platform views. You use it to install a station in a remote platform,
as well as make a local backup copy of a remote station (copy its station database and files to your PC).
You can also rename and delete stations, either locally or remotely.
Note: Starting in Workbench AX-3.5, new Station Copier changes became effective. See “Station Copier depen-
dencies check” on page 1-58 for related details.
As always, this platform view is not seen when opening a local platform connection at your Supervisor
computer—usage has always been intended for remote JACE hosts only.

Figure 1-85 Station Copier view

As shown in Figure 1-85, this view is split into two main areas:
• Local stations on your Workbench computer (left side)
• Remote station on the opened JACE platform (right side)
Note: By default, contents of the !\stations folder is shown on the Workbench (left) side. If you have station
folders located elsewhere, click the folder icon for a “Change Directory” dialog, and point the Station Copier
to that location. That alternate location is remembered the next time you access the Station Copier.
The following sections provide more details:
• Station copy direction
• Station Copier dependencies check
• Station Transfer Wizard
• Renaming stations
• Deleting stations

NiagaraAX-3.6
1-57
Platform Guide
Station Copier Chapter 1 – Niagara platform
Station copy direction April 4, 2011

Station copy direction

The copier works in either direction. In other words, click a station on one side (to copy to the other side).
When you click a station, the station is selected (highlighted) and the appropriate Copy button, by
direction, becomes enabled to clarify the source and target. See Figure 1-86.

Figure 1-86 Copy direction by station side selection

To perform the following station operations, you:

• Click in left side for a copy from local-to-remote.
Do this to install a station in a JACE. This is called “installing” in remaining document subsections.
• Click in right side for a copy from remote-to-local.
Do this to make a local backup copy of a station, saved to your Workbench computer. This is de-
scribed as a “backup” in the following document subsections.
When you click a Copy button, a Station Transfer Wizard guides you the rest of the way.
Note: Starting in Workbench AX-3.5, dependency checks may prevent the installation of a selected station—
where the Station Transfer Wizard does not start. See the next section “Station Copier dependencies check”
for more details.

Station Copier dependencies check

Starting in Workbench AX-3.5, the Station Copier behavior changed whenever installing a station, and
the target JACE platform does not already have all modules installed that are required by that station.
Changes are summarized as follows:
• If any module needed by the station has a dependency that requires the JACE to be commissioned
(upgrade core Niagara software or QNX OS), the station install immediately stops, upon station se-
lection. (Steps in the Station Transfer Wizard do not appear.) A dialog explains the JACE needs com-
missioning, and provides the option to start the Commissioning Wizard. See Figure 1-87.

Figure 1-87 Selected station cannot be installed without first commissioning the JACE.

Click Yes to start the Commissioning Wizard, or No to simply return to the Station Copier.
Two different examples of when this might occur:
• You have a platform connection to a JACE running AX-3.4. The station you are trying to copy
(install) has been engineered with “export tags”, using the exportTags module introduced in
AX-3.5. The exportTags module has 3.5 dependencies on baja and other modules.
In this case, providing you bought a 3.5 license for this JACE, you could click Yes to start the
Commissioning Wizard, then upgrade the JACE—selecting to also install the same station.
• You are trying to install a station in a new, uncommissioned “out-of-the-box” JACE.
Despite documentation to first commission any new JACE using the platform Commissioning
Wizard, this continues to occasionally come up. For complete details, see the JACE NiagaraAX
Install and Startup Guide.
• If all modules needed by the station are found on your Workbench computer, the Station Transfer
Wizard starts normally. However, upon reaching the “Modules step”, in some cases you may see a
caution. For further details see “Modules step” on page 1-62.

NiagaraAX-3.6
1-58
Platform Guide
Chapter 1 – Niagara platform Station Copier
April 4, 2011 Station Transfer Wizard

Station Transfer Wizard

This wizard assists with any station copy (installing or backing up) by presenting a number of steps. The
exact steps vary by the direction of copy, as well your selections in wizard step dialogs. In each step, click
Next to advance to the next step. As needed, click Back to return to a previous step and make changes,
or click Cancel to exit from the wizard (no station copy performed).
Note: Use Cancel if you need to select a different station to copy; this reruns the wizard.
The wizard’s Finish button is enabled only in the final step. When you click Finish, the related opera-
tions begin, and you see progress updates in the wizard’s Transferring station dialog. When complete, you
click Close in that dialog to exit the wizard.
The following sections describe all possible steps in the Station Transfer Wizard:
• Name step
• Delete step
• Content step
• Disposition step
• Station settings step
• Details step
• Modules step
• Stop station step
• Review step
Note: In the unlikely case where the source station config.bog file is currently in use (“locked”), the wizard
opens in a state where you must Cancel to exit (no other steps are given).
• If installing a station, the source config.bog is locked if it contains unsaved changes (it is being
edited elsewhere in Workbench). After saving changes, you can try the copy again.
• If backing up a station, the source config.bog is locked if currently in process of being saved. You
can retry the copy later.
Name step
The first step in the Station Transfer Wizard is to confirm the name (or type a new name) for
the copied station directory.

Figure 1-88 Station Transfer Wizard dialog, name step

Default name is the station directory being copied. If you rename the station, it will be identical to the
source (copied) station in every way except name of its station directory.
Delete step
Note: This step is skipped for any station backup, or if a station install in either of these cases:
• No existing station exists.
• The existing station is named the same as the one you are installing.
This step occurs because all JACE platforms have a support limit of one (1) installed station. The delete
step simply cautions you that the existing station will be deleted (Figure 1-89).

Figure 1-89 Station Transfer Wizard dialog, delete step

NiagaraAX-3.6
1-59
Platform Guide
Station Copier Chapter 1 – Niagara platform
Station Transfer Wizard April 4, 2011

Note: The entire remote station directory (all subdirectories and files) is deleted when the station install starts.
If unsure, it may be best to Cancel, then backup the remote JACE station first.
The next step is the content step.
Content step
Note: This wizard step is skipped if the source station consists of only a config.bog file.
After the name step and possibly delete step, the wizard asks you to select what station files to copy, with
the default selection being “all” files and folders under that station directory (Figure 1-90).

Figure 1-90 Station Transfer Wizard dialog, content step

The three possible selections are:

• Copy files from selected directories (not shown if source station has no subdirectories).
If you select this, a later “details step” allows you to select the source subdirectories.
• Copy every file in the station directory and its subdirectories.
• Copy only the “config.bog” station database file.
The next step is the disposition step.
Disposition step
Note: This wizard step occurs only when an identically-named target station already exists.
If the target station already exists, a disposition step asks what is to be done with it (Figure 1-91).

Figure 1-91 Station Transfer Wizard dialog, disposition step

The two possible selections are:

• Delete existing station directory before starting the copy
• Overwrite existing station files with new files, while leaving other files intact.
If you previously selected “copy everything” from the content step, the default pre-selection is the first
(delete existing station directory). Otherwise, the second selection (overwrite) is pre-selected.
The next step is the station settings step.
Station settings step
Note: This wizard step is skipped for any station backup.
This step specifies the station’s Auto-Start setting (Figure 1-92).

NiagaraAX-3.6
1-60
Platform Guide
Chapter 1 – Niagara platform Station Copier
April 4, 2011 Station Transfer Wizard

Figure 1-92 Station Transfer Wizard dialog, station settings

Two items are listed:

• START AFTER INSTALL: Start the station immediately after it is copied.
• AUTO-START: Start the station every time the platform daemon starts.
Auto-start is one of two station settings for any station, as specified in the Application Director view
by using start checkboxes.
Depending on the target platform, default settings in this step vary:
• If a Win-32 based JACE (JACE-NXS, AX SoftJACE)
• START AFTER INSTALL: Enabled.
• AUTO-START: Enabled.
• If a QNX-based JACE.
• START AFTER INSTALL: shown cleared and unavailable (dimmed). A QNX-based JACE re-
quires a reboot for the station to start. After clicking Next, a separate dialog asks if the remote
host should be rebooted (Figure 1-93).
• AUTO-START: Enabled.

Figure 1-93 Reboot remote host after copying the station

Typically, you enable all settings and continue to the next step, either the details step or modules step.
Details step
Note: This wizard step is skipped unless you selected “copy selected directories” in the content step.
This step provides a tree (Figure 1-94) to select station subdirectories (folders) to include in the copy. By
default, all selectable folders are both expanded and selected, while unselectable folders are not (note that
if present, a station’s alarm and history folders are unselectable).

Figure 1-94 Station Transfer Wizard dialog, details step

For any selectable folder, click to toggle it as either selected (with X) or unselected (no X).

NiagaraAX-3.6
1-61
Platform Guide
Station Copier Chapter 1 – Niagara platform
Station Transfer Wizard April 4, 2011

Modules step
Note: This wizard step is skipped if a station backup, or if all modules required by the station being installed are
already in the remote JACE platform. In this case, you see either the stop station step or review step instead.
This step occurs if the target JACE platform is missing one or more of the modules required by the station
being copied (installed). It lists the missing modules/versions that will be installed during the station copy
operation. If included, this is the final step before the station copy process starts.
Note: Starting in Workbench AX-3.5, dependencies of the missing modules are compared against the software
that is already installed in the target JACE platform. The Station Copier no longer arbitrarily installs the
most recent (available) versions of missing modules. Previously, due to continuing dependencies, this could
lead to additional NiagaraAX core software also being installed, i.e. an “inadvertent upgrade”. Sometimes,
this led to other issues like insufficient licensing.
Now, the Station Copier now looks for versions of those missing modules in your Workbench software
database that can be installed without re-commissioning the JACE, by default.
There are two possible results when the wizard reaches this step:
• Station can be installed with most current modules
• Station can be installed with “out of date” modules
In either case, to continue you click either:
• Finish — Start the local-to-remote copy, including installation of the listed modules. Progress up-
dates appear in a Transferring station dialog.
• Cancel — Exit from the Station Transfer Wizard, then either select another station to install, or if
a JACE upgrade is possible (and you have purchased an upgrade license for it) run the Commission-
ing Wizard to upgrade the JACE, including the installation of a station.
Station can be installed with most current modules If all missing modules can be installed using the
most current versions, they list without any warning, as shown in Figure 1-95.

Figure 1-95 Station install example, all missing modules are most current versions

Station can be installed with “out of date” modules If any module to be installed is not the most
current version, you have the option to cancel the station install. A dialog explains that you can use the
Commissioning Wizard to upgrade the JACE. An example of this dialog is shown in Figure 1-96.

Figure 1-96 Station install example, one or more missing modules not current versions

In the example above, a station using the BACnet driver is being installed in AX-3.4 JACE which does not
already have BACnet-related modules installed (bacnet, platBacnet, platMstp). Here, the Workbench
AX-3.5 software database includes some 3.4 modules—likely “imported” using the Software Manager.

NiagaraAX-3.6
1-62
Platform Guide
Chapter 1 – Niagara platform Station Copier
April 4, 2011 Station Transfer Wizard

For related details, see Software Manager topics “About your software database” on page 1-51 and
“Software Import” on page 1-54. Also see “Upgrading a JACE” on page 1-29.
Stop station step
You can see this wizard step in any of these scenarios:
• You are copying the station running in a remote platform to your local computer, and you selected
either “copy files from selected directories” or “copy only the config.bog station database file” in the
previous content step. Note this step is skipped if you elect to “copy every file in the station directory
and its subdirectories”. However, a station save occurs before the station copy transfer starts.
• If installing a “same-named” station.
This step reminds you that the station must be stopped while it is copied (Figure 1-97).

Figure 1-97 Station Transfer Wizard dialog, stop station step

Click Next to go to the review step.

Review step
Note: This wizard step is skipped when installing a station where additional modules are required. (Instead, the
modules step provides the Finish button.)
This step provides a summary of choices from previous steps, and a Finish button to begin the station
copy process. As shown in Figure 1-98, if you selected only specific station subdirectories to copy (from
the details step), they are listed.

Figure 1-98 Station Transfer Wizard dialog, review step

If needed, click Back to make changes, or click Finish to begin the copy process and observe progress
in the Transferring station dialog.
Transferring station
After clicking Finish in the wizard’s modules step or review step, the station copy process begins and
updates appear in a this dialog, as shown in Figure 1-99.

NiagaraAX-3.6
1-63
Platform Guide
Station Copier Chapter 1 – Niagara platform
Renaming stations April 4, 2011

Figure 1-99 Station Transfer Wizard, Transferring station (copy) process

Depending on the type of copy, the following operations may be included in this process:
• If installing a station (copy local-to-remote):
• Stop all stations — whenever modules require to be installed.
• Stop one station — any JACE where same station is being reinstalled.
• Delete station(s) — if you chose to delete station in the disposition step, or if a station needs to
be deleted to stay under maximum number of stations (only one for any JACE platform)
• Transfer files — includes station and module files (actual copy portion).
• Start station — if a station had required to be stopped (module installation), or if you chose to
start the station in the station settings step. Note that if a QNX-based platform, the process will
finish with a host reboot.
• If backing up a station (copy remote-to-local):
• Save station — whenever remote station is currently running.
• Transfer files — includes station and module files (actual copy portion).
Note: A popup explaining that the existing station must be stopped may appear for a few seconds. Following, and
during execution of the various operations, a Cancel button is available. If you click Cancel before all
operations complete, the installation (or backup) is not valid.
After all operations are finished, a Close button is available and the last update in the dialog is
“Transfer complete.” Click Close to exit the wizard.
By default, after installing a station, the wizard exits with a popup (Figure 1-100) asking if you wish to
switch to the Application Director platform view. Because it is a good idea to observe a station’s output
upon first startup, you typically select Yes.

Figure 1-100 Switch to Application Director popup

Note: To always automatically switch to the Application Director after installing a station, click the checkbox to
“Don’t ask again” before selecting Yes. Then, you do not see this popup again.

Renaming stations
The Station Copier lets you rename any station, either on your local PC (left side) or a remote platform
(right side). A Rename dialog (Figure 1-101) appears when you select a station and click Rename.

Figure 1-101 Rename station dialog

NiagaraAX-3.6
1-64
Platform Guide
Chapter 1 – Niagara platform Station Copier
April 4, 2011 Deleting stations

Note: Be careful when renaming stations, as there is no undo. Furthermore, please note the following:
• Any running station that is renamed must first be stopped—a confirmation dialog will inform you of
this after you enter the new station name and click OK. In the case of a QNX-based JACE, this also
results in a host reboot.
• If a renamed running station is already included in the NiagaraNetwork of other stations, its corre-
sponding NiagaraStation component will remain “down” until renamed to match the new name.
Thus, all child components (Niagara proxy points and so on) will also be down until this is done. In
addition, other unforeseen consequences may result from changing the name of a station that has
already been integrated into other stations.
Therefore, station renames are best done on local (left side) stations, or when initially configuring a
job site network, such as when installing (copying) a station.

Deleting stations
The Station Copier lets you delete any station, either on your local PC (left side) or a remote platform
(right side). A confirmation dialog (Figure 1-102) appears when you select a station and click Delete.

Figure 1-102 Confirm delete station dialog

Note: Be careful when deleting stations, as there is no undo. Furthermore, please note the following:
• The entire selected station directory gets deleted, including all subdirectories and file contents.
• Special notification does not occur if you choose to delete a running station (you may briefly see a
“stop station” popup, with opportunity to Abort).
• Also in general (as a precaution), before deleting a remote station, it is generally recommended to
make a backup copy first. If desired, when backing up you can rename it using some “temp” conven-
tion to flag it for later housekeeping.

NiagaraAX-3.6
1-65
Platform Guide
TCP/IP Configuration Chapter 1 – Niagara platform
TCP/IP changes in AX-3.6 April 4, 2011

TCP/IP Configuration
TCP/IP Configuration is one of several platform views. Typically, you use it to initially configure a remote
JACE’s TCP/IP settings. Some earlier JACE models have only a single Ethernet port (interface) for config-
uring TCP/IP, but if equipped with two Ethernet ports, both interfaces are accessible (Figure 1-103).

Figure 1-103 TCP/IP Configuration shows available Ethernet interface(s)

If connected to your localhost (PC) platform, this view also provides access to your PC’s Windows TCP/
IP settings. However, you typically use the Windows Control Panel for making these changes.
Note: Regardless of platform connection, if you make any changes in this view, a reboot of that platform is
necessary before those changes are effective. A popup dialog appears when you click Save (Figure 1-104),
asking if you wish the platform daemon to reboot that host now. When making multiple changes, wait until
entering all changes before you click Save, Yes.

Figure 1-104 Reboot confirmation dialog from TCP/IP configuration change

More details on the TCP/IP Configuration view are in the following sections:
• TCP/IP changes in AX-3.6 (IPv6 support for “Hotspot JACE” vs. “J9 JACE”)
• TCP/IP Host fields
• TCP/IP DNS fields (host-level for QNX-based platforms only)
• TCP/IP Interface fields

TCP/IP changes in AX-3.6

IPv6 support
Starting in AX-3.6, IPv6 support is available in some of the newer QNX-based JACE platforms, providing
that they are running AX-3.6 or later. Starting in AX-3.6, these same JACE platforms also use the Sun
Hotspot JVM (Java virtual machine), versus the IBM J9 JVM used in AX-3.5 and earlier.

NiagaraAX-3.6
1-66
Platform Guide
Chapter 1 – Niagara platform TCP/IP Configuration
April 4, 2011 TCP/IP Host fields

Thus, there are now two “subgroups” of QNX-based controllers, sometimes referred to as follows:
• Hotspot JACE
Includes the JACE-7 (JACE-700) and JACE-6 and JACE-602 Express (both NPM6-based) control-
lers, providing they are running AX-3.6 or later. These models support IPv6 in addition to IPv4.
• J9 JACE
Includes any QNX-based JACE controller running AX-3.5 or earlier, including the models above, as
well as all other JACE controllers (regardless of AX-level), such as the JACE-2 and JACE-202 Express
(both NPM2-based). None of these support IPv6.
The two QNX-based JACE sub groups are sometimes referred to as “Hotspot JACE” or “J9 JACE” in this
document. Also see “Sun Hotspot JVM or IBM J9 JVM” on page 1-4 for related details.
Related to this, AX-3.5 and later Workbench began support for “IPv6”, where for any selected Ethernet
interface, there are now separate tabs for (standard) IPv4 Settings as well as IPv6 Settings.
Note that TCP/IP property field descriptors maintain an “IPv4”, “v4”, “IPv6”, or “v6” qualifier, to clarify
separate properties.
For example: IPv4 Address (IP Address)
JACE WiFi
Also starting in AX-3.6, a wireless 802.11b/g (WiFi) option became available for the JACE-700 controller,
effectively adding a third available interface for its platform TCP/IP configuration. For related details, see
the Engineering Notes II document “NiagaraAX JACE WiFi Option”.

TCP/IP Host fields

The top of the TCP/IP Configuration view provides the platform’s TCP/IP host settings.

Figure 1-105 Hosts fields on platform TCP/IP Configuration view

These available host fields are as follows:

• Host Name
Synonymous with “computer name,” this is a string that can be processed by a DNS server to resolve
to an IP address. By default, hostname for any QNX-based platform is “localhost”.
Note: On Win32 systems, this is also the computer name. Be aware that changing it will have
important consequences with regards to the computer’s identification in its workgroup or domain!
If using hostnames in your network, you should assign each Niagara platform a unique hostname.
• Hosts File
The hosts file is a standard TCP/IP hosts file, where each line associates a specific IP address with a
known hostname. To review and edit, you click on the expand control to see all entries.
• To add an entry, click at the end of the last line and press Enter.
Then type the IP address, at least one space, then the known hostname.
• To delete an entry, drag to highlight the entire line, then press Backspace.
Click the expand control again to collapse the Hosts File editor.
• Use IPv6
Default is No (unchecked). If set to Yes (checked), NiagaraAX (platform daemon and station) re-
spond to IPv6 requests, that is, creates IPv6 server sockets (daemon) and IPv6 fox multicast sockets.
This property is applicable only to the following hosts:
• AX-3.6 and later “Hotspot JACE”, that is JACE-7 (JACE-700) and JACE-6 and JACE-602 Ex-
press running AX-3.6 or later. See “IPv6 support” on page 1-66 for background details.
• AX-3.4 and later Windows-based hosts, providing that the host platform has the Microsoft
TCP/IP version 6 protocol installed.
• AX-3.4 and later Linux-based Supervisor.

NiagaraAX-3.6
1-67
Platform Guide
TCP/IP Configuration Chapter 1 – Niagara platform
TCP/IP DNS fields April 4, 2011

TCP/IP DNS fields

If connected to a QNX-based JACE platform, the DNS and gateway settings are also “host-level” param-
eters in the TCP/IP Configuration view, as shown in Figure 1-106.
Note: If a Windows-based host, DNS and gateway settings are available under each Interface section. See “TCP/
IP Interface fields” on page 1-68.

Figure 1-106 Host-level fields for QNX-based platform includes DNS and gateway

All QNX-based
JACEs

“Hotspot” JACEs only

(AX-3.6 and later)

The available fields for QNX-based JACE platforms are as follows:

• DNS Domain
The TCP/IP Domain Name System (DNS) domain this host belongs to, if used.
• IPv4 Gateway
The IP address for the device that forwards packets to other IPv4 networks or subnets. A valid gate-
way address is required in multi-station (JACE) jobs to allow point discoveries under NiagaraNet-
works.
• DNSv4 Servers
The IP address for one or more DNS servers (if available), where each can automate associations be-
tween hostnames and IPv4 addresses. Included are icon-buttons to Add (to enter IP address of serv-
er), Delete, and move Up/Down (to set the DNS search order).
• IPv6 Gateway
Available only if a AX-3.6 and later “Hotspot JACE”. The IPv6 address for the device that forwards
packets to other IPv6 networks or subnets.
• DNSv6 Servers
Available only if a AX-3.6 and later “Hotspot JACE”. The IPv6 address for one or more IPv6 DNS
servers (if available), where each can automate associations between hostnames and IPv6 addresses.
Included are icon-buttons to Add (to enter IP address of server), Delete, and move Up/Down (to set
the DNS search order).

TCP/IP Interface fields

For each Ethernet port on the connected platform, the TCP/IP Configuration platform view provides an
expandable Interface n section.
Some JACE models have two Ethernet ports: LAN1 and LAN2, which are Interface 1 (en0) and
Interface 2 (en1). Other JACE models may have a single Ethernet LAN port, Interface 1 (en0).
Note: Starting in AX-3.6, a JACE-700 can have an optional “WiFi” adapter installed. It appears in the TCP/IP
Configuration view as yet a third Interface 3 (bc0).

Figure 1-107 TCP/IP Interface fields, top properties

NiagaraAX-3.6
1-68
Platform Guide
Chapter 1 – Niagara platform TCP/IP Configuration
April 4, 2011 TCP/IP Interface fields

As shown in Figure 1-107, each Interface has the following properties at the top:
• ID
A read-only OS identifier for the hardware interface, such as “en0” if a QNX-based platform, or if a
Windows-based platform, either a 128-bit GUID (globally unique identifier) or a Windows network
connection name, such as “Local Area Connection 2”.
• Description
A read-only text string such as “Onboard Ethernet Adapter en0” for a QNX-based host, or “Intel(R)
PRO/100 VE Network Connection” for a Win32-based host, describing a NIC model.
• Physical Address
(Value is available only if platform is running AX-3.5 or later) The unique 48-bit MAC address of the
Ethernet adapter, in six two-hexadecimal digits. For example, for a JACE: 00:01:F0:80:13:E6
• Adapter Enabled
Checkbox to specify whether the Ethernet port is usable. On Windows-based hosts, this is read-only.
Below the properties above, each Interface has two separate tabs, as follows (each with properties):
• IPv4 Settings
• IPv6 Settings
IPv4 Settings
Figure 1-108 IPv4 tab for Interface of QNX-based JACE, in platform TCP/IP Configuration view

The following properties are on the IPv4 Settings tab of the selected Interface:
• DHCPv4
(Available on Interface 2 (en1) of a QNX-based JACE only if it is running AX-3.5 or later)
Note: Only ONE adapter of any QNX-based JACE may have DHCP enabled.
A checkbox to specify DHCP (Dynamic Host Configuration Protocol) instead of static IP addressing.
Successful use requires a DHCP server installed on your network. If enabled, other interface fields
such as IP Address and Subnet Mask become read-only, as these are assigned by the DHCP server
after the platform reboots.
Note: In general (for stability), static IP addressing is recommended over DHCP. If configuring for
DHCP it is recommended that you reserve a specific, fixed IP address for this JACE host in the
network’s DHCP server/router configuration, noting the MAC address of this adapter as shown above.

Caution Do not enable DHCP unless sure that your network has one or more DHCP servers! Otherwise, the JACE
may become unreachable over the network.

• DNS Domain
(Windows-based hosts only) The TCP/IP Domain Name System (DNS) domain this host belongs to,
if used.
• IPv4 Address
The “static” IP address for this host, unique on your network.
Note: Be careful to understand the following:
• If enabling both LAN ports, note that the LAN1 IP address and LAN2 IP address must be on
different subnets, otherwise the ports will not function correctly.
For example, with a typical “Class C” subnet mask of 255.255.255.0, setting Interface
1=192.168.1.99 and Interface 2=192.168.1.188 is an invalid configuration, as both addresses are
on the same subnet.
• A JACE does not provide IP routing or bridging operation between different Interfaces (LAN

NiagaraAX-3.6
1-69
Platform Guide
TCP/IP Configuration Chapter 1 – Niagara platform
TCP/IP Interface fields April 4, 2011

ports, GPRS, dialup, WiFi).

• IPv4 Gateway
(Windows-based hosts only) IP address for the device that forwards packets to other networks or
subnets.
• IPv4 Subnet Mask
The “static” IP subnet mask used by this host.
• DHCPv4 Server
Applies only if DCHP is enabled. Shows read-only address of the DHCP server from which this host
last obtained its IP address settings.
• DHCPv4 Lease Granted
Applies only if DCHP is enabled. Shows a read-only timestamp of when the DHCP lease started.
• DHCPv4 Lease Expires
Applies only if DCHP is enabled. Shows a read-only timestamp of when the DHCP lease will expire,
and will need renewal.
• DNSv4 Servers (DNS Servers)
(Windows-based hosts only) The IP address for one or more DNS servers, each of which can auto-
mate associations between hostnames and IP addresses. Included are icon-buttons to Add (to enter
IP address of server), Delete, and move Up/Down (to set the DNS search order).
IPv6 Settings
• Starting in AX-3.6, IPv6 support is available in some QNX-based JACE models, but is not available
in any QNX-based JACE running AX-3.5 or earlier. See “IPv6 support” on page 1-66 for background.
• AX-3.4 or later Windows-based hosts have IPv6 properties that are read-only. Any adjustments, if
necessary, must be made directly from the Windows OS interface, that is the Control Panel.

Figure 1-109 IPv6 tab for Interface of (Hotspot) QNX-based JACE, in platform TCP/IP Configuration view

The following properties are on the IPv6 Settings tab of the selected Interface:
• IPv6 Support
Yes or No, as read-only. Indicates if host platform’s OS supports IPv6.
• Some QNX-based JACEs running AX-3.6 or later (with “Hotspot” JVM) support IPv6. For
those hosts that do not, the rest of the properties below do not appear.
• Windows-based OS hosts typically provide IPv6 support, as does Linux.
• IPv6 Enabled
Checkbox for Enabled. Read-write for AX-3.6 or later “Hotspot JACE” only, where default is disabled
(cleared). If a Windows-based host this is read-only, and indicates whether the host is configured
with the IPv6 protocol.
• Obtain IPv6 Settings Automatically
Checkbox for Enabled (default). Changeable for a AX-3.6 or later “Hotspot JACE” only. Provides for
“auto-configuration” of IPv6 address, if acceptable. If enabled, the next two properties are read-only.
If cleared, the two properties below must be entered manually.
• IPv6 Address
The host’s IP address in IPv6 format, to be unique on its network.
• IPv6 Network Prefix Length
The number of left-most contiguous bits of the IPv6 address (in decimal) that compose the subnet
prefix.
• DNSv6 Servers
(Windows-based hosts only, providing host’s OS has IPv6 enabled) Read-only IPv6 address for one
or more DNS servers, each of which can automate associations between hostnames and IPv6 ad-
dresses.

NiagaraAX-3.6
1-70
Platform Guide
Chapter 1 – Niagara platform User Manager
April 4, 2011 Users management

User Manager
The User Manager is one of several platform views, available only when connected to a remote Windows-
based JACE. This view allows you to manage Windows OS user and group accounts local to that host
(which otherwise would require accessing “Administrative Tools” in Windows on that host).
Note: You need “admin-level” platform access in order to change any user settings. When connected to the
platform via a “user-level” login, you can review settings, but none of the buttons in this view are available,
nor are “drag and drop” actions possible. See “Levels of platform access” on page 1-42 for related details.

Figure 1-110 User Manager for remote Win32-based host

As shown in Figure 1-110 above, the view has two main sides.
• Users are listed in a users table on the left side.
• Groups are listed in a groups table the right side. In addition, a lower “membership” table shows all
members of any currently selected group.
Buttons below each side provide popup dialogs in which you can add or delete a user or group, or change
password for a selected user.
The following sections provide more details:
• Users management
• Groups management

Users management
In the users side of the User Manager, click in the users table and buttons below to perform various
Windows user management tasks. You can review, add, and delete users, and change passwords. You can
also drag and drop users into groups.
Review user
Double-click any existing user in the User Manager for a Details dialog, as shown in Figure 1-111.

Figure 1-111 Details dialog for Windows user

This displays the user’s account name, comment, and group memberships (including domain groups).
Add user
Click the New User button in the User Manager for a New User dialog, as shown in Figure 1-112.

NiagaraAX-3.6
1-71
Platform Guide
User Manager Chapter 1 – Niagara platform
Groups management April 4, 2011

Figure 1-112 New User dialog

In this dialog you must type a user name and password (text in both password fields must match). You
can also type a comment, typically a full user name or description. Click in the groups checklist to
designate which groups the new user should have membership.
When you click OK, the new user is added and appears in the user table.
Delete user
In the User Manager, click to select one or more users (press Ctrl and click to select multiples). Then click
the Delete User button for a confirmation dialog, as shown in Figure 1-113.

Figure 1-113 Confirm Delete dialog

When you click OK, the selected user(s) is deleted and removed from the user table.
Change user password
In the User Manager, click to select a user, then click the Change Password button for a popup dialog
(Figure 1-114).

Figure 1-114 Change Password dialog

You must type the current user’s password, then the new password twice (text in both new password fields
must match). When you click OK, the password for that user is changed to your new password.
Drag and drop
In the User Manager, you can “drag and drop” rows from the users table on top of a row in the groups
table. This adds the selected user(s) to the target group, without any popup dialog.
Or, if a single group is already selected, you can drag and drop user rows into the lower membership table
for that group. This adds the selected user(s) to that group, and updates the membership table.

Groups management
In the groups side of the User Manager, click in the groups table, membership table, and buttons below
to perform various Windows group management tasks. You can review, add, and delete groups, and in
any group, you can add or remove members.
Note: Starting in AX-3.5, Workbench and the NiagaraAX platform daemon changed for a Windows host, such
that only domain groups are shown in which the current user is a member, vs. all possible domain groups.
Previously, it was found that on a large domain (e.g. a corporate domain with thousands of domain
groups), platform daemon issues resulted that prevented proper loading of views such as the User Manager.
This could also affect User Authentication dialogs launched from the Platform Administration view.

NiagaraAX-3.6
1-72
Platform Guide
Chapter 1 – Niagara platform User Manager
April 4, 2011 Groups management

Review group
Click any existing group in the User Manager to see user members in the table below (Figure 1-115).

Figure 1-115 Select group to see membership

All users for the selected group are shown.

Add group
Click the New Group button in the User Manager for a popup dialog, as shown in Figure 1-116.

Figure 1-116 New Group dialog

Note: AX-3.5 and later hosts limit shown domain groups to those in which the current user is a member.
In this dialog you must type a name for the new group. Click in the users checklist to designate which
Windows users the new group should have as members.
By default, the users checklist is “filtered” to reduce entries as follows:
• List only local accounts — Any domain users and groups do not appear.
• List only users — Groups do not appear.
As needed, click these checkboxes to add or remove these choices in the users checklist.
When you click OK, the new group is added and appears in the groups table.
Delete group
Note: You cannot delete any Windows “Built-In” group.
In the User Manager, click to select one or more groups (press Ctrl and click to select multiples). Then
click the Delete Group button for a confirmation dialog, as shown in Figure 1-113.

Figure 1-117 Confirm Delete dialog

When you click OK, the selected group(s) is deleted and removed from the groups table.
Add member
Select (click) a group in the User Manager, then the Remove Member button for a popup (Figure 1-118).

NiagaraAX-3.6
1-73
Platform Guide
WiFi Configuration Chapter 1 – Niagara platform
Groups management April 4, 2011

Figure 1-118 Add Member dialog

Only users not already members of this group are listed. Click in the users checklist to designate which
Windows users the group should have as members.
By default, as in the New Group dialog (Figure 1-116), the users checklist is filtered to not list domain
users and groups. If needed, click these checkboxes to add or remove these choices in the users checklist.
When you click OK, the group’s membership is updated with the member(s) you added.
Note: You can also drag and drop users (rows in users table) onto groups (rows in groups table).
Remove member
Select (click) a group in the User Manager, then in the membership table, select one or more users. With
the user(s) selected, click the Remove Member button for confirmation dialog (Figure 1-119).

Figure 1-119 Confirm Remove dialog

When you click OK, the selected user(s) is removed that group’s membership.

WiFi Configuration
WiFi Configuration appears among platform views, along with a WiFi Certificate Manager
view., only if a AX-3.6 or later JACE host that has an installed 802.11b/g wireless WiFi adapter, At the time
of this document, this applies only to a JACE-700 with a Mini-PCI WiFi adapter card (T7-WIFI option).
This JACE-7 option became available in the AX-3.6 software release time frame.

Figure 1-120 WiFi Configuration platform view (AX-3.6 or later)

This view lets you discover 802.11b/g networks available to the JACE, and add one or more networks, as
necessary.
Note: The JACE’s running station also has a “WifiPlatformService” among its platform services. Its
default “Wifi Platform Service Plugin” view is identical to the WiFi Configuration view.

NiagaraAX-3.6
1-74
Platform Guide
Chapter 1 – Niagara platform WiFi Certificate Manager
April 4, 2011 Groups management

Figure 1-121 Wifi Platform Service Plugin view (AX-3.6 or later)

Refer to the Engineering Notes II document “NiagaraAX JACE WiFi option” for complete details,
including usage scenario, configuring the JACE for WiFi, and further details on this view.

WiFi Certificate Manager

WiFi Certificate Manager appears among platform views, along with a WiFi Configuration
view, only if a AX-3.6 or later JACE host that has an installed 802.11b/g wireless WiFi adapter, At the time
of this document, this applies only to a JACE-700 with a Mini-PCI WiFi adapter card (T7-WIFI option).

Figure 1-122 WiFi Certificate Manger platform view (AX-3.6 or later)

This view lets you import “CA certificate” and client “private key” files onto the JACE for use in WiFi
security types WPA or WPA2. Usage of these security types (with such digital certificates) are uncommon
except in an “enterprise level” network scenario.
Note: The JACE’s running station also has a “WifiPlatformService” among its platform services. The
WiFi Certificate Manager view is available as the service’s secondary view.
Refer to the Engineering Notes II document “NiagaraAX JACE WiFi option” for complete details,
including further details on using this view.

Remote File System

The Remote File System view is one of several platform views. It provides a read-only view of the remote
platform’s file system.
For QNX-based platforms (only), it also provides browse capability of the file system root (/) of the
remote host, using the Nav tree side bar of Workbench (Figure 1-123).

NiagaraAX-3.6
1-75
Platform Guide
Remote File System Chapter 1 – Niagara platform
Groups management April 4, 2011

Figure 1-123 Remote File System for QNX-based host

NiagaraAX-3.6
1-76
Platform Guide
 CHAPTER 2
Platform Services
This section explains the platform access available in a running station—in other words, the station’s
perspective on its host platform. Unlike the various platform views, a platform connection is not needed
to access platform services. Instead, you need only a standard station (Fox) connection.
The following main sections provide more details:
• About Platform Services
• “PlatformServiceContainer parameters” on page 2-2
• “PlatformServiceContainer actions” on page 2-6
• “SystemService (under PlatformServices)” on page 2-7
• “Platform service types” on page 2-7
• “Using platform services in a station” on page 2-8
• “JACE power monitoring” on page 2-9
• “PlatformServices binding and link caveats” on page 2-10
• “About the NtpPlatformService” on page 2-11

About Platform Services

Under Config, Services, every running Niagara station has a PlatformServices container
(Figure 2-1), which any station user with admin-level permissions to this component can access.

Figure 2-1 Example JACE station’s PlatformServices

Platform services in a running station provide two main types of functionality:

• A “subset” of platform views available in a platform connection. Platform services do not provide the
full set of functions available in Workbench platform connection. For example, you cannot install or
upgrade software, or transfer stations and files. However, a number of platform configuration views
are available under a station’s PlatformServices.
• Certain platform configuration settings accessible only through PlatformServices—that is, not avail-
able in a client platform connection.
Note: When engineering station security, be careful about assigning user permissions to PlatformServices and its
child service components. In general, you should regard this portion of the station as most critical, as it
allows access to items such as host licenses and TCP/IP settings. Furthermore, right-click actions on the
PlatformServices include “Restart Station” (note that if a QNX-based JACE, this results in a host reboot!).
For details about station security, see “About Security” in the User Guide.

NiagaraAX-3.6
2–1
Platform Guide
PlatformServiceContainer parameters Chapter 2 – Platform Services
Component differences for platform services April 4, 2011

Component differences for platform services (as explained in the next section) should be understood.

Component differences for platform services

PlatformServices is different from all other components in a station in the following ways:
• It acts as the station interface to specifics about the host platform (whether JACE or a PC).
• It is built dynamically at station runtime—you do not see PlatformServices in an offline station.
• Changes you make to PlatformServices and all child services are not stored in the station database.
Instead, changes are stored in other files on that platform, such as its platform.bog file, or within
the platform’s operating system.
Note: Do not attempt to edit platform.bog directly; always use PlatformServices’ views!
In summary, when you make changes under a station’s PlatformServices, those changes are independent
of the running station. If you install another station, platform services are dynamically recreated again
when the new station starts, based upon the last settings.
In addition, understand that some changes in platform services views may require the host to be rebooted
to become effective. Examples include TCP/IP changes, or some NTP-related changes in a QNX-based
JACE. A “Reboot Now?” popup dialog appears upon saving such a change.

PlatformServiceContainer parameters
In addition to being a container, the PlatformServicesContainer provides various status and configu-
ration entries for the host platform. In the Nav tree, double-click PlatformServices to access the “Platform
Service Container Plugin” which lists these entries, as shown in Figure 2-2.

Figure 2-2 PlatformServicesContainerPlugin view (many entries not shown)

Included are many read-only status values as well as configuration parameters. Each is described in
separate sections as follows:
• PlatformServiceContainer status values
• PlatformServiceContainer configuration parameters
• Additional PlatformServiceContainer properties
Note: By default, any PlatformServicesContainer also provides three right-click actions.

PlatformServiceContainer status values

Status values in a station’s PlatformServicesContainer include the following:
• Name
Name of running station.
• Host
IP address of host platform.
• Model
Model of host platform type, such as “J403,” “JNXS,” or “Workstation.” See “Models of platforms” on
page 1-9 for further details.
• Host ID
NiagaraAX host identifier, a string unique to this one machine.

NiagaraAX-3.6
2-2
Platform Guide
Chapter 2 – Platform Services PlatformServiceContainer parameters
April 4, 2011 PlatformServiceContainer status values

• Niagara Version
Version and build number of the NiagaraAX distribution running in the host platform.
• Java VM Name
Java virtual machine used, e.g. either “Java HotSpot(TM) Client VM” or “J9” (QNX-based hosts) or
“Java HotSpot(TM) Client VM” for Windows-based hosts.
• Java VM Vendor
Vendor for Java VM, e.g. “IBM Corporation” (J9) or “Sun Microsystems Inc.” (Java HotSpot).
• Java VM Version
Version of Java VM, e.g. “2.3” (J9) or “1.6.0_02-b06” (Java Hotspot).
• OS Name
Operating System name, such as “QNX” or “Windows XP.”
• OS Arch.
Machine architecture for OS, such as “ppc” (QNX-based hosts) or “x86” (Windows-based hosts)
• OS Version
Operating System version, such as “6.4.1” (QNX) or “5.1” (Windows XP)
• Platform Daemon Port
Port number on which the platform daemon that started the station is listening (3011, or another
port number). This can prove useful in case you changed the platform port (see “Change HTTP Port”
on page 1-43), but then forgot what the new port is.
Note: In the container plugin, most of the remaining entries are configuration parameters. However
a few status values are also mixed in, and are described below.
• Number of CPUs
Number of CPUs used in the host platform (typically 1).
• Current CPU Usage
Percentage of CPU utilization in the last second.
• Overall CPU Usage
Percentage of CPU utilization since the last reboot.
• Filesystem
File storage statistics for the host, including total file space, available (free) space, and file block size
(minimum size for even the smallest file). For a QNX-based JACE host, it may look similar to:
Total Free Block Size Files Max Files
/ffs0 126,976 KB 77,160 KB 2,048 bytes 732 4096
/aram0 31,488 KB 29,832 KB 1,024 bytes 28 4096

Note: The “Files” and “Max Files” values require the JACE to be running AX-3.6 or later.
• Physical RAM
Current total and free RAM statistics for the host. For a QNX-based JACE, it may look similar to:
Total Free
262,144 KB 70,160 KB

• Serial Number
(Appears only if QNX-based JACE running AX-3.6 or later). The controller’s unique serial number.
• Hardware Revision
(Appears only if QNX-based JACE running AX-3.6 or later). Hardware revision of the controller.
• Hardware Jumper Preset
(Appears only if QNX-based JACE) Either true or false—indicates whether or not the mode jumper
is installed for “serial shell mode” access. Read at boot time only. See “About JACE serial shell mode”
in the JACE NiagaraAX Install & Startup Guide.
• EWF Overlays
(Appears only if a CompactFlash-based JACE-NXT or JACE-NXS host) Status of the Enhanced
Write Filter overlays which protect the CompactFlash card from excessive writes. Two overlays are
listed, one for OS, and one for History. The current State can either be “Enabled,” “Disabled,” or
“Unknown.” The state should always say “Enabled” for both overlays under normal operation. The
Command should normally be “Commit.” Other possible values are “noCmd” and “CommitAndDis-
able.” Ram Usage is the amount of RAM used by the overlay, and should “cap out” at some maxi-
mum number during normal operation. The history overlay theoretical maximum is about 5% larger
than the size of the History partition, about 85MB.
Also see the JACE-NXT NiagaraAX Install & Startup Guide and JACE-NXS NiagaraAX Install &
Startup Guide.

NiagaraAX-3.6
2-3
Platform Guide
PlatformServiceContainer parameters Chapter 2 – Platform Services
PlatformServiceContainer configuration parameters April 4, 2011

PlatformServiceContainer configuration parameters

Configuration properties of a station’s PlatformServices Container are listed below. If needed, you can
change any in the container plugin view (property sheet)—click Save to write to the host platform.
Note: It is recommended that you leave engine-related parameters and other advanced settings at default values,
unless you have been directed otherwise by Systems Engineering.
• Locale
Determines locale-specific behavior such as date and time formatting, and also which lexicons are
used. A string entered must use the form: language [“_” country [“_” variant]]. For example, U.S. En-
glish is “en_US” and traditional Spanish would be “es_ES_Traditional”. For details, see Sun doc-
umentation at http://java.sun.com/j2se/1.4.2/docs/api/java/util/Locale.html.
• System Time
Current local time in host.
• Date
Current local date in host.
• Time Zone
Current local time zone for host. For more details, see “Time Zones and NiagaraAX” on page B-1.
• Engine Watchdog Policy
Note: The engine watchdog is a platform daemon process, to which the station periodically reports
its updated engine cycle count. The watchdog purpose is to detect and deal with a “hung” or “stalled”
station, and is automatically enabled when the station starts.
The Engine Watchdog Policy defines the response taken by the platform daemon if it detects a sta-
tion engine watchdog timeout. Watchdog policy selections include:
• Log Only — Generates stack dump and logs an error message in the system log.
• Terminate — (Default) Kills the VM process. If “restart on failure” is enabled for the station
(typical), the station is restarted.
• Reboot — Automatically reboots the host JACE platform. If “auto-start” is enabled for the sta-
tion, the station is restarted after the system reboots.
• Engine Watchdog Timeout
Default is 1 minute, and range is from 0 ms to infinity. If the station’s engine cycle count stops chang-
ing and/or the station does not report a cycle count to the platform daemon within this defined pe-
riod, the platform daemon causes the VM to generate a stack dump for diagnostic purposes, then
takes the action defined by the Engine Watchdog Policy.
• Enable Station Auto-Save
Either Enable (default) or Disable. Allows for “auto save” of running station to
“config_backup_<YYMMDD>_<HHMM>.bog” file at the frequency defined in next property. Auto-
saved backup files are kept under that station’s folder.
• Station Auto-Save Frequency
Default is every 24 hours for any QNX-based host, or every (1) hour if Windows-based host. Range
is from 1 to many hours.
• Station Auto-Save Backups to Keep
The default value for QNX-based hosts is 0 (none), and in most cases, this is appropriate for any
QNX-based host. Oldest of kept backups is replaced upon next manual save or auto-save backup,
once the specified limit is reached. In Windows-based hosts, the default is 3, and typically (unless a
CompactFlash-based JACE-NXT or JACE-NXS) can be safely adjusted up, if desired.
• Failure Reboot Limit
Limits the number of system reboots that can be triggered by station failures, within the Failure Re-
boot Limit Period, below (if the host is so configured using the Application Director, see
“Start checkboxes” on page 1-14). Default value is 3.
• Failure Reboot Limit Period
Specifies the repeating frequency of the Failure Reboot Limit period, with default value at 1 hour.
Note: These two “Failure Reboot” settings are also adjustable (in any version of QNX-based host)
within that JACE’s !daemon/daemon.properties file, in the following two properties:
• failureRebootLimit=x (where x is integer, default is 3)
• failureRebootLimitPeriod=y (where y is long in milliseconds, default is 3600000)
• RAM Disk
In MB, where default varies according to JACE model. Specifies size of RAM disk used to store his-
tory and alarm files.

NiagaraAX-3.6
2-4
Platform Guide
Chapter 2 – Platform Services PlatformServiceContainer parameters
April 4, 2011 Additional PlatformServiceContainer properties

• Minimum Free Heap Size

Specifies the minimum free Java heap size, in MB, against which the station compares (tests) for low
memory conditions, that is excessive Java heap. The default varies according to JACE model.
This test automatically runs once a minute. If the heap free byte count is less than the defined min-
imum free heap size, a “low memory warning” appears in all Workbench views of the station. The
warning is a yellow message box overlayed on any new view accessed, or on any current view that is
refreshed. This warning is removed when the heap free byte count rises above the defined minimum
size—such as might occur if enough components are deleted from the station.
Note: All memory statistics, including those for heap, are accessible on a station opened in
Workbench, via the Resource Manager view of the Station component.

Additional PlatformServiceContainer properties

A station running on a QNX-based platform has the following additional PlatformServicesContainer
properties, as shown in Figure 2-3.

Figure 2-3 Additional PlatformServiceContainer properties for QNX-based host.

These properties are in addition to the other standard configuration properties. Each of these additional
properties has a read-only Status field on the far right side, plus the following configuration fields:
• RAM Disk Size
Has two configurable fields:
• Min Free — minimum allowable free size in %. If status is not Ok, a “Low RAM disk space”
warning is overlayed in all Workbench views of the station.
• Size —in MB, specifies the amount of RAM disk used to store history and alarm files, where de-
fault varies according to JACE model.
• Java Heap
Has one configurable “Min Free” field, in MB. Used by the station to compare (test) for low memory
conditions, that is excessive Java heap. Also shown is a read-only Max field, in MB, for the heap size.
If status is not Ok, a “Low memory” warning is overlayed in all Workbench views of the station.
• Open File Descriptors
Has one configurable “Min Free” field, related to number of files (and/or open sockets). Specifies the
maximum amount of file descriptors that can be used. That is, the read-only “Max Open” number
minus the “Min Free” amount. File descriptors are used for histories, modules, and Fox connections
If exceeded a “Station has too many open files or sockets” warning is overlayed in all Workbench
views of the station.
• Free RAM
Has one configurable “Min Free” field, in KB. Specifies the minimum RAM that can be left free dur-
ing station operation. If status is not Ok, a “Low free RAM” warning is overlayed in all Workbench
views of the station.
• Disk Space
Has one configurable “Min Free” field, in %. Specifies the minimum percentage of disk storage that
can be left free during station operation. Below this amount, a “Platform running low on disk space”
warning is overlayed in all Workbench views of the station.
• Files
Has one configurable “Min Free” field, to specify the minimum number of free files available during
station operation. Below this amount, a related platform warning appears. Note that starting in AX-

NiagaraAX-3.6
2-5
Platform Guide
PlatformServiceContainer parameters Chapter 2 – Platform Services
Model-specific PlatformServiceContainer properties April 4, 2011

3.6, the PlatformServiceContainer status property “Filesystem” includes both the current number of
files and the maximum number of files for each partition on a QNX-based JACE.
Note: Current statistics for memory, heap, and file descriptors (fd) are accessible on a station opened in
Workbench, via the Resource Manager view of the Station component.

Model-specific PlatformServiceContainer properties

Some QNX-based JACE models may have yet more PlatformServices properties, specific to special
hardware features. This is in addition to the standard and additional properties described above.
Typically, these are configured at JACE commissioning time.
For more details, see “Controller-specific PlatformServices properties” in the JACE NiagaraAX Install &
Startup Guide.

PlatformServiceContainer actions
The PlatformServicesContainer also provides three (right-click) actions, as shown in Figure 2-4.

Figure 2-4 PlatformServicesContainer actions.

These actions are described as follows:

• Send Thread Dump to Console
Causes that host’s platform daemon to have the station send a VM thread dump to its standard out-
put (console), equivalent to the “Dump Threads” command in the Application Director. Typically
used only during troubleshooting.
Note: Apart from Application Director (platform access) to view station output, you can also view
a “snapshot” of station output in a browser. Do this via the “stdout” link in the spy utility, at URL
http://<hostIP>/ord?spy:/stdout
• Request Garbage Collection
Causes the JVM running the station to perform garbage collection. This results in a “best effort” to-
wards releasing unused objects and making more memory available on the “heap”. Note that current
heap and memory statistics for any running station are available on the ResourceManager view of
the station component.
• Restart Station
Produces a popup confirmation dialog. Applies directly to a station running in a Windows-based
platform, where it is equivalent to issuing a “Restart” command from the Application Director (sta-
tion is saved on its host, then restarted). If issued to a station running on a QNX-based platform, this
results in a host reboot (station restart not available unless host is rebooted).
Note: Also, most child services under the PlatformServicesContainer have an available “Poll” action, which
refreshes their property values. See “Platform service types” for a listing of possible child services.

NiagaraAX-3.6
2-6
Platform Guide
Chapter 2 – Platform Services SystemService (under PlatformServices)
April 4, 2011 PlatformServiceContainer actions

SystemService (under PlatformServices)

PlatformServices also contains a child “SystemService” container, accessible from its property sheet as
shown in Figure 2-5. Unlike other child services, SystemService does not appear in the Nav tree.

Figure 2-5 SystemService from property sheet of PlatformServices.

When you expand SystemServices, you see most of the same properties available in the default Platform
Service Container Plugin view (see “PlatformServiceContainer parameters” on page 2-2). In addition,
there is container slot “Station Save Alarm Support,” as shown in Figure 2-6.

Figure 2-6 Station Save Alarm Support expanded in property sheet of SystemService.

These properties allow you to configure the alarm class and other parameters to use for “station save”
alarms. Such an alarm may occur, for example, if there is insufficient disk space to complete the save.
Poperties work the same as those in an alarm extension for a control point. For property descriptions, see
the User Guide section “About alarm extension properties”.
Note: Other platform warnings from defined limits, such as for low memory, low disk space, and so on (see
Figure 2-3 on page 5 for related properties) are not really alarms—they simply generate a yellow overlay in
the lower right corner when viewing the station in Workbench. If you need actual alarms, you can link from
an appropriate boolean slot of the SystemService component (for example, “LowHeap”) into other persisted
station logic in another area of the station.
If linking to PlatformServices, be aware that you should change the link type from “handle” to “slot path”.
For related details, see “PlatformServices binding and link caveats” on page 2-10.

Platform service types

In addition to the SystemService found under its property sheet, the PlatformServicesContainer has
various child services, of which different types are listed below.
Note: Some platform services are intended to support installations where all configuration must be done using
only a browser connection (and not a Workbench platform connection to a JACE’s platform daemon).
Examples include types TcpIpService and LicenseService.

NiagaraAX-3.6
2-7
Platform Guide
Using platform services in a station Chapter 2 – Platform Services
PlatformServiceContainer actions April 4, 2011

The list of visible platform service types includes the following:

• TcpIpService
Provides access to the same configuration using the platform’s TCP/IP Configuration view.
• LicenseService
Provides access to the same configuration using the platform’s License Manager view.
• SerialPortService
Allows review of available serial ports on the host platform. For older QNX-based JACEs with con-
figurable serial ports (e.g. JACE-403), this is where you configure port usage. For a related procedure,
see “JACE serial port configuration” in the JACE NiagaraAX Install & Startup Guide.
• PowerMonitorService
Currently applies to QNX-based JACEs, providing configuration and status of the JACE’s battery
monitoring and AC power-fail shutdown routines. See “JACE power monitoring” on page 2-9 for de-
tails. This service also applies to some models of the (Win32-based) JACE-NXT and JACE-NXS, see
“JACE-NXT (and JACE-NXS) power monitoring” on page 2-9.
• DialupService
Provides status of the platform’s dialup daemon and allows “blockout” of dialup functions from sta-
tion logic, if desired. For details, see “About the dialup daemon and service” on page 1-21.
• HardwareMonitorService
Applies to station in a Win32-based JACE only (JACE-NXT, JACE-NXS, JACE-NX). Provides status
of several internal environmental variables, including alarm limit configuration. See “JACE-NXT
hardware monitoring” on page 2-9 and “JACE-NXS hardware monitoring” on page 2-10 for details.
• NtpPlatformService
Provides the Niagara interface to the NTP (Network Time Protocol) service or daemon of the plat-
form’s OS (QNX, Win32, Linux), including several configuration parameters and a list specifying
one or more NTP time servers. For details, see “About the NtpPlatformService” on page 2-11.
• GprsPlatformService
Available only for a QNX-based JACE with a GPRS modem option card installed, providing that the
platGprs module is installed. Refer to the section “About the GprsPlatformService” in the Engi-
neering Notes document GPRS modem option for more complete details.
• UsbMonitorPlatformService
(Applies to JVLN, i.e. JACE-7 platforms only). Provides read-only debug type details related to USB
port monitoring on the JACE-7 series controller. If client applications are installed that interface
with this service, system notifications may occur when USB devices are inserted or removed.
• DataRecoveryService
(Applies only to a AX-3.6 or later QNX-based JACE with an installed “SRAM option card”). Allows
monitoring the service that automatically creates and manages static RAM buffers in the option
card, allowing “battery-less” operation of the JACE controller. For details, refer to the Engineering
Notes II document JACE Data Recovery Service (SRAM support).
Note: This service automatically removes any former PowerMonitorService.
• WifiPlatformService
(Applies if a JACE-700 with installed WiFi optiononly, AX-3.6 or later). Allows configuration of the
optional WiFi adapter installed in the JACE controller, providing that the platWifi module is in-
stalled. For details, see the “About the WiFiPlatformService” section in the Engineering Notes II doc-
ument NiagaraAX JACE WiFi option.

Using platform services in a station

Apart from configuration usage, some platform services under the PlatformServicesContainer provide
status values that you can further incorporate. Typically, each value also provides built-in alarm features.
Usage is typical for the following:
• JACE power monitoring
• JACE-NXT (and JACE-NXS) power monitoring
• JACE-NX hardware monitoring
• JACE-NXS hardware monitoring

NiagaraAX-3.6
2-8
Platform Guide
Chapter 2 – Platform Services Using platform services in a station
April 4, 2011 JACE power monitoring

JACE power monitoring

Note: Starting in AX-3.6, it is possible for a JACE-2,-6,-7 controller to be outfitted with an “SRAM option card”,
with removal of any internal NiMH backup battery and (if applicable) external 12V battery. This “battery-
less” JACE operation is supported by a new platform service: the DataRecoveryService, which
automatically replaces the power monitoring service in the JACE’s station. For details, refer to the
Engineering Notes II document JACE Data Recovery Service (SRAM support).
By default, through the PowerMonitorService, any QNX-based JACE provides status monitoring of
the following items, via “Boolean” type slots:
• AC power
(“Primary Power Present” slot) — True whenever AC power is currently supplied to the JACE.
• Battery level
(“Battery Good” slot) — True if last JACE test of NiMH backup-battery was good.
Also included is a “Time of Last Test” slot that provides a timestamp for the last battery test.
If needed, you can make Px bindings or links to these slots (however, see “PlatformServices binding and
link caveats” on page 2-10). In addition to these read-only status slots, the PowerMonitorService provides
related configuration slots, which you typically review at commissioning time. For more details and a
related procedure, see “JACE power monitoring configuration” in the JACE NiagaraAX Install & Startup
Guide.
Note: As new QNX-based JACE platforms are introduced, additional power-monitoring capabilities may be
present in the station’s PowerMonitorService. For example, both the JACE-7 series and JACE-x02 Express
series (“M2M JACE”) may be installed with two backup batteries: the NiMH battery like a JACE-2/6, plus
an optional 12V sealed lead-acid (SLA) battery that provides system operation for some duration during
a power outage. In this “dual battery” PowerMonitorService, separate slots exist for the monitoring and
alarming of both batteries. For related details, see the latest JACE NiagaraAX Install & Startup Guide.

JACE-NXT (and JACE-NXS) power monitoring

Note: Often, a hard-drive based JACE-NXT or JACE-NXS does not have the special SITOP DC UPS module
(with battery accessory), in which case its PowerMonitorService will have no application. The following
slots do apply to the CompactFlash-based JACE-NXT or JACE-NXS, which will be so equipped.
Currently, through the PowerMonitorService, a station running in a JACE-NXT or JACE-NXS
provides status monitoring of the following items, via “Boolean” type slots:
• DC power
(“Primary Power Present” slot) — True whenever DC power is currently supplied to the UPS.
• Battery level
(“Battery Ok” slot) — True if last UPS backup-battery test was good.
• UPS Connectivity
(“Ups Talking” slot) — value is “talking” if last JACE attempt to communicate to the UPS was success-
ful. Another possible state is “no comm.” Note that a USB cable must be connected between the
JACE-NXS and the SITOP UPS module.
If needed, you can make Px bindings or links to these slots (however, see “PlatformServices binding and
link caveats” on page 2-10). In addition to these read-only status slots, this PowerMonitorService
provides related configuration slots, which you typically review at commissioning time.
For more details and a related procedure, refer to:
• “Power monitoring JACE-NXT configuration” in the JACE-NXT NiagaraAX Install & Startup Guide.
• “Power monitoring JACE-NXS configuration” in the JACE-NXS NiagaraAX Install & Startup Guide.

JACE-NXT hardware monitoring

A station in the Windows-based JACE-NXT provides status monitoring of internal hardware param-
eters, via “Float” type slots under its HardwareMonitorService.
The three items monitored are:
• CPU temperature
(“Cpu Temp” slot) — Value in degrees (C or F) of the mainboard under the JACE-NXS’s CPU.
• Board temperature
(“Board Temp” slot) — Value in degrees (C or F) of the space inside the chassis.
• RAM temperature
(“Ram Temp” slot) — Value in degrees (C or F) of the space inside the chassis.

NiagaraAX-3.6
2-9
Platform Guide
Using platform services in a station Chapter 2 – Platform Services
JACE-NXS hardware monitoring April 4, 2011

If needed, you can make Px bindings or links to these slots (however, see “PlatformServices binding and
link caveats” on page 2-10). In addition to these read-only status slots, the HardwareMonitorService
provides related configuration slots, which you typically review at commissioning time. For more details
and a related procedure, see “Hardware monitoring JACE-NXT configuration” in the JACE-NXT
NiagaraAX Install & Startup Guide.

JACE-NXS hardware monitoring

A station in the Windows-based JACE-NXS provides status monitoring of internal hardware parameters,
via “Float” type slots under its HardwareMonitorService.
The two items monitored are:
• CPU temperature
(“Cpu Temp” slot) — Value in degrees (C or F) of the mainboard under the JACE-NXS’s CPU.
• Board temperature
(“Board Temp” slot) — Value in degrees (C or F) of the space inside the chassis.
If needed, you can make Px bindings or links to these slots (however, see “PlatformServices binding and
link caveats” on page 2-10). In addition to these read-only status slots, the HardwareMonitorService
provides related configuration slots, which you typically review at commissioning time. For more details
and a related procedure, see “Hardware monitoring JACE-NXS configuration” in the JACE-NXS
NiagaraAX Install & Startup Guide.

JACE-NX hardware monitoring

A station in the (discontinued) Windows-based JACE-NX provides status monitoring of various internal
hardware parameters, via “Float” type slots under its HardwareMonitorService.
A few of the items monitored include:
• CPU temperature
(“Cpu Temp” slot) — Value in degrees (C or F) of the mainboard under the JACE-NX’s CPU.
• CPU fan Speed
(“Cpu Fan Speed” slot) — RPM value of the CPU fan inside the JACE-NX.
• Chassis fan Speed
(“Sys Fan Speed” slot) — RPM value of the JACE-NX’s rear-mounted chassis fan.
Also included are various internal voltage values (Vtt, CPU core, Vcc 3 and 5, +12, -12, Vsb).
If needed, you can make Px bindings or links to these slots (however, see “PlatformServices binding and
link caveats” on page 2-10). In addition to these read-only status slots, the HardwareMonitorService
provides related configuration slots, which you typically review at commissioning time. For more details
and a related procedure, see “Hardware monitoring in the JACE-NX” in the JACE-NX NiagaraAX Install
& Startup Guide.

PlatformServices binding and link caveats

Because any station’s PlatformServices are dynamically built upon startup, if binding its slots to Px
widgets (or linking to other station components), be aware of the following limitations/guidelines:
• Subscription behavior is unique to a station’s PlatformServices slots, in that property values initially
load, but do not automatically update. To explicitly refresh such properties, you must invoke the
“poll” action of the container for those properties.
For example, if on a Px page you bind a BoundLabel to the PowerMonitorService’s “Battery Good”
slot, it will display text as “true” or “false.” However, this value does not update until the user right-
clicks for the “Poll” action, which forces a fresh read.

Figure 2-7 Poll action on bound PlatformServices property

• Links from PlatformServices (and child slots) to other station components must use a source ord
“slot path”, versus “handle”. Otherwise, after a station restart or host reboot, handle-sourced links
may be lost. An example link being edited to use slot path is shown in Figure 2-8.
Note: Consider the “update limitation” before linking PlatformServices slots into other components
that provide control logic. Linked slot values may well be outdated shortly after station startup, yet
still “subscribed” and not marked as “stale.”

NiagaraAX-3.6
2-10
Platform Guide
Chapter 2 – Platform Services About the NtpPlatformService
April 4, 2011 Interaction with station’s TimeSyncService

Figure 2-8 From LinkSheet of target component, editing link to use slot path for source ord.

However, note that the station’s plugins (views) for the PlatformServices do provide updated property
values, as they work in concert with the special polling used for platform-resident data.

About the NtpPlatformService

Starting in AX-3.4, PlatformServices in any station contains a child NtpPlatformServicesOS, which
provides an interface to the RFC 1305-compliant NTP (Network Time Protocol) service or daemon
running on that host platform. NTP is the currently recommended time synchronization protocol to use
between inter-networked devices, offering more accuracy than the RFC 868 Time Protocol.
By default, this platform service is disabled.
• If left disabled, this platform service does nothing.
• If enabled, this platform uses NTP as a client to sync its clock with time values retrieved from one or
more NTP time servers, according to other configuration properties.
Note: An enabled NtpPlatformService will not allow client synchronization with time servers using
RFC 868, even if the station also has a TimeSyncService under its Config, Services folder. See the
section “Interaction with station’s TimeSyncService” for related details.
See the following sections for more details:
• Interaction with station’s TimeSyncService
• NTP port/firewall considerations
• About the Ntp Platform Service Editor

Interaction with station’s TimeSyncService

Typically, an NTP-only solution is used to synchronize time among NiagaraAX hosts running AX-3.4 or
later, such that all platforms use their enabled NtpPlatformService for their OS type, and each has no
TimeSyncService component in their station. A Supervisor may be NTP-configured to sync with one or
more domain controllers, or perhaps to sync to one or more well-known Internet public NTP time
servers. Whereas JACEs typically specify the Supervisor as the NTP time server. Or alternatively, a JACE
may be configured to sync to other JACEs, or (providing it has access to DNS and a gateway), a public
NTP time server.
However, it may be possible that RFC 868 time server support is still required, for example an AX-3.4 or
later Supervisor on a job that includes one or more AX-3.3 JACEs. In this scenario, the Supervisor could
synchronize its own time using NTP (as a client) using its NtpPlatformServiceWin32, and also behave as
an RFC 868 time server via the TimeSyncService in its running station. Note in this configuration, any
child “TimeSyncClient” components under its TimeSyncService are irrelevant—as whenever the
NtpPlatformService is enabled, client synchronization is only possible using NTP.
However, in the TimeSyncService of any remote AX-3.3 (or earlier) JACE station, it could reference the
Supervisor as the TimeSyncClient (time server) to request/receive RFC 868 synchronization.

NiagaraAX-3.6
2-11
Platform Guide
About the NtpPlatformService Chapter 2 – Platform Services
NTP port/firewall considerations April 4, 2011

NTP port/firewall considerations

On any host, NTP requires the use of UDP port 123—this port is not configurable. On a QNX-based
JACE this is not an issue. However, on a Windows or Linux host platform, you typically need to make the
necessary firewall exception or “iptable” entry to allow UDP port 123 traffic.
Note: Otherwise, NTP time synchronization can fail because of firewall-blocked messages.

About the Ntp Platform Service Editor

Regardless of platform OS type (Windows, QNX, Linux), the default view for any NtpPlatformService is
an Ntp PlatformService Editor OS view, your typical interface. Double-click any NtpPlatform-
Service to see this editor.
Although a few differences exist between the different NTP platform service editors in property names,
all three types use a similar division of “key properties” at top, and “specified time server(s)” at the bottom
of the dialog. Specific details on each NTP platform service editor are in the following sections:
• Ntp Platform Service Editor Win32
• Ntp Platform Service Editor QNX
• Ntp Platform Service Editor Linux
Note: All NtpPlatformServices have a right-click action “Poll”. This action refreshes the values shown in the Ntp
Platform Service Editor (received from the NTP daemon), but does not affect messaging between the host
and an NTP server.
However, starting in AX-3.6, the NtpPlatformServiceQnx (for a JACE) does have an additional“Sync Now”
action, which does attempt an immediate sync. See “Sync Now action” on page 2-15 for more details.

About the Ntp Platform Service Editor Win32

An example Win32 host Ntp Platform Service Editor is shown in Figure 2-9. This is the default view for
the NtpPlatformService on a Win32 host.

Figure 2-9 Ntp Platform Service Editor Win32

This dialog provides access to some of the key settings of the Windows Time service (W32Time) on the
host platform.
Note: Settings are only a small subset of those possible to configure—for more fine-grained tuning of the time
service, Windows registry settings can be set according to Microsoft’s latest instructions. At the time of this
document, the current Microsoft reference for Windows Time service settings is found at:
http://technet2.microsoft.com/windowsserver/en/library/b43a025f-cce2-4c82-
b3ea-3b95d482db3a1033.mspx?mfr=true
As in all Ntp Platform Service Editors, there are two main areas: Settings at top, Time Servers at bottom.
About Ntp Platform Service Editor Win32 settings
Settings in the Ntp Platform Service Editor Win32 include the following properties:
• Enabled
If true, the host will use NTP to sync its clock with time values retrieved from other servers.

NiagaraAX-3.6
2-12
Platform Guide
Chapter 2 – Platform Services About the NtpPlatformService
April 4, 2011 About the Ntp Platform Service Editor Win32

• Sync Policy
Specifies how the host should sync, where possible choices include:
• none — available only if Enabled = false. Clock is not sync’ed with any time servers.
• ntp — available only if Enabled = true. Use NTP to sync with servers in the Time Servers list.
• domain — available only if Enabled = true and the host is a member of a Windows domain. Use
NTP to sync with domain controllers, but not with servers in Time Servers list.
• both — available only if Enabled = true and the host is a member of a Windows domain. Use
NTP to sync with domain controllers, and also with servers in Time Servers list.
• Max. Pos. Phase Correction
Maximum amount of time, in seconds, that the clock can be set forward in a sync. Default is 54000,
or 15 hours. If the service determines a larger correction is needed, an event log is created instead.
• Max. Neg. Phase Correction
Maximum amount of time, in seconds, that the clock can be set backward in a sync. Default is 54000,
or 15 hours. If the service determines a larger correction is needed, an event log is created instead.
• Min. Poll Interval
The shortest period allowed between polls, where units are in “log-base-two seconds,” or 2 to the
power of n seconds (NTP convention). For example, if this value is 10, then the interval is 2 to the
10th seconds, or 1024 seconds.
• Max. Poll Interval
The longest period allowed between polls, where units are in “log-base-two seconds,” or 2 to the
power of n seconds (NTP convention). For example, if this value is 14, then the interval is 2 to the
14th secondss, or 16384 seconds.
• Special Poll Interval
Poll interval, in seconds, for servers in the Time Servers list that have “Use Spec. Interval” set to true.
About Ntp Platform Service Editor Win32 time servers
Each entry in the time servers list in the Ntp Platform Service Editor Win32 specifies a server to which
the host’s clock will be sync’ed when the Sync Policy is either “ntp” or “both.” These servers are not used
if the Sync Policy is “none” or “domain.”
Controls below the list allow you to add and delete servers, as well as reorder up or down .
Fields for each time server includes the following:
• Address
Fully qualified domain name, IP address, or host files alias for the NTP time server.
• Use Spec. Interval
Default is false. If true, the poll interval rules specified by RFC 1305 are ignored, and the specified
Special Poll Interval is used instead.
• Fallback Only
Default is false. If true, this server is polled only if other servers cannot be reached.
• Peer Mode
Specifies the server’s sync relationship:
• unspecified — Use the system default behavior when sync’ing with the server.
• symmetricActive — Both this host’s and the server’s clocks may be changed as a result of each
sync.
• client— Only this host’s clock may be changes as a result of each sync.

NiagaraAX-3.6
2-13
Platform Guide
About the NtpPlatformService Chapter 2 – Platform Services
About the Ntp Platform Service Editor Qnx April 4, 2011

About the Ntp Platform Service Editor Qnx

An example QNX-based host Ntp Platform Service Editor is shown in Figure 2-10. This is the default
view for the NtpPlatformService on any QNX-based JACE.

Figure 2-10 Ntp Platform Service Editor Qnx

This dialog provides access to some of the key settings of the NTP daemon (ntpd) of the QNX OS running
on the host JACE platform.
As in all Ntp Platform Service Editors, there are two main areas: Settings at top, Time Servers at bottom.
Also, starting in AX-3.6, the NtpPlatformServiceQnx has an available “Sync Now” action. For more
details, see “Sync Now action” on page 2-15.
About Ntp Platform Service Editor Qnx settings
Settings in the Ntp Platform Service Editor QNX include the following properties:
• Enabled
If true, the host will use NTP to sync its clock with time values retrieved from other servers.
• Sync Local Clock to NTP
If true, this enables the host to adjust its local clock by means of NTP. If disabled (false), the local
clock free-runs at its intrinsic time and frequency offset. This flag is useful in case the local clock is
controlled by some other device or protocol and NTP is used only to provide synchronization (as
server) to other clients. In this case, the local clock driver can be used to provide this function and
also certain time variables for error estimates and leap-indicators.
• Sync Time At Boot
Default is false. If true, when the JACE boots, before the stations starts or the ntpd starts, it executes
the ntpdate command. This updates the system local time.
• Use Local Clock as Backup
If true , should the specified NTP server(s) become unavailable at the time of a poll, the time used is
provided by the system clock. This prevents the timing of the polling algorithm in the ntpd (which
is exectued at specified/changing intervals) from being reset.
• Generate NTP Statistics
If true , the NtpPlatformService reports whatever information it can about its operation. To access
these statistics with the station opened in Workbench, right-click the NtpPlatformServiceQnx and
select Views > SpyRemote. Keep in mind that the ntpd is a QNX process; thus NiagaraAX has
no control over what it reports.
About Ntp Platform Service Editor Qnx time servers
Each entry in the time servers list in the Ntp Platform Service Editor QNX specifies a server to which the
host’s clock will be sync’ed when the service is Enabled (true), and “Sync Local Clock to NTP” is also true.
These servers are not used if eitherof these properties are false.
Controls below the list allow you to add and delete servers, as well as reorder up or down (to
establish priority order, highest at top). Fields for each time server includes the following:
• Address
Fully qualified domain name, IP address, or host files alias for the NTP time server.

NiagaraAX-3.6
2-14
Platform Guide
Chapter 2 – Platform Services About the NtpPlatformService
April 4, 2011 About the Ntp Platform Service Editor Qnx

• Peer Mode
Peer mode to use with the server, as either server or peer (symmetricActive).
• Burst
False by default. If true, when server is reachable, upon each poll a burst of eight packets are sent,
instead of the usual one packet. Spacing between the first and second packets is about 16 seconds to
allow a modem call to complete, while spacing between remaining packets is about 2 seconds.
• Preferred
If true, designates a server as preferred over others for synchronization. Note also that priority order
(top highest, bottom lowest) is also evaluated if multiple servers are entered.
• Min. Poll
Minimum poll interval for NTP messages, from 4 to 16. Note units are in “log-base-two seconds,” or
2 to the power of n seconds (NTP convention), meaning from 2 to the 4th (16 seconds) to 2 to the
16th (65,536 seconds).
• Max. Poll
Maximum poll interval for NTP messages, from 10 to 17. Note units are in “log-base-two seconds,”
or 2 to the power of n seconds (NTP convention), meaning from 2 to the 10th (1,024 seconds) to 2
to the 17th (131,072 seconds).
Sync Now action
In addition to the “Poll” action present on any NtpPlatformService, starting in AX-3.6 the NtpPlat-
formServiceQnx component has an additional “Sync Now” action.

Figure 2-11 Sync Now action on NtpPlatformServiceQnx (AX-3.6 and later)

As shown in Figure 2-11, this action produces a popup Sync Now dialog, which is blank.
To use, type in the fully qualified domain name of a public NTP server (as shown above), or else the IP
address of any accessible NTP server, and then click OK.
To verify, look for a related entry in the station’s spy “platform diagnostics” log. Do this in Workbench by
right-clicking the station, then selecting Spy > platform diagnostics > log or from the
Workbench File menu, File > Open ord (Ctrl + L) and enter:
ip:JACE_IP_address|fox:|spy:/platform diagnostics/log

NiagaraAX-3.6
2-15
Platform Guide
About the NtpPlatformService Chapter 2 – Platform Services
About the Ntp Platform Service Editor Linux April 4, 2011

About the Ntp Platform Service Editor Linux

An example Linux host Ntp Platform Service Editor is shown in Figure 2-12. This is the default view for
the NtpPlatformService on a Linux Supervisor host.

Figure 2-12 Ntp Platform Service Editor Linux

This dialog provides access to some key settings of the Network Time Protocol (NTP) Daemon on the
Supervisor’s Linux OS.
Note: Settings are only a small subset of those available—for all settings, plus the ability to make changes in the
NTP Daemon, use root login access of the Linux OS on the host. Refer to the Linux documentation about
the NTP Daemon for specific details.
As in all Ntp Platform Service Editors, there are two main areas: Settings at top, Time Servers at bottom.
About Ntp Platform Service Editor Linux settings
Settings in the Ntp Platform Service Editor Linux include the following properties:
• Enabled
If true, the host will use NTP to sync its clock with time values retrieved from other servers.
• Sync Local Clock to NTP
If true, this enables the host to adjust its local clock by means of NTP. If disabled (false), the local
clock free-runs at its intrinsic time and frequency offset. This flag is useful in case the local clock is
controlled by some other device or protocol and NTP is used only to provide synchronization (as
server) to other clients. In this case, the local clock driver can be used to provide this function and
also certain time variables for error estimates and leap-indicators.
• Use Local Clock as Backup
If true , should the specified NTP server(s) become unavailable at the time of a poll, the time used is
provided by the system clock. This prevents the timing of the polling algorithm in the ntpd (which
is exectued at specified/changing intervals) from being reset.
• Generate NTP Statistics
If true , the NtpPlatformService reports whatever information it can about its operation. To access
these statistics with the station opened in Workbench, right-click the NtpPlatformServiceLinux and
select Views > SpyRemote. Keep in mind that the ntpd is a Linux process; thus NiagaraAX has
no control over what it reports.
• Authenticated Peers Only
If true (default), enables the server to synchronize with unconfigured peers only if the peer has been
correctly authenticated using a trusted key and key identifier.
• Autokey Regen Interval
Specifies the interval between regenerations of the session key list used with the autokey feature.
Note that the size of the key list for each association depends on the interval and the current poll
interval. The default value is 12 (units in NTP are in “log-base-two seconds,” or 2 to the power of n
seconds where 12 means 4096 seconds, or about 1.1 hours). For poll intervals about the specified in-
terval, a session key list with a single entry will be regenerated for every message sent.
• Autokey Revoke Interval
Specifies the interval between regenerations of the private value used with the autokey feature.
• Monitor
If true (default), enables the ntpd monitoring facility.

NiagaraAX-3.6
2-16
Platform Guide
Chapter 2 – Platform Services About the NtpPlatformService
April 4, 2011 About the Ntp Platform Service Editor Linux

About Ntp Platform Service Editor Linux time servers

Each entry in the time servers list in the Ntp Platform Service Editor Linux specifies a server to which the
host’s clock will be sync’ed when the service is Enabled (true), and “Use NTP on Server” is also true.
These servers are not used if either of these properties are false.
Controls below the list allow you to add and delete servers, as well as reorder up or down .
Fields for each time server includes the following:
• Address
Fully qualified domain name, IP address, or host files alias for the NTP time server.
• Peer Mode
Peer mode to use with the server, as either server or peer (symmetricActive).
• Auto Key
If true, all packets sent to the address include authentication field encrypted using autokey scheme.
If false, packets sent to the address include the authentication field encrypted using the specified Key
identifier.
• Key
Applies only if Auto Key is disabled (false). To specify a key identifier, as an unsigned 32-bit integer
less than 65536, used in authentication with packets set to the address.
• Burst
False by default. If true, when server is reachable, upon each poll a burst of eight packets are sent,
instead of the usual one packet. Spacing between the first and second packets is about 16 seconds to
allow a modem call to complete, while spacing between remaining packets is about 2 seconds.
• Preferred
If true, designates a server as preferred over others for synchronization. Note also that priority order
(top highest, bottom lowest) is also evaluated if multiple servers are entered.
• Min. Poll
Minimum poll interval for NTP messages, from 4 to 6. Note units are in “log-base-two seconds,” or
2 to the power of n seconds (NTP convention), meaning from 2 to the 4th (16 seconds) to 2 to the
6th (64 seconds).
• Max. Poll
Maximum poll interval for NTP messages, from 10 to 17. Note units are in “log-base-two seconds,”
or 2 to the power of n seconds (NTP convention), meaning from 2 to the 10th (1024 seconds) to 2 to
the 17th (131,072 seconds).

NiagaraAX-3.6
2-17
Platform Guide
About the NtpPlatformService Chapter 2 – Platform Services
About the Ntp Platform Service Editor Linux April 4, 2011

NiagaraAX-3.6
2-18
Platform Guide
 CHAPTER 3
Platform Component Guides
Component Guides provides summary information on platform-related components.

Component Reference Summary

Summary information is available on components in the following modules:
• platDataRecovery
• platDialup
• platGprs
• platform
• platPower
• platPowerNxs
• platSerialQnx
• platSerialWin32
• platSysmonNx
• platSysmonNxs
• platSysmonNxt
• platWifi

Components in platDataRecovery module

• DataRecoveryService

platDataRecovery-DataRecoveryService
The DataRecoveryService automatically creates and manages buffers in a JACE controller’s installed
“SRAM option card”, allowing “battery-less” operation. For details, see the “About the DataRecovery-
Service” section in the Engineering Notes II document JACE Data Recovery Service (SRAM support).

Components in platDialup module

• DialupPlatformService

platDialup-DialupPlatformService
DialupPlatformService is the station’s interface to the platform’s dialup daemon. This service is
found under the running station’s PlatformServiceContainer. For more details, see “DialupService”
on page 1-21.

Components in platGprs module

• GprsPlatformService
• GprsHostSettings
• GprsRuntimeData

platGprs-GprsPlatformService
Gprs Platform Service is the station’s interface to the platform’s GPRS daemon (gprsd). If the host
QNX-based JACE has a GPRS modem option installed, along with the platGprs module, this
service is found under the running station’s PlatformServiceContainer.

NiagaraAX-3.6
3–19
Platform Guide
Components in platform module Chapter 3 – Platform Component Guides
platGprs-GprsHostSettings April 4, 2011

Note: Starting in AX-3.6 and build 3.5.31 and later, the GprsPlatformService has a default Gprs
Platform Service Plugin view—identical to the platform view GPRS Modem Configuration.
This provides station access to modem configuration properties, and also runtime data. For details, see
“GPRS Modem Configuration” on page 1-31.
This newer GprsPlatformService also has many properties available, located under a child
GprsHostSettings container with its own GprsRuntimeData child container. Note that prior to build 3.5.26,
the GprsPlatformService has only a property sheet view, and 10 read-only properties.
For complete GPRS modem option details, refer to the Engineering Notes document “GPRS modem option”.

platGprs-GprsHostSettings
GprsHostSettings (Settings) is a container child of the GprsPlatformService in a JACE (AX-3.6 or
later, or build 3.5.31 or higher) that is equipped with a GPRS modem option. Access it under service’s
property sheet view. It contains a number of read-only properties, most of which reflect configuration, as
well as a GprsRuntimeData child container.
For more details, refer to the “GprsPlatformService (latest)” section in the Engineering Notes document
“GPRS modem option”.

platGprs-GprsRuntimeData
GprsRuntimeData (Runtime Data) is a container child of the GprsHostSettings container under the
GprsPlatformService in a JACE (AX-3.6 or later, or build 3.5.31 or higher) that is equipped with a GPRS
modem option. Access it under service’s property sheet view. It contains a number of read-only
properties.
For more details, refer to the “GprsPlatformService (latest)” section in the Engineering Notes document
“GPRS modem option”.

Components in platform module

• DaemonFileSpace
• DaemonSession
• LicensePlatformService
• NtpPlatformServiceLinux
• NtpPlatformServiceQnx
• NtpPlatformServiceWin32
• PlatformAlarmSupport
• PlatformServiceContainer
• SystemPlatformServiceQnxJavelina
• SystemPlatformServiceQnxNpm2xx
• SystemPlatformServiceQnxNpm6xx
• SystemPlatformServiceWin32
• TcpIpPlatformService

platform-DaemonFileSpace
FileSpace implementation for the files which can be accessed using the platform daemon.

platform-DaemonSession
DaemonSession represents a platform connection to a host made in Workbench. In the Nav tree
view, the DaemonSession icon is labeled Platform, and is directly under the host to which the
platform session is in progress.
The default view is the Nav Container View, which provides a table of all the various platform views.
For more details, see “Niagara platform” on page 1-1.

platform-LicensePlatformService
The LicensePlatformService provides station access to the host platform’s license(s) and certificate(s).
This service is found under the running station’s PlatformServiceContainer. From the default plugin
(view), you can perform the same operations as from the License Manager view using a platform
connection.

NiagaraAX-3.6
3-20
Platform Guide
Chapter 3 – Platform Component Guides Components in platform module
April 4, 2011 platform-NtpPlatformServiceLinux

platform-NtpPlatformServiceLinux
(AX-3.4 or later only) The NtpPlatformServiceLinux is the NiagaraAX interface to the NTP
(Network Time Protocol) daemon of the Linux OS running on a Linux Supervisor. If enabled, it
provides client and server support for NTP. The default view of this platform service is the Ntp Platform
Service Editor Linux plugin, in which you can adjust a few settings, as well as specify time servers.
For more details, see “About the NtpPlatformService” on page 2-11.

platform-NtpPlatformServiceQnx
(AX-3.4 or later only) The NtpPlatformServiceQNX is the NiagaraAX interface to the NTP (Network
Time Protocol) daemon of the QNX OS running on a JACE. If enabled, it provides client and server
support for NTP. The default view of this platform service is the Ntp Platform Service Editor Qnx plugin,
in which you can adjust a few settings, as well as specify time servers.
For more details, see “About the NtpPlatformService” on page 2-11.

platform-NtpPlatformServiceWin32
(AX-3.4 or later only) The NtpPlatformServiceWin32 is the NiagaraAX interface to the Windows
Time service (W32Time) on a Win32-based platform’s Windows OS. This Windows service uses the
SNTP (Simple Network Time Protocol) to syncronize to one or more designated time servers. The
default view of this platform service is the Ntp Platform Service Editor Win32 plugin, in which you can
adjust a few settings of the Windows Time service, including identifying NTP time servers.
For more details, see “About the NtpPlatformService” on page 2-11.

platform-Platform
Platform provides a component model of the Niagara Platform: OS, VM, framework, modules, etc.
The Platform is available under system and in any connected station.

platform-PlatformAlarmSupport
PlatformAlarmSupport is a container slot that appears for each alarmable value under a Platform
Service, such as (for a QNX-based JACE), the PowerMonitorPlatformServiceQnx, or for a JACE-NXS,
the HardwareMonitorNxsPlatformServiceWin32 (internal JACE-NXS temperature, etc).
For a QNX-based JACE, example PlatformAlarmSupport components include:
• Battery Alarm Support
To configure how “low battery level” alarms are handled in the station.
• Power AlarmSupport
To configure how “AC power loss” alarms are handled in the station.
For a JACE-NXS, example PlatformAlarmSupport components include:
• Cpu Temperature Alarm Support
Under the HardwareMonitorService, to configure how “Cpu Temperature Fail” alarms are handled
in the station.
• Ups Not Found Alarm Support
Under the PowerMonitorService, to configure how “UPS not responding” alarms (if applicable) are
handled in the station.
Properties under each PlatformAlarmSupport container are used to designate the station’s Alarm Class
to be used, and also to populate the alarm record when the specific alarm occurs. These properties work
in the same fashion as those in an alarm extension for any control point.

platform-PlatformServiceContainer
PlatformServiceContainer provides a container for a station's PlatformService instances. The
PlatformServiceContainerPlugin is its primary view. The PlatformServiceContainer is available
when online with any running station, under its Config, Services folder. For more details, see
“PlatformServiceContainer parameters” on page 2-2.

platform-SystemPlatformServiceQnxJavelina
SystemPlatformServiceQnxJavelina is the QNX implementation of SystemPlatformService in a
station running on a JVLN-based (JACE-700) controler. For more details, see “SystemService (under
PlatformServices)” on page 2-7.

NiagaraAX-3.6
3-21
Platform Guide
Components in platPower module Chapter 3 – Platform Component Guides
platform-SystemPlatformServiceQnxNpm2xx April 4, 2011

platform-SystemPlatformServiceQnxNpm2xx
SystemPlatformServiceQnxNmp2xx is the QNX implementation of SystemPlatformService in a
station running on a NPM2-based JACE controller. For more details, see “SystemService (under
PlatformServices)” on page 2-7.

platform-SystemPlatformServiceQnxNpm6xx
SystemPlatformServiceQnxNmp6xx is the QNX implementation of SystemPlatformService in a
station running on a NPM6-based JACE controller. For more details, see “SystemService (under
PlatformServices)” on page 2-7.

platform-SystemPlatformServiceWin32
SystemPlatformServiceWin32 is the Win32 implementation of SystemPlatformService. For more
details, see “SystemService (under PlatformServices)” on page 2-7.
Reboot action
Reboot action causes a system reboot. This is not available in Win32 systems if the platform authenti-
cation setting labeled “Stations - allow stations to have admin access to platform daemon” is disabled. See
Figure 1-58 on page 42 and the discussion following it for more details.

platform-TcpIpPlatformService
TcpIpPlatformService provides station access to the host platform’s TCP/IP settings. This service is
found under the running station’s PlatformServiceContainer. From the default plugin (view), you can
perform the same operation as from the TCP/IP Configuration view using a platform connection.
If a Win32 host and the platform authentication setting labeled “Stations - allow stations to have admin
access to platform daemon” is disabled, TCP/IP properties in this view are read-only. See Figure 1-58 on
page 42.

Components in platPower module

• JaceSlaBattery
• JavelinaBatteryPlatformService
• Npm2NimhBattery
• NpmDualBatteryPlatformService
• NpmExternalSlaBattery
• PowerMonitorPlatformServiceQnx

platPower-ExternalSlaBattery
ExternalSlaBattery is one of two “Battery” slots in the JavelinaBatteryPlatformService in a JACE-700
(JACE-7 series) controller station’s PlatformServices container. This slot indicates the host JACE
platform can use an optional, sealed-lead acid (SLA) battery, in addition to the onboard NiMH backup
battery.

platPower-JaceSlaBattery
JaceSlaBattery is the “Battery” slot under the PowerMonitorService in a JACE-4 or JACE-5 series
station’s PlatformServices container. This slot simply indicates the host JACE platform uses a sealed lead
acid type (SLA) battery.

platPower-JavelinaBatteryPlatformService
JavelinaBatteryPlatformService (PowerMonitorService) applies to a station running in a JACE-700
(JACE-7 series) controller. It can monitor primary power status and backup battery levels in both the
onboard 12V NiMH battery and an optional 12V sealed-lead acid (SLA) battery. In addition, it can
monitor alarm contacts of an external, customer-supplied UPS— if enabled and wired to the two corre-
sponding onboard contact inputs (CIs) of the controller. Note the JACE-7 controller has three onboard
CIs, with the intended use for UPS AC power lost, UPS low battery, and (door) tamper switch.
Note: The tamper switch CI on the JACE-7 controller is enabled/monitored by two properties in the PowerMon-
itorService’s parent PlatformServiceContainer).
Configuration properties in this PowerMonitorService allow changing the shutdown delay time, and also
specifying whether external equipment is connected (12V SLA battery, UPS). Separate alarm source
configuration properties are available for all five types of alarms (low NiMH battery level, low SLA battery
level, primary power lost, UPS AC power lost, UPS low battery).

NiagaraAX-3.6
3-22
Platform Guide
Chapter 3 – Platform Component Guides Components in platPowerNxs module
April 4, 2011 platPower-NimhBattery

Typically, support is enabled and configured at JACE commissioning time. For related details, see “JACE
power monitoring configuration” in the latest JACE NiagaraAX Install & Startup Guide.

platPower-NimhBattery
NimhBattery is a “Battery” container slot under the PowerMonitorService in a JACE-700 (JACE-7
series) station’s PlatformServices container. This slot indicates the host JACE platform uses a nickel-
metal hydride (NiMH) battery. Included are two status properties that show the current “State” (Idle,
Charging, Discharging, Unknown) and “Charge Time Left” (in hours and minutes, if state is charging).

platPower-Npm2NimhBattery
Npm2NimhBattery is a “Battery” container slot under the PowerMonitorService in a JACE-2/6 series
or JACE-x02 Express (NPM2 or NPM6) station’s PlatformServices container. This slot indicates the host
JACE platform uses a nickel-metal hydride (NiMH) battery. Included are two status properties that show
the current “State” (Idle, Charging, Discharging, Unknown) and “Charge Time Left” (in hours and
minutes, if state is charging).
This slot also appears in the NpmDualBatteryPlatformService (“dual battery” PowerMonitorService) of
a JACE that is capable and enabled for dual battery support.

platPower-NpmDualBatteryPlatformService
NpmDualBatteryPlatformService (PowerMonitorService) applies to a station running in a JACE
platform that is capable and enabled for “dual battery” support, such as a JACE-x02 Express series
(M2M JACE). It is used to monitor primary power status and backup battery levels in both the onboard
NiMH battery as well as the optional sealed-lead acid (SLA) battery. A few configuration parameters
allow changing the shutdown delay time, as well as alarm source configuration for all three types of
alarms (low NiMH battery level, low SLA battery level, primary power lost).
Typically, support is enabled and configured at JACE commissioning time. For related details, see “JACE
power monitoring configuration” in the latest JACE NiagaraAX Install & Startup Guide.

platPower-NpmExternalSlaBattery
NpmExternalSlaBattery is one of two “Battery” slots under the NpmDualBatteryPlatformService in a
“dual battery enabled” JACE’s station’s PlatformServices container. This slot simply indicates the host
JACE platform can use an optional, sealed-lead acid (SLA) battery, in addition to the onboard NiMH
backup battery.

platPower-PowerMonitorPlatformServiceQnx
PowerMonitorPlatformServiceQnx (PowerMonitorService) is used to monitor the primary power
status and backup battery level in many QNX-based JACEs. A few configuration parameters allow
changing the shutdown delay time, as well as alarm source configuration for both types of alarms (low
battery level, primary power lost).
This PowerMonitorService is found under the PlatformServiceContainer in a station running on any
QNX-based JACE except for those models that are capable and/or enabled for “dual battery” support.
Typically, support is enabled and configured at JACE commissioning time. For related details, see “JACE
power monitoring configuration” in the latest JACE NiagaraAX Install & Startup Guide.

Components in platPowerNxs module

platPowerNxs-PowerMonitorPlatformServiceNxsWin32
PowerMonitorPlatformServiceNxsWin32 (PowerMonitorService) is used to monitor the status of
primary power, UPS communications, and UPS battery condition for a JACE-NXT or JACE-NXS.
Configuration parameters allow changing the shutdown delay time, as well as alarm source configuration
for all three types of alarms (low battery level, primary power lost, UPS communications).
The PowerMonitorService is found under the PlatformServiceContainer in a station running on any
JACE-NXT or JACE-NXS. See “Using platform services in a station” on page 2-8 for related details. For
specific details, see the section “Power monitoring configuration in JACE-NXT” or “Power monitoring
configuration in JACE-NXS” in the appropriate JACE-NXT (or JACE-NXS) NiagaraAX Install & Startup
Guide.

NiagaraAX-3.6
3-23
Platform Guide
Components in platSerialQnx module Chapter 3 – Platform Component Guides
platSerialQnx-SerialPortPlatformServiceQnx April 4, 2011

Note: This service applies to any CompactFlash-based JACE-NXT or JACE-NXS, which includes the special
“SITOP” DC UPS and UPS battery modules. However, if a hard drive-based unit (installed without this
UPS option), you can safely ignore this service, and its contained slots.

Components in platSerialQnx module

• SerialPortPlatformServiceQnx
• SerialPortPlatformServiceQnx403
• SerialPortPlatformServiceQnx404

platSerialQnx-SerialPortPlatformServiceQnx
SerialPortPlatformServiceQnx is the station’s interface to the platform’s serial port configuration,
such as used by a JACE-2,-6,-7 series host. This service is found under the running station’s Platform-
ServiceContainer as the Serial Port Service.

platSerialQnx-SerialPortPlatformServiceQnx403
SerialPortPlatformServiceQnx403 is the station’s interface to the platform’s serial port configu-
ration, in this case specific to to a JACE-403 series host. This service is found under the running
station’s PlatformServiceContainer as the Serial Port Service.

platSerialQnx-SerialPortPlatformServiceQnx404
SerialPortPlatformServiceQnx404 is the station’s interface to the platform’s serial port configu-
ration, in this case specific to a JACE-545 series host. This service is found under the running
station’s PlatformServiceContainer as the Serial Port Service.

platSerialQnx-SerialPortQnx
SerialPortQnx contains properties that describe how a serial port (RS-232 or RS-485) on a QNX-
based JACE is being used in software as COMn. Each one is a child of that JACE’s SerialPortService
(SerialPortPlatformServiceQnx). Properties are as follows:
• Owner — The driver network or function currently associated with that COM port, for example,
“NrioNetwork”, “dialup”, “none”, “ModbusAsyncNetwork”, or “dbgjmpr” (latter in-
dicated for COM1 when “serial shell” jumper is installed on JACE).
• Os Port Name — How the port is known to the QNX OS and associated low-level drivers.
• Port Index — Unique serial port index number, starting with 1 for COM1.

Components in platSerialWin32 module

platSerialWin32-SerialPortPlatformServiceWin32
SerialPortPlatformServiceWin32 is the station’s interface to the platform’s serial port configuration,
used by any Win32 (Windows XP) based host, such as a JACE-NXS or Supervisor PC. This service
is found under the running station’s PlatformServiceContainer as the Serial Port Service.

platSerialWin32-SerialPortWin32
SerialPortWin32 contains properties that describe how a serial port (RS-232 or RS-485) on a Win32-
based host is being used in software as COMn. Each one is a child of that host’s SerialPortService
(SerialPortPlatformServiceWin32). Properties are as follows:
• Owner — The driver network or function currently associated with that COM port, for example,
“ModbusSlaveNetwork” or “none”.
• Os Port Name — How the port is known to the Windows operating system, e.g. COM1 or COM3.
• Port Index — Unique serial port index number, starting with 0 for COM1.

Components in platSysmonNx module

platSysmonNx-HardwareMonitorNxPlatformServiceWin32
HardwareMonitorNxPlatformServiceWin32 (HardwareMonitorService) is the station’s interface to
internal environmental parameters in the host JACE-NX, such as CPU temperature, fan speeds, and
various voltages. This service appears under the running station’s PlatformServiceContainer as the
Hardware Monitor Service.

NiagaraAX-3.6
3-24
Platform Guide
Chapter 3 – Platform Component Guides Components in platSysmonNxs module
April 4, 2011 platSysmonNxs-HardwareMonitorNxsPlatformServiceWin32

See “Using platform services in a station” on page 2-8 for related details. For specific details, see the
section “Hardware monitoring JACE-NX configuration” in the JACE-NX NiagaraAX Install & Startup
Guide.

Components in platSysmonNxs module

• HardwareMonitorNxsPlatformServiceWin32

platSysmonNxs-HardwareMonitorNxsPlatformServiceWin32
HardwareMonitorNxsPlatformServiceWin32 (HardwareMonitorService) is the station’s interface
to internal environmental parameters in any JACE-NXS host, namely the CPU temperature and
board temperature. This service appears under the running station’s PlatformServiceContainer as the
Hardware Monitor Service.
For more details, see the section “Hardware monitoring JACE-NXS configuration” in the JACE-NXS
NiagaraAX Install & Startup Guide.

Components in platSysmonNxt module

• HardwareMonitorNxtPlatformServiceWin32

platSysmonNxt-HardwareMonitorNxtPlatformServiceWin32
HardwareMonitorNxtPlatformServiceWin32 (HardwareMonitorService) is the station’s interface
to internal environmental parameters in any JACE-NXT host, namely the CPU temperature and
board temperature. This service appears under the running station’s PlatformServiceContainer as the
Hardware Monitor Service.
For more details, see the section “Hardware monitoring JACE-NXT configuration” in the JACE-NXT
NiagaraAX Install & Startup Guide.

Components in platUsbmon module

• UsbMonitorPlatformServiceQnx

platUsbmon-UsbMonotorPlatformServiceQnx
UsbMonitorPlatformServiceQnx (Usb Monitor Platform Service) is the station’s interface to low-
level details from monitoring USB ports on the host JACE-7 (JVLN) platform. If client applications
are installed that interface with this service, notifications may occur when USB devices are inserted or
removed.

Components in platWifi module

platWifi-WifiPlatformService
(AX-3.6 and later) WifiPlatformService is the station’s interface to a WiFi-equipped JACE,
providing views to discover and connect to a wireless 802.11 network, as well as a “secondary view”
to install CA (Certificate Authority) certificate files and client private key files on the JACE. Note the
latter view is typically not needed, unless installing the JACE on an “enterprise level” wireless network
that uses either WPA or WPA2 security, based upon digital certificates.
The WifiPlatformService automatically appears in the station’s PlatformServices if the controller
has a WiFi adapter—at the time of this document, this means a JACE-700 series (JVLN) controller with
a WiFi option. For general information, see “WiFi Configuration” on page 1-74.
Note: For complete details, refer to the Engineering Notes document “NiagaraAX JACE WiFi option”.

NiagaraAX-3.6
3-25
Platform Guide
Components in platWifi module Chapter 3 – Platform Component Guides
platWifi-WifiPlatformService April 4, 2011

NiagaraAX-3.6
3-26
Platform Guide
 CHAPTER 4
Platform Plugin Guides
There are many ways to view plugins (views). One way is directly in the tree. In addition, you can right-
click on an item and select one of its views. Plugins provide views of components.
Access the following summary descriptions on any plugin by selecting Help > On View (F1) from the
menu, or by pressing F1 while the view is open.

Plugin Reference Summary

Summary information is provided on views in the following modules:
• platDaemon
• platDataRecovery
• platDDNS
• platDialup
• platform
• platGprs
• platWifi

Plugins in platDaemon module

• ApplicationDirector
• DaemonLogSettingsView
• DistInstaller
• DistributionView
• FileTranferClient
• LexiconInstaller
• LicenseManager
• SoftwareManager
• SoftwareView
• PlatformAdministration
• PlatformTextSummaryEditor
• StationCopier
• StationDirector
• TcpIpConfiguration
• UserManager

platDaemon-ApplicationDirector
The Application Director (formerly: Station Director) is the AX-3.3 and later platform view
that allows you to start, stop, restart, and kill a station on the connected NiagaraAX platform. You
also use it to examine standard station output, for troubleshooting and debug purposes. Starting in AX-
3.3, along with the renaming to Application Director, limited support began for starting,
stopping, and monitoring Sedona apps—however, Sedona platform support now uses a Sox connection.
For more details, see “Application Director” on page 1-10.

platDaemon-DaemonLogSettingsView
DaemonLogSettingsView allows you to view the log settings.

NiagaraAX-3.6
4–27
Platform Guide
Plugins in platDaemon module Chapter 4 – Platform Plugin Guides
platDaemon-DistInstaller April 4, 2011

platDaemon-DistInstaller
DistInstaller allows you to install distribution files from this computer to the remote host. For more
details, see “Distribution File Installer” on page 1-24.

platDaemon-DistributionView
Distribution View is the dialog that appears when you double-click a distribution file listed in the
platform’s Distribution File Installer view. A number of details is provided about the selected distri-
bution file, including all contents and any dependencies.

platDaemon-FileTransferClient
The File Transfer Client is the platform view that allows you to copy files and/or folders between
your Workbench PC and the remote Niagara platform, as needed. For more details, see “File Transfer
Client” on page 1-30.

platDaemon-LexiconInstaller
Lexicon Installer allows you to install lexicon files (for Niagara localization) on a remote host. For
more details, see “Lexicon Installer” on page 1-33.

platDaemon-LicenseManager
License Manager allows you to view and install files required for Niagara licensing. For more details,
see “License Manager” on page 1-34.

platDaemon-SoftwareManager
The Software Manager is the platform view you use to install, upgrade, or remove modules in the
connected Niagara platform. For more details, see “Software Manager” on page 1-50.

platDaemon-SoftwareView
Software View is the dialog that appears when you double-click an item (for example, module) listed
in the platform’s Software Manager view. A number of details is provided about the selected item.

platDaemon-PlatformAdministration
The Platform Administration view provides access to various platform daemon (and host) settings
and summary information. Included are buttons to perform various platform operations. For more
details, see “Platform Administration” on page 1-38.

platDaemon-PlatformTextSummaryEditor
PlatformTextSummaryEditor is the dialog that appears when you click the export tool button when
using the Platform Administration view. Setup in this dialog allows you to include/exclude the
platform summary data and the platform daemon console output, as well as limit daemon output.

platDaemon-StationCopier
The Station Copier is the platform view that you use to install a station in a remote JACE host, as
well as make a local backup copy of a remote JACE station onto your Workbench PC. You can also
delete stations using this view. For more details, see “Station Copier” on page 1-57.

platDaemon-StationDirector
The Station Director is the pre-AX-3.3 platform view that allows you to start, stop, restart, and kill
a station on the connected NiagaraAX platform. You also use it to examine standard station output,
for troubleshooting and debug purposes. Starting in AX-3.3, this view was renamed to the Appli-
cation Director, but functionality for stations (NiagaraAX applications) remained unchanged.
For more details, see “Application Director” on page 1-10.

platDaemon-StationTextSummaryEditor
StationTextSummaryEditor is the dialog that appears when you click the export tool button when
using the Application Director view. Setup in this dialog allows you to include/exclude the platform
summary data, platform daemon console output, station console output, as well as limit both the daemon
and station output.

NiagaraAX-3.6
4-28
Platform Guide
Chapter 4 – Platform Plugin Guides Plugin in platDataRecovery
April 4, 2011 platDaemon-TcpIpConfiguration

platDaemon-TcpIpConfiguration
TCP/IP Configuration is the platform view you use configure a remote JACE host’s TCP/IP settings.
Typically, you make initial settings when you first commission the JACE, where this view is one step
in the platform’s Commissioning Wizard.
For more details, see “TCP/IP Configuration” on page 1-66.

platDaemon-UserManager
The User Manager is a platform view available only for Win32 based hosts (e.g. JACE-NXS). It allows
you to manage Windows OS user and group accounts local to that host, which otherwise would require
accessing “Administrative Tools” in Windows on that host.
For more details, see “User Manager” on page 1-71.

Plugin in platDataRecovery
• DataRecoveryServiceEditor

platDataRecovery-DataRecoveryServiceEditor
The Data Recovery Service Editor is the default view on the DataRecoveryService, as found
in a JACE with an installed “SRAM option card”. This view allows monitoring of the “battery-less”
support provided by this service. For details, see the “About the DataRecoveryService” section in the
Engineering Notes II document JACE Data Recovery Service (SRAM support).

Plugin in platDDNS
platDdns-DdnsConfigurationView
Ddns Configuration allows for DNS IP addresses to be dynamically updated. For more details, see
“Ddns Configuration” on page 1-16.

Plugins in platDialup
platDialup-ConfigureDialup
Dialup Configuration is to configure a host’s modem and “captive network” settings. For more
details, see “Dialup Configuration” on page 1-18.

platDialup-DialupEditor
DialupEditor allows you to configure the dialup parameters for the connected host.

Plugins in platform module

• ActivityView
• LicensePlatformServicePlugin
• Ntp Platform Service Editor Linux
• Ntp Platform Service Editor Qnx
• Ntp Platform Service Editor Win32
• PlatformServiceContainerPlugin
• PlatformServiceProperties
• SystemPlatformServicePlugin
• SystemPlatformServiceQnxPlugin
• TcpIpPlatformServicePlugin

platform-ActivityView
The ActivityView allows you to view the items in the platform.

platform-LicensePlatformServicePlugin
LicensePlatformServicePlugin allows you to manage the host's licenses and certificates under a
station’s PlatformServiceContainer.

NiagaraAX-3.6
4-29
Platform Guide
Plugins in platGprs Chapter 4 – Platform Plugin Guides
platform-NtpPlatformServiceEditorLinux April 4, 2011

platform-NtpPlatformServiceEditorLinux
Ntp Platform Service Editor Linux is the default view of a station’s NtpPlatformServiceLinux, which
provides the platform interface to the NTP daemon (process) running on a Linux-based host. This
view provides access to a few related settings, plus allows specifying one or more remote time servers.
For more details, see “About the Ntp Platform Service Editor Linux” on page 2-16.

platform-NtpPlatformServiceEditorQnx
Ntp Platform Service Editor Qnx is the default view of the station’s NtpPlatformServiceQnx, which
provides the platform interface to the NTP daemon (process) running on a QNX-based JACE. This
view provides access to a few related settings, plus allows specifying one or more remote time servers.
For more details, see “About the Ntp Platform Service Editor Qnx” on page 2-14.

platform-NtpPlatformServiceEditorWin32
Ntp Platform Service Editor Win32 is the default view of the station’s NtpPlatformServiceWin32,
which provides the platform interface to the Windows Time service (W32Time) running on the host
platform’s Windows OS. This Windows service uses the SNTP (Simple Network Time Protocol) to
syncronize to one or more designated time servers.
For more details, see “About the Ntp Platform Service Editor Win32” on page 2-12.

platform-PlatformServiceContainerPlugin
PlatformServiceContainerPlugin allow you to view and edit information about the Platform. It
includes the following:
• System - System Settings
• LON - LON settings
• Comm - Serial Communications
For more details, see “About Platform Services” on page 2-1.

platform-PlatformServiceProperties
PlatformServiceProperties allows you to configure a remote host’s serial port properties or power
monitoring properties under a station’s PlatformServiceContainer.

platform-SystemPlatformServicePlugin
System PlatformService Plugin allows you to view and edit information about the system.

platform-SystemPlatformServiceQnxPlugin
SystemPlatformServiceQnxPlugin provides station access to platform parameters on QNX-based
hosts.

platform-TcpIpPlatformServicePlugin
TcpIpPlatformServicePlugin allows you to manage the host's TCP/IP settings under a station’s
PlatformServiceContainer. Settings include Hostname, Domain, the Hosts file and Interfaces.

Plugins in platGprs
platGprs-GprsConfiguration
Gprs Configuration (GPRS Modem Configuration) is the platform view used to configure the
wireless GPRS modem option card that may be installed in the host JACE. For general details, see
“GPRS Modem Configuration” on page 1-31.
Note: For complete details, refer to the Engineering Notes document “GPRS modem option”.

platGprs-GprsPlatformServicePlugin
The Gprs Platfrom Service Plugin is the default view on the GprsPlatformService
in a station running on a JACE with a wireless GPRS modem option card installed (AX-3.6, or build
3.5.35 or later). It provides the identical interface as the platform view GPRS Modem Configuration.
For general details, see “GPRS Modem Configuration” on page 1-31.
• Prior to build 3.5.35, this view is not available. The service’s default view is its property sheet.
• For complete details, refer to the Engineering Notes document “GPRS modem option”.

NiagaraAX-3.6
4-30
Platform Guide
Chapter 4 – Platform Plugin Guides Plugins in platWifi module
April 4, 2011 platWifi-WifiConfiguration

Plugins in platWifi module

platWifi-WifiConfiguration
(AX-3.6 and later) Wifi Configuration is the platform view available in a WiFi-equipped JACE
to discover and connect to a wireless 802.11 network. This platform view appears only if the
controller has a WiFi adapter—at the time of this document, this means a JACE-700 series (JVLN)
controller with a WiFi option. For general information, see “WiFi Configuration” on page 1-74.
Note: For complete details, refer to the Engineering Notes document “NiagaraAX JACE WiFi option”.

platWifi-WifiPlatformServicePlugin
(AX-3.6 and later) The Wifi Platform Service Plugin is the default view on a station’s
WifiPlatformService, and is identical to the platform Wifi Configuration view. The
platform service is available in a WiFi-equipped JACE, to discover and connect to a wireless 802.11
network. At the time of this document, this means a JACE-700 series (JVLN) controller with a WiFi
option. For general details, see “WiFi Configuration” on page 1-74.
Note: For complete details, refer to the Engineering Notes document “NiagaraAX JACE WiFi option”.

platWifi-WifiSecurityManager
(AX-3.6 and later) Wifi Certificate Manager (WifiSecurityManager) is the platform view
available in a WiFi-equipped JACE to import CA (Certificate Authority) certificates and client
private key files. This can allow the JACE to access to an “enterprise level” wireless 802.11 network that
uses either WPA or WPA2 security with digital certificates. For general information, see “WiFi Certificate
Manager” on page 1-75.
This view is also a secondary view on a station’s WifiPlatformService, with the primary view the
WifiPlatformServicePlugin.
Note: For complete details, refer to the Engineering Notes document “NiagaraAX JACE WiFi option”.

NiagaraAX-3.6
4-31
Platform Guide
Plugins in platWifi module Chapter 4 – Platform Plugin Guides
platWifi-WifiSecurityManager April 4, 2011

NiagaraAX-3.6
4-32
Platform Guide
 APPENDIX A
License Tools and Files
This appendix provides details about the Workbench tools related to NiagaraAX license files, including
license-management. Also included are details on the contents of license files.
The following subsections are included:
• License-related Workbench tools
Unlike platform views (which require a platform connection), or equivalent PlatformServices plugin
views (requiring a station connection), Workbench tools are available whenever running full Work-
bench. Find Workbench tools on the Tools menu, as shown in Figure A-1.
• Workbench License Manager tool
• Request License tool

Figure A-1 Tools menu in Workbench

• License management topics (in addition to Workbench License tools):

• local license database
• license archive (.lar) files
• About NiagaraAX license files
• Items common to all license files
• JACE hardware features
• Driver attributes
• Driver types
• Applications

NiagaraAX-3.6
A–1
Platform Guide
Workbench License Manager Appendix A – License Tools and Files
April 4, 2011

Workbench License Manager

The Workbench License Manager view is available via the Workbench Tools menu, by selecting
Local License Database.

Figure A-2 Workbench License Manager

As shown in Figure A-2, this view lets you browse and manage the contents of your “local license
database.”
Note: For details about the license database structure, see “About the local license database” on page A-6.
This view provides a two-pane window into all the license files and parent “host ID” folders, where
• Left pane provides tree navigation, where you can expand folders and click (to select) license files.
• Right pane shows the text contents of any selected license file.
Buttons at the bottom of this view provide a way to manage the contents of your local license database,
and are described as follows:
• Import File — Always available, this allows you to add license file(s) from a local license file or license
archive (.lar) file.
• Export File — Always available, this allows you to save all licenses (or any selected licenses) locally,
as a license archive file.
• Delete — This allows you to delete licenses from your Workbench local license database.
• Sync Online — Typically available if you have Internet connectivity. This lets you update all licenses
(or any selected licenses) in your local license database with the most current versions, via the online
licensing server.

Import File
The Import File button in the Workbench License Manager is always enabled, and produces the
Import License dialog for you to navigate to a source file (.license or .lar), as shown in
Figure A-3. Note only these two types of files appear for selection.

Figure A-3 Import License dialog to find local license file or license archive file

Select a license file and click OK to add to (or update in) your local license database. A popup dialog
(Figure A-4) informs you of success, and the license(s) are added or updated in your database.

NiagaraAX-3.6
A-2
Platform Guide
Appendix A – License Tools and Files Export File
April 4, 2011

Figure A-4 Import success

Note: If any of the license(s) you select to import are older than the ones currently in your local database, meaning
that the “generated” attribute timestamp is earlier, newer license(s) in your local license database are not
overwritten. However, the same “Import successful” message popup appears for such file import operations.

Export File
The Export File button in the Workbench License Manager allows you to save any number (or all)
licenses in your local license database locally on your Workbench PC, as a license archive (.lar) file.
Note: The license archive format allows you to easily share saved .lar files (however named) among multiple
Workbench PCs without overwriting a license file for a different host platform. You can use the Import File
command in the Workbench License Manager to add/update licenses in a license archive, or the equivalent
Import command when in the platform License Manager (or similar License Platform Service Plugin).
For more details, see “About license archive (.lar) files” on page A-7.
If you click Export File without first selecting any licenses (and/or) host IDs, every license in your
local license database will be included in the archive, as noted in a confirmation dialog. See Figure A-5.

Figure A-5 Export All Licenses confirmation dialog

Or, you can select one or more entries in the left pane (host IDs or license files) to include only those
selected (highlighted) licenses to be in the exported archive file.
When you click Yes (if all) or Export File for selected licenses, an Export Licenses dialog
(Figure A-6) lets you navigate to the spot to save the .lar file.

Figure A-6 Export Licenses dialog

By default, a license archive file is saved in the root of your Niagara release directory. Use the dialog’s
navigation controls to specify another target folder or drive, as needed. Before saving, you can also
rename the license archive file, to make it more identifiable. For example, instead of: licenses.lar,
you could rename it MyJaceNxs.lar.
Upon export of license(s) to a license archive file, a popup dialog appears, as shown in Figure A-7.

NiagaraAX-3.6
A-3
Platform Guide
Delete Appendix A – License Tools and Files
April 4, 2011

Figure A-7 Export file success

Delete
The Delete button in the Workbench License Manager is enabled when you have one or more host IDs
and/or license files selected in the left pane, and produces a confirmation dialog to delete licenses from
your local license database, as shown in Figure A-8.

Figure A-8 Delete licenses confirmation

Click Yes to delete the license(s), or No to leave the local license database unchanged.
Note: Following a delete, you may need to click the Refresh button in order to update the left pane contents.
Note that if the selected “host ID” folder contained only a .license file, the entire folder is removed with
a delete. However, if the folder contained other files (or subfolders), only the .license file is actually
deleted, but it will no longer appear in the left pane.

Sync Online
The Sync Online feature in the Workbench License Manager allows you to update any number (or all)
licenses in your local license database with the most current license, available online from the licensing
server. This feature requires Internet connectivity from your Workbench PC.
Note: For related details, see “About the licensing server” on page 1-37.
If you click Sync Online without first selecting any licenses (and/or) host IDs, every license in your
license database will be included in the sync request, as noted in a confirmation dialog. See Figure A-9.

Figure A-9 Sync All Licenses confirmation dialog

Or, you can select one or more entries in the left pane (host IDs or license files) to include only those
selected (highlighted) licenses to be included in the sync request.
When you click Yes (if all) or Sync Online for selected licenses, an immediate request is sent to the
licensing server. Intermediate popup dialogs may briefly appear while the sync request is handled. The
operation concludes with a Synchronization Complete dialog, which summarizes the number of
licenses and certificate files updated in your Workbench local license database. See Figure A-10.

Figure A-10 Synchronization Complete dialog

If all licenses (and certificates) were already up-to-date, this dialog will say “0 licenses and 0 certif-
icates updated”.

NiagaraAX-3.6
A-4
Platform Guide
Appendix A – License Tools and Files Request License
April 4, 2011

Request License
The “Request License” item on the Workbench Tools menu (Figure A-1 on page 1) simply opens a
“license request form” in your Workbench PC’s default browser. By default, the only pre-filled field in this
form is the host ID of your Workbench PC. See Figure A-11.

Figure A-11 License request form in browser (from Workbench, Tools > Request License)

Typically, your Workbench PC is already licensed. Otherwise, you would not be able to successfully start
Workbench, and then select Request License from the “Tools” menu.
However, you could use this as quick method to request a license for another PC on which you have
installed NiagaraAX. In that case, you could substitute (type in) the host ID for the other PC in this form,
along with other pertinent information.

NiagaraAX-3.6
A-5
Platform Guide
About the local license database Appendix A – License Tools and Files
April 4, 2011

About the local license database

Any Workbench PC (including an Supervisor) has a “local license database” that is a structured collection
of subdirectories and file under its Niagara release (system home) !/licenses/db directory. Each
subdirectory has a unique NiagaraAX “host ID” name, matching that for some remote host platform.
Figure A-12 shows an example of this license database structure, as viewed in the Workbench Nav tree.

Figure A-12 Workbench local license database is everything under !/licenses/db

Your local license database is created and managed automatically by Workbench, and updated whenever
you perform license operations from platform connections, PlatformService plugins, or when using
Workbench tools such as the Workbench License Manager. Note that you can see the same directory/file
structure when looking at this location on your Workbench PC using Windows Explorer.
Note: The license required for your (local) Workbench PC operation is in the root of the licenses folder, named
simply by your brand, for example Tridium.license.
For details on the Workbench License Manager, see “Workbench License Manager” on page A-2.

Local license database rationale

The local license database design makes it easier for Workbench to store licenses for multiple host
platforms—without inadvertently overwriting one license file with another. Unlike in older Workbench
releases, you do not have to manually create special license folders (subdirectories), and/or rename
license files uniquely. The related “license archive” storage file format (.lar) also facilitates the exchange
of licenses among different Workbench PCs, and is used in updating/synchronizing licenses to the online
licensing server, as well as with provisioning features for Niagara Networks. See “About license archive
(.lar) files” on page A-7.

Local license inbox

In addition to the !licenses/db folder, there is also a !licenses/inbox folder. The inbox allows
“drag and drop” importing into your license database of both individual license files and “license archive”
(.lar) files, which may have been “saved” or “exported” from other Workbench computers, or perhaps sent
to you from the licensing server.
When you restart Workbench after copying license files and/or .lar files into your inbox subfolder,
Workbench automatically creates the appropriate “host ID” named subfolders in your local license
database, each containing the corresponding license file. Contents of the inbox folder are then deleted.
Note: If you upgraded Workbench (or an Supervisor) from a release prior to AX-3.3, this inbox feature is partic-
ularly useful. Simply copy all your license files you previously stored (from whatever locations) into your
Workbench computer’s !licenses/inbox folder, renaming files if necessary (to permit copying). After
you restart Workbench, your local license database will be correctly structured. In addition, now you can
use the “Sync Online” feature of the Workbench License Manager to ensure you have the latest version of
all your licenses. See “Sync Online” on page A-4.

NiagaraAX-3.6
A-6
Platform Guide
Appendix A – License Tools and Files About license archive (.lar) files
April 4, 2011

About license archive (.lar) files

When you use the platform License Manager view or Workbench’s Workbench License Manager view
(under Tools) to export one or more license files, they are saved in a compressed (Zip compatible) format
known as a license archive, that is a file with a “.lar” file extension. Any .lar file is simply a zip of the
exported license file(s) that includes the complete “licenses/hostID” folder (subdirectory) structure
for any included licenses. See Figure A-13 for an example.

Figure A-13 License archive (.lar) is license file(s) in zip format, including folder paths relative to sys home.

Figure A-13 shows a .lar file in Windows Explorer being opened using WinZip, and its subsequent
contents. In this case where the archive contains multiple licenses, it was created by an export performed
using the Workbench License Manager tool. However, if you export a license in the License Manager
when platform-connected to a remote host, the license archive file contains just that one license.

Licensing server use of license archives

The NiagaraAX licensing server also uses the “license archive” (.lar) format when it sends out license files,
as a file attachment to emails.
• You can simply use the Import File command in your Workbench License Manager view (in
your Tools menu) to copy in the licenses.lar. This adds or updates those licenses in your local
license database. You can then import licenses from your local license database when either platform
(or station) connected.
Or, if your Workbench PC is Internet-connected while using the platform License Manager (or a sta-
tion’s equivalent PlatformServices, License Manager view) you can use the Import command and se-
lect “Import licenses from the licensing server,” which installs the updated license in the host
platform, and updates your local license database at the same time.
• Alternatively, you can unzip the contents of the licenses.lar under your !\licenses folder, and
use the Install File command in the License Manager to install licenses.

About NiagaraAX license files

A NiagaraAX license file is a structured XML file that has a .license file extension. It enables a set of
vendor specific features. Each license file is valid for one specific host platform (JACE, PC), matched by
that host’s unique host ID. License files are “digitally signed” by the vendor to prevent tampering.
The following sections provide more details on the contents of any license file that validates against the
Tridium certificate:
• Items common to all license files (license, about, brand, signature)
• JACE hardware features (maxheap, mstp, ndio, serial)
• Driver attributes (name, expiration, device.limit, history.limit, point.limit, schedule.limit, parts)
• Driver types (many types, including bacnet, lonworks, modbusTcp, obixDriver, niagaraDriver)
• Applications (crypto, eas, email, genericAppliance, provisioning, station, tenantBilling, web, work-
bench)

NiagaraAX-3.6
A-7
Platform Guide
Items common to all license files Appendix A – License Tools and Files
April 4, 2011

Items common to all license files

license
All license files require an opening <license > line, where the last line in the license file is the closing
</license> tag, and all contents (lines) in between are <feature > elements, plus one signature
element.
In the first <license > line, there are a number of common attributes, described below.
<license version="3.2" vendor="Tridium" generated="2007-04-11"
expiration="2008-03-31" hostId="Win-6827-91CB-C49A-6B4B" serialNumber="4856">
version version="3.2" - The highest release version of software which can be installed in the JACE. If
a newer version of software is installed, the JACE will fail on startup with a license version error.
vendor vendor="Tridium" - This is always Tridium.
generated generated="2007-04-11" - The date upon which the license file was generated.
expiration expiration="2008-03-31" - The expiration date of the license file. After the expiration
date the Workbench software will fail start due to a license expired error. Typically, engineering copies of
Workbench have expiration dates which expire on an annual basis. License files for actual projects are
issued with non-expiring licenses, where this attribute value is "never".
hostId hostId="Win-6827-91CB-C49A-6B4B" - Alphanumeric code unique to the specific host,
which is generated upon installation of the NiagaraAX software on a Windows-based platform. QNX-
based JACE controllers are assigned a hostId similar to this: hostId="Qnx-NPM2-0000-0E8F-2420".
The hostId in the license file must match the hostId of the JACE controller, otherwise the JACE cannot
run a station.
serialNumber serialNumber="4856" - Applies to a license for a QNX-based JACE only. Designates its
unique serial number assigned from the factory. The serial number in the license file must match the
serial number of the JACE..
about
The "about" feature is used to designate optional information, and does not affect station operation in
any way. This information can be useful for filtering records when searching the license database. Two
attributes in this feature are typically designated when ordering product:
<feature name="about" owner="Tridium" project="Tridium Testing"/>
owner owner="Tridium" - Optional field to designate the name of a person who is responsible for the
project or possibly an end user.
project project="Tridium Testing" - Optional field to designate a project. This grouping should
typically be assigned to all JACE controllers used for a particular project.
brand
For any license with vendor="Tridium", the NiCS (Niagara Compatibility Structure) provides a
structure (or schema) that OEMs can use to define the various levels and types of Niagara interoperability
that their products will support. The NiCS definitions are contained in the this feature item which is
checked by a station or tool when it starts up. There are five attributes to the NiCS: BrandID, Station
Compatability In, Station Compatibility Out, Tool Compatibility In, and Tool Compatibility Out. These
elements can be combined in a variety of ways to achieve unlimited flexibility, and are described below.
<feature name="brand" brandId="MyBrand" accept.station.in="*"
accept.station.out="*" accept.wb.in="*" accept.wb.out="*"/>
brandId brandId="MyBrand" - Every licensed station and tool has a Brand Identifier (BrandID). This
field holds a text descriptor that the OEM chooses as the identifier for its product line. Each station or
tool can have only one BrandID entry.
accept.station.in accept.station.in="*" - A list of brands that this local station will allow
NiagaraAX data to come in from. Simply stated from a JACE perspective, "this is the list of brands that I
can accept data from". The "*" is a wildcard designation to allow all brands.
accept.station.out accept.station.out="*" - A list of brands that this local station will allow
NiagaraAX data to be shared with. Simply stated, "This is the list of brands that I can share data with".
accept.wb.in accept.wb.in="*" - A list of brands that this station will allow to be connected to it for
engineering of its application. Simply stated, "This is the list of brands that can engineer me".
accept.wb.out accept.wb.out="*" - A list of brands that this tool is allowed to connect to and
engineer. Simply stated, "This is the list of brands that I can engineer".

NiagaraAX-3.6
A-8
Platform Guide
Appendix A – License Tools and Files signature
April 4, 2011

signature
This element contains a digital signature which is created when the license file is generated. It prevents
tampering with the license file. Attempts to edit the license file to enable additional features will render
the license file useless. Typically, the signature element is the last element contained in the license, so it
is followed by the closing license tag as the last line in the license file.
<signature>MCwCFFOdq4wJcYgvhTVtrf0oSyuCDCwjAhRj+H9pNxQGStBnhEkIqK8rONB10g==</
signature>
</license>
Note: All licenses for any JACE or Supervisor platform also require a "station" application feature, in order to
run a local station. See the section “Applications” on page A-12 for related details.

JACE hardware features

maxheap
This feature determines the maximum size of the Java heap for either a JACE-2 or JACE-6 series
controller. In the abscense of this feature, the maximum heap size is limited to 16 MB for a JACE-2, and
48 MB for a JACE-6. When this license feature is present, the maximum heap size is limited to 48 MB for
a JACE-2 and 96 MB for a JACE-6. The feature may not be available onall JACE-2 controllers, earlier
models were manufactured with 64 MB RAM chips. Verify the amount of physical memory in a JACE-2
before attempting to order the memory upgrade option.
<feature name="maxHeap" expiration="never" parts="NPM-128">

mstp
This feature determines how many of the available serial ports may be used for BACnet MS/TP commu-
nications. Note that features bacnet and serial must also exist in the license file.
<feature name="mstp" expiration="2008-03-31" port.limit="1" parts="AX-DEMO"/>
port.limit port.limit="1" - This specifies the number of serial ports which may be used for MSTP
communications. Typically this number matches the number of physical ports. Some JACE controller
models have option card slots, if additional serial cards are added then the port limit may be less than the
number of physical ports if the port activation has not been ordered as well.
ndio
This feature enables the NDIO (Niagara Direct Input Output) driver, required to configure and use a
JACE controller's I/O hardware. Not all JACE controllers support integrated or distributed I/O, refer to
specific JACE controller datasheets to confirm whether this is an available option. Note that in the ndio
features line (below), a "device" equates to an "Ndio Board", and that history and schedule limits have no
practical application. See Driver Feature Attributes for related details.
<feature name="ndio" expiration="never" device.limit="none"
history.limit="none" point.limit="none" schedule.limit="none" parts="AX-DEMO"/>

serial
This feature enables the use of JACE serial ports for various drivers, for example aapup or modbusAsync.
Note that the JACE license needs this serial feature in addition to any specific driver feature. Only one
serial feature line is needed, regardless of number of serial-based drivers. Note that in the case of a JACE
used for BACnet MS/TP, it would require this serial feature and driver features bacnet and mstp.
<feature name="serial" expiration="2008-03-31" parts="AX-DEMO"/>

Driver attributes
Each driver is enabled by a feature line (element) in the license file. Most of the drivers utilize the same
attributes within that feature. For simplicity, these common attributes are discussed first, and any unique
attribute specific to a particular driver or service will be discussed in that Driver types section.
<feature name="driver name" expiration="expiration date" device.limit="none"
history.limit="none" point.limit="none" schedule.limit="none" parts="AX-DEMO">
Note: The various "limit type" attribute values can be either "none" or a numerical (limit) value, for example
device.limit=32. Note that a limit value of none means unlimited, whereas a limit value of 0 means
none allowed. Although most drivers include all the attributes shown in the feature line above, some
attributes may not apply to a specific driver, with the exceptions of point.limit and device.limit
attributes, which typically do apply to any driver.
For example, none of the Modbus-related drivers have any history or schedule import/export capabilility,
due to the simplicity of the Modbus protocol. Therefore, "history.limit" and "schedule.limit"
attributes have no importance in the feature line of those drivers.

NiagaraAX-3.6
A-9
Platform Guide
name Appendix A – License Tools and Files
April 4, 2011

name
Feature name of the driver, often the same as the actual module (.jar file) name, for example bacnet,
lonworks, etc.
expiration
Each driver has an expiration date which is typically the same as the expiration property of the license
feature. In some cases such as beta testing agreements, individual drivers may be set to expire where the
main license file is non-expiring.
device.limit
This attribute designates a license limit on the number of devices which may be added to this specific
driver network in the station database. Above this limit, any added device component (and all its child
components) will be in fault.
This limit has no impact on the actual physical limitation of a field bus. For example just because the
lonworks feature is set to device.limit="none", this does not mean that you can exceed the normal limit
of 64 devices per segment.
history.limit
This attribute limits the number of NiagaraAX histories that can be imported from remote histories (logs
or trends) into the station's history space, and/or exported from station histories to appear as histories in
remote devices. Above this limit, any added history import descriptor (or history export descriptor) will
be in fault, and the associated import/export will not be successful.
point.limit
This attribute designates the maximum number of proxy points that may be added to the station database
for a particular driver. Above this limit, any added proxy point will be in fault.
schedule.limit
This attribute limits the maximum number of NiagaraAX schedules that can be imported from remote
schedules into the station’s database, and/or exported from station schedules to appear as schedules in
remote devices. Above this limit, any added schedule import descriptor (or schedule export descriptor)
will be in fault, and the associated import/export will not be successful.
parts
This is an alphanumeric part code which is automatically assigned when generating the license file and is
for Tridium internal use.

Driver types
Each driver type is enabled by a separate feature element (or line, starting with name attribute), and has
common Driver attributes as previously described.
Note: New NiagaraAX drivers are continually developed and offered as products. This section includes some, but
not all drivers available. It is included in this section to illustrate how driver features appear in licenses.
Alphabetically, driver types listed here include aaphp, aapup. bacnet, bacnetws, dust, fileDriver,
lonworks, modbusAsync, modbusSlave, modbusTcp, modbusTcpSlave, obixDriver, opc, niagaraDriver,
rdbDb2, rdbOracle, rdbSqlServer, and snmp.
aaphp
Enables the American Auto-Matrix Public Host Protocol (PHP) driver. The serial feature is also required.
aapup
Enables the American Auto-Matrix Public Unitary Host (PUP) driver. The serial feature is also required.
bacnet
Enables functionality of the BACnet driver for BACnet/Ethernet and BACnet/IP. If a QNX-based JACE,
other features can be added to enable BACnet MS/TP communications over serial ports: mstp and serial.
<feature name="bacnet" expiration="2009-03-31" device.limit="none"
export="true" history.limit="none" point.limit="none" schedule.limit="none"
parts="AX-DEMO"/>
export export="true" - When set to "true" this field enables BACnet server operation. When the
field is set to "false" only BACnet client operation is permitted.
Note: When BACnet export is enabled, any station histories and/or schedules that are exported to BACnet do
not count towards any history.limit or schedule.limit values in the license (if any).

NiagaraAX-3.6
A-10
Platform Guide
Appendix A – License Tools and Files bacnetws
April 4, 2011

bacnetws
Provides added functionality as a BACnet Supervisor as described in the BACnet Specification B-OWS
device profile, and is for PC platforms only (not JACE platforms). The bacnet feature is also required in
the license. More details are available as an appendix in the NiagaraAX BACnet Guide.
dust
Enables the Dust Wireless Mesh driver. Details are available in the NiagaraAX Dust User Guide.
fileDriver
Enables the File driver, used to import comma or tab delimited text files and convert into Niagara
Histories.
lonworks
Enables the Lonworks driver. Utilizing the driver also requires a LON interface on the JACE controller.
Some JACE controller models require an optional Lonworks interface card to be installed. More details
are available in the NiagaraAX Lonworks Guide.
modbusAsync
Enables the Modbus Master Serial driver. The JACE controller operates as the Modbus Master device
communicating via an available serial port using either Modbus RTU or Modbus ASCII. The serial
feature is also required.
modbusSlave
Enables the Modbus Slave Serial driver. The JACE controller operates as a Modbus Slave communicating
via an available serial port using either Modbus RTU or ASCII to a Modbus Master device. The serial
feature is also required.
modbusTcp
Enables the Modbus Master TCP driver. The JACE controller operate as a Modbus Master device
communicating via Modbus TCP/IP.
modbusTcpSlave
Enables the Modbus Slave TCP driver. The JACE controller operates as a Modbus Slave device commu-
nicating via Modbus TCP/IP.
obixDriver
Enables the oBIX driver. The driver supports the oBIX protocol, which is M2M (Machine-to-Machine)
communications via XML over TCP/IP.
<feature name="obixDriver" expiration="2009-03-31" device.limit="none"
export="true" history.limit="none" point.limit="none" schedule.limit="none"
parts="AX-DEMO"/>
export export="true" When set to "true" this field enables oBIX server operation. When the field is
set to "false" only oBIX client operation is permitted.
opc
Enables the OPC client driver, and is only available on Windows-based platforms because of the
protocol’s dependency of Windows.
niagaraDriver
Enables communication via the Fox protocol to other NiagaraAX stations, and allows creation of a Niaga-
raNetwork, including proxy points, importing/exporting histories and schedules, and routing alarms.
rdbDb2
Enables the Relational Database Driver using the IBM DB2 database format. This driver allows exporting
of histories from the NiagaraAX station to an IBM DB2 database. The driver does not include the DB2
software, which must be purchased separately from a third party source.
<feature name="rdbDb2" expiration="never" parts="ENG-WORKSTATION"/>
rdbOracle
Enables the Relational Database Driver using the Oracle database format. This driver allows exporting of
histories from the NiagaraAX station to an Oracle database. The driver does not include the Oracle
software, which must be purchased separately from a third party source.
<feature name="rdbOracle" expiration="never" parts="ENG-WORKSTATION"/>

NiagaraAX-3.6
A-11
Platform Guide
rdbSqlServer Appendix A – License Tools and Files
April 4, 2011

rdbSqlServer
Enables the Relational Database Driver using the Microsoft SQL database format. This driver allows
importing and exporting of histories to and from the NiagaraAX station, and to and from a Microsoft
SQL database. The driver does not include the Microsoft SQL software, which must be purchased
sperately from a third party source. The driver does work with the MSDE version which is free from
Microsoft; however, the normal Microsoft imposed limitations on the MSDE version still apply.
<feature name="rdbSqlServer" expiration="never" history.limit="10" history-
Import="true" parts="ENG-WORKSTATION"/>

snmp
Enables the SNMP (Simple Network Management Protocol) driver, which allows sending and receiving
SNMP messages.
<feature name="snmp" expiration="2008-03-31" device.limit="none"
history.limit="none" point.limit="500" schedule.limit="none" parts="AX-DEMO"/>

Applications
Alphabetically, application types include crypto, eas, email, genericAppliance, provisioning, station,
tenantBilling, web, and workbench. However, applications station, web, and workbench have special
importance, and are summarized first.
station
Enables a station to be run, and is typically present in any JACE platform, as well as a Supervisor.
<feature name="station" expiration="2008-03-31" resource.limit="none"
parts="AX-DEMO"/>
The station feature may not be present in a license for an engineering workstation (PC), unless specifi-
cally ordered with it.
resource.limit resource.limit="none" - If the resource.limit flag is specified (in kRUs), then the
station displays a warning on startup if the actual resource units exceed the limit resource units. If the
limit is exceeded by 110% then the station will not boot at all. This limit is normally only specified on
SoftJACE license files.
web
The web feature must be present to start the WebService in a running station (to access the web server
via an HTTP connection). If not licensed, the server is set to fault with appropriate faultCause. If the
feature is enabled, then WebServlets and spy pages are always available.
Note: Full Workbench can connect to a station (via Fox connection) even if the web feature is disabled.
<feature name="web" expiration="2008-03-31" ui="true" ui.wb="true"
ui.wb.admin="true" parts="AX-DEMO"/>
ui ui="true" - If the ui flag is false, then all access to ServletViews via "/ord" are disabled (with
exception to spy pages).
ui.wb ui.wb="true" - If the ui.wb flag is false, then all user accounts using an WbProfile are disabled
(including thin client views, but with exception to spy pages). Only thin client accounts operate when
ui.wb is false; other accounts do not automatically degrade. Views which aren't licensed return 403
Forbidden.
ui.wb.admin ui.wb.admin="true" - If the admin flag is false, then all views which have an admin flag
set in their required permissions are unavailable using the wb applet.
workbench
The workbench feature must be present to start the full version of Workbench (for example, a copy of
Tridium's WorkPlaceAX or an OEM-specific Workbench-based application). If the admin flag is false,
then all views requiring admin access are unavailable. This feature is included for PC platforms only, with
the sole exception of a SoftJACE.
<feature name="workbench" expiration="2008-03-31" admin="true" parts="AX-DEMO"/
>

crypto
Enables "secure socket layer" (ssl) operation.
<feature name="crypto" expiration="never" ssl="true" parts="ENG-WORKSTATION"/>

eas
This feature enables the Energy Suite application and the associated reports, data points and meters.

NiagaraAX-3.6
A-12
Platform Guide
Appendix A – License Tools and Files allCostReports
April 4, 2011

<feature name="eas" expiration="2008-03-31" allCostReports="true"

allE2Reports="true" brand="MyBrand" costMeter.limit="none"
dataPoint.limitt="none" parts="AX-DEMO"/>
allCostReports allCostReports="true" - If set to “true" all Cost Profiler Reports are enabled.
When set to "false" there are additional feature items for each of the specific Cost Profiler Reports that
are enabled.
allE2Reports allE2Reprots="true" - If set to “true" all E2 Profiler Reports are enabled. When set
to "false" there are additional feature items for each of the specific E2 Profiler Reports that are enabled.
costMeter.limit costMeter.limit="none" - Designates the maximum number of Cost Profiler
Meters that may be configured in the VES Application, where “none” means unlimited.
dataPoint.limit dataPoint.limit="none" - Designates the maximum number of E2 Profiler Points
that may be configured in the VES Application, where “none” means unlimited
email
This features enables the NiagaraAX station to send email messages to an SMTP server. If the feature is
not present then the service and all its incoming and outgoing accounts are marked as fault. No email can
be sent or received if not licensed.
<feature name="email" expiration="2008-03-31" parts="AX-DEMO"/>
genericAppliance
This feature enables the NiagaraAX Generic Appliance Application.
<feature name="genericAppliance" expiration="never" vendor.name="" parts="GA-
GENERIC"/>

provisioning
Enables the operation of provisioning, typically used to automate routine maintenance of a NiagaraAX
system such as JACE software upgrades, file distribution and backups. It applies to an Supervisor
platform only. In AX-3.1 and AX-3.2, provisioning was done with the ProvisioningService, sourced from
the provisioning module. Starting in AX-3.3, provisioning moved to a BatchJobService and “network
extension model (e.g. a “ProvisioningExt” under the NiagaraNetwork), sourced respectively from
modules batchJob and provisioningNiagara.
<feature name="provisioning" expiration="2008-03-31" parts="AX-DEMO"/>

tenantBilling
Enables the NiagaraAX Tenant Billing Application.
<feature name="tenantBilling" expiration="never" tenant.limit="none" parts="S-
TBS-AX"/>
tenant.limit tenant.limit="none" - Designates the maximum number of tenants that may be
configured in the station database, where “none” means unlimited.

NiagaraAX-3.6
A-13
Platform Guide
tenant.limit Appendix A – License Tools and Files
April 4, 2011

NiagaraAX-3.6
A-14
Platform Guide
 APPENDIX B
Time Zones and NiagaraAX
Platform configuration of a NiagaraAX host includes specifying its time zone. This affects both real time
clock accuracy used in station control, an also how timestamps appear in items like histories and alarms.
This appendix provides details on time zone selection in all revisions of NiagaraAX, as well as the AX-3.3
and later improvements based upon a “historical time zone database.”
The following main sections are included:
• Time zones and terminology
• Selecting a time zone in NiagaraAX
• About timezones.xml (pre-AX-3.3)
• About the historical time zone database (current NiagaraAX releases)
Note: Starting in AX-3.5, Workbench provides a special “Time Zone Database Tool” that lets you explore the
historical time zone database on the local Workbench host. For details, refer to the User Guide section on
the “Time Zone Database Tool”.

Time zones and terminology

A time zone is a region in the world that uses the same standard time, often referred to as the local time.
There are many different time zones, owing to the combinations of geographic locations and political/
cultural differences. Time zones calculate their local time as an offset from UTC (Coordinated Universal
Time). In addition, many time zones apply DST (Daylight Saving Time).

UTC
Coordinated Universal Time (UTC) is the recognized atomic-clock standard of reference time, largely
replacing GMT (Greenwich Mean Time) as reference time. Time zones are commonly expressed as
negative or positive offsets from UTC time.

DST
Daylight Saving Time (DST) is used as a means of maximizing daylight hours during normal waking
hours, and is used by many (but no means all) time zones. DST is a twice-yearly event acting upon local
time, as follows:
• Start of DST adds an offset (typically 1 hour) to local time. During this period of the year, local time
may be called “daylight time.”
• End of DST removes the DST offset from local time. During this period of the year, local time may
be called “standard time.”
Any time zone using DST has specific rules that define the exact days and times when DST starts and
ends. These rules vary widely from zone to zone, since DST policies are set by national and regional
governments. Also, DST policies are subject to change for this same reason—as in the recent 2007 change
for all U.S. time zones that observe DST.
In the 2007 U.S. DST changes, the DST start time was changed to “first Sunday on or after the 8th in
March” (from “first Sunday on or after the 1st in April” for 2006 and prior years). The DST end time was
changed to “first Sunday on or after the 1st in November” (from “last Sunday in October” for 2006 and
prior years).
Note: A change in DST rules for a time zone can cause issues in NiagaraAX when displaying historical data
(histories and alarm records), particularly when applying new (current) DST rules to records collected
using prior (old) DST rules. Starting in AX-3.3, these issues have been overcome using a “historical
timezones” mechanism. For more details, see “About the historical time zone database” on page B-4.

NiagaraAX-3.6
B–1
Platform Guide
Selecting a time zone in NiagaraAX Appendix B – Time Zones and NiagaraAX
April 4, 2011

Selecting a time zone in NiagaraAX

Since the first NiagaraAX release, platform configuration of a NiagaraAX host includes the setting of date
and time, which includes specifying its local time zone. Typically, this is done using either a platform
connection and the Platform Administration view (function “Change Date/Time”), or possibly
after a station is installed and running, using the one of the station’s PlatformServices views (“Platform
Service Container Plugin” or “System Date and Time Editor”).

Figure B-1 Selecting time zone from Change Date/Time selection in Platform Administration View

Time zones appear on the selection list using a “Zone ID (hours UTC offset/hours [DST + UST] offset)”
format. Some examples:
America/Chicago (-6,-5)
Europe/Berlin (+1,+2)
Asia/Tokyo (+9)
Note there is no DST observance in Japan, so the selection with zone ID “Asia/Tokyo” shows only the
UTC offset of +9 hours.
This selection list of available time zones is from a “time zone database” that resides on that host.
Depending on NiagaraAX release level, this database is sourced differently, as follows:
• Host platforms running pre-AX-3.3 builds use a !lib/timezones.xml file. In this database file,
for each known time zone there is one definition, starting with its zone ID. If necessary, you can edit
the definition of one or more time zones in this timezones.xml file (or replace with an edited version
of this file). See the next section “About timezones.xml” for more details.
• Host platforms running AX-3.3 or later use a “historical time zone database”, contained in the file
!lib/timezones.jar. (Although a timezones.xml file is also included, it is not used locally.)
In this database, a history of changes for applicable time zones are stored, such that multiple defini-
tions for a time zone may exist, including past definitions as well as its current definition. Time zones
in this database are not user editable. However, this time zone database offers advantages for Niaga-
raAX jobs where accrued histories or alarms have spanned across different time zone definition eras.
For more details, see “About the historical time zone database” on page B-4.

About timezones.xml
The timezones.xml file used by pre-AX-3.3 hosts provides an easily read and edited single definition
for each time zone, where all values are contained within quotes "value".
For example, consider the following entry for one time zone:
<zone id="America/Anchorage" utcOffset="-9h">
<display name="Alaska Standard Time" short="AKST" dstName="Alaska Daylight Time" dstShort="AKDT"/>
<dst savings="1h">
<start time="2:00" weekday="sunday" month="march" week="second"/>
<end time="2:00" week="first" weekday="sunday" month="november"/>
</dst>
where attributes and example values are:
• zone id="America/Anchorage" : Name in drop-down selection list when picking a time zone.
• utcOffset="-9h" : Time added to UTC for this zone, typically in (h)ours, may be negative, positive,

NiagaraAX-3.6
B-2
Platform Guide
Appendix B – Time Zones and NiagaraAX DST start and end syntax variations
April 4, 2011

or 0 (i.e. none).
• display name="Alaska Standard Time" : Seen somewhere (but where?) when DST not in effect.
• short="AKST" : Seen within timestamps (e.g.,alarms and histories) when DST not in effect.
• dstName="Alaska Daylight Time" : Seen somewhere (but where?) when DST is in effect.
• dstShort="AKDT" : Seen within timestamps (e.g.,alarms and histories) when DST is in effect.
• dst savings="1h" : All dst parameters exist only if the time zone has DST. If so, the savings at-
tribute is the DST adjustment amount, typically "1h" (1 hour), in very few time zones is "0.5h".
• start time="2:00" weekday="sunday" month="march" week="second"/ : Specifies the
time and day when DST begins, often with "week, weekday, month" method (that is, “Nth week-
day”, as shown here.
• end time="2:00" week="first" weekday="sunday" month="november"/ : Specifies the
time and day when DST ends, often with a "week, weekday, month" method (that is, “Nth week-
day”, as shown here.
Note that there are DST start and end syntax variations different from the ones above.

DST start and end syntax variations

Sometimes a time zone with DST will use a different syntax to specify a DST start or stop day, versus the
“Nth weekday” syntax shown in the previous timezones.xml example.
For example, the Baghdad time zone defintion uses day (“Exact day”) instead of “Nth weekday” to specify
a particular date, in this case for the 1st of the month:
<zone id="Asia/Baghdad" utcOffset="3h">
<display name="Arabia Standard Time" short="AST" dstName="Arabia Daylight Time" dstShort="ADT"/>
<dst savings="1h">
<start time="3:00 standard" month="april" day="1"/>
<end time="3:00 standard" month="october" day="1"/>
</dst>
</zone>
A variation is where weekday and day are both used (but not week) and the day numeric value includes
trailing ... to indicate “on or after (that day number),” as in time zone definition below. In this case, start
time is evaluated as “on the Friday on or after the 26th of March.”
<zone id="Asia/Tel_Aviv" utcOffset="2h">
<display name="Israel Standard Time" short="IST" dstName="Israel Daylight Time" dstShort="IDT"/>
<dst savings="1h">
<start time="2:00" weekday="friday" month="march" day="26..."/>
<end time="2:00" month="september" day="13"/>
</dst>
</zone>
A similar “on or before” variation can be specified using a leading ... before a day number, for example,
day=”...12”. Of course many time zones do not even observe DST, so their definitions are noticeably
shorter, for example the following one for Honolulu:
<zone id="Pacific/Honolulu" utcOffset="-10h">
<display name="Hawaii Standard Time" short="HST"/>
</zone>

Using Workbench to edit and transfer timezones.xml

Remember the timezones.xml used by any Niagara AX host (JACE) is the one in its own !lib folder, so
to change it you typically edit a local copy (on your Workbench PC) and then transfer this file to that
location on the remote JACE, using the platform view File Transfer Client.
The following is a quick summary of how to do this using Workbench:
Step 1 In the Workbench nav tree, expand My File System and then Sys Home, lib folder.
Step 2 In the lib folder, double-click timezones.xml to open it in the Text File Editor.
Step 3 Make whatever changes are needed in the time zone(s) you will pick from, and click the Save tool
when done.
Step 4 In Workbench, open a platform connection to the target JACE, and select the File Transfer Client.
Step 5 In the File Transfer Client, open both (left and right) sides to list files in the !lib folder.
Step 6 Transfer your locally edited timezones.xml (left side) to the JACE on the right. A "Replace File?"
popup dialog will appear, showing a different CRC value. Click Yes to transfer the file.
The time zone database is now updated in the JACE.
Note: Any change to timezones.xml is not effective until after the station is restarted.

NiagaraAX-3.6
B-3
Platform Guide
About the historical time zone database Appendix B – Time Zones and NiagaraAX
April 4, 2011

About the historical time zone database

Starting in AX-3.3, any NiagaraAX host uses a time zone database with “historical perspective,” such that
display of a station’s timestamped data (histories and alarms) collected in time zones under “prior rules”
(typically DST-related) will always display with the original (and correct) collected time.

Issue example and fix

You have a JACE that has been running since AX-3.0, installed in a U.S. time zone that observes DST.
Included in the AX-3.0 builds was a timezones.xml with “old” DST rules. See the “DST” section for
related details. On it you have a station running, that includes an original history for a boolean point with
two records like this:
01-Nov-06 8:00 AM EST {} {ok} On
01-Nov-06 5:00 PM EST {} {ok} Off
The timestamp values shown are correct, this was a piece of equipment that came ON at 8:00am and OFF
at 5:00pm, and on November 1st of 2006 it was indeed “Eastern Standard Time” (EST), as Daylight
Savings Time had already ended on the last Sunday in October.
Since, you upgraded the JACE to AX-3.2, which uses updated 2007 rules in its timezones.xml file. After-
wards, when looking at the same two records for the example history, you see:
01-Nov-06 9:00:11 AM EDT {} {ok} On
01-Nov-06 6:00:13 PM EDT {} {ok} Off
These timestamp values are incorrect, as the DST offset of 1 hour was “retroactively” applied using the
new DST rules (even though these rules were not actually in effect at this time). However, those same new
rules are required during this period in 2007 to correctly change the system clock and maintain accurate
2007 timestamps.
After upgrading the JACE to AX-3.3 or later, which uses the timezones.jar (historical time zone database)
instead of timezones.xml, when you look again at the same two records for the example history, you see:
01-Nov-06 8:00:11 AM EST {} {ok} On
01-Nov-06 5:00:13 PM EST {} {ok} Off
The timestamp values are correct, as the historical rules were used instead of the current (new) rules.

Parts of the historical time zone database

The historical time zone database is sourced from the public “Olson Time Zone Database,” and updated
(synchronized to it) upon each NiagaraAX build. It is implemented using a “timezones.jar” file that
contains histories of changed rules for any so-affected timezones, along with changes to the NRE
(Niagara Runtime Environment) that support this new method.
There are 2 associated files with historical time zones in an AX-3.3 or later host’s !lib folder, described
as follows:
• timezones.jar : The time zone database, in Java archive format. Contains a collection of binary
files, one representing each time zone. Upon each build of NiagaraAX, this timezones.jar file is up-
dated (synchronized) to the Olson Time Zone Database to maintain historical accuracy.
• system.properties : The file responsible for loading various system settings at NRE (Niagara
Runtime Environment) boot time. This file now contains 2 keys pertaining to historical time zones:
• niagara.timezone.dbCache : The maximum number of zones to remain cached in memory
when querying the database for a particular zone. This caching is done in an “LRU” fashion, vs.
hitting the database repeatedly for the same zones. This method provides performance gains.
• niagara.timezone.eraTolerance : The number of milliseconds to wait before loading a
new historical time zone era. The higher the number, the better the performance (yet lower the
accuracy). The reverse is true for higher numbers
Please note that time zones in this database are not user editable, unlike with the earlier
timezones.xml database.

Updating a historical time zone database

Typically, you use the normal release/build upgrade process for a JACE to update its historical time zone
database. However, in cases where an updated version of this database becomes available, and you want
to maintain the current build in an AX-3.3 or later JACE, you can simply transfer the newer
timezones.jar file to the host's !lib folder.
Note: As when making changes to the timezones.xml file in an earlier rev. host (pre-AX-3.3), after updating the
historical time zone database files, you must restart the station on that host for the updated time zone
database to become effective.

NiagaraAX-3.6
B-4
Platform Guide
 APPENDIX C
Platform Tunneling
Starting in AX-3.5, support was added for a “tunneled” Workbench platform connection to a remote
NiagaraAX platform, similar to the Fox and HTTP (browser) tunnel mechanisms introduced in AX-3.3.
This appendix provides details about how to configure and establish tunneled platform connections.
Note: For details about Fox and HTTP tunneling, see the Engineering Notes article “Fox Tunneling and HTTP
Tunneling”.
The following main sections are included:
• Platform tunneling overview
• Supervisor configuration to support platform tunneling
• Platform tunneling usage
• Notes on platform tunneling

Platform tunneling overview

Platform tunneling lets you make a Workbench platform connection to a remote JACE platform by
“tunneling” through the station running on another NiagaraAX proxy host, typically the Supervisor for
the target JACE. Once the tunnel connection is made, you can use all the same platform views, and
perform the same platform tasks, as if you had a platform connection directly to the target JACE.
This can be useful in cases where only the Supervisor has an exposed IP address, or if a firewall restricts
access to Niagara hosts on a network through only a single port.
Key points to remember include:
• Usage applies to a full Workbench client only, and not a “Web Workbench” browser session for plat-
form tunnel access (just as Web Workbench does not provide direct platform access).
• Tunneling is not a “daemon level” function. Platform tunneling relies on the Supervisor’s running
station, as its web server acts as the “tunnel proxy server”, or tunnel entrance point. Tunneling is ac-
tually HTTP, to allow access to the platform daemon running on a JACE—the tunnel endpoint.

Platform tunneling requirements

• NiagaraAX-3.5 is required by all platforms (Supervisor, JACEs) on ends of a platform tunnel.
• Platform tunneling requires a “tunneling” feature in the license of the Supervisor, (tunnel proxy serv-
er) with the “http” attribute set to true, which is standard. See Figure C-1.

Figure C-1 Supervisor (tunnel proxy server) requires “tunneling” feature to support platform tunneling

The Supervisor station also requires a few configuration settings, as described in following sections.

NiagaraAX-3.6
C–1
Platform Guide
Supervisor configuration to support platform tunneling Appendix C – Platform Tunneling
April 4, 2011

Supervisor configuration to support platform tunneling

On the AX-3.5 or later Supervisor station, these areas are involved:
• WebService settings for platform tunneling
• FoxService settings for platform tunneling

WebService settings for platform tunneling

In the Supervisor’s WebService (under Config, Services), ensure that the two properties
below are as shown in Figure C-2.

Figure C-2 WebService in Supervisor to support platform tunneling

• Tunneling Enabled
Set to true. If Fox and HTTP tunneling are already enabled, this should already be enabled.
• Proxy Authentication When Tunneling
Set to false. In the initial AX-3.5 implementation of platform tunneling, proxy authentication is
not supported. The only login authentication used in a tunneled platform connection are the tunnel
endpoint’s (JACE’s) platform credentials.
Note: This property was first introduced in AX-3.4, and for an existing job upgraded from AX-3.4 to
AX-3.5 may be true. To permit platform tunneling, you must set it to false.

FoxService settings for platform tunneling

Platform tunneling works independently from Fox tunneling. Typically, if a job uses tunneling, both Fox
tunneling and HTTP tunneling are already enabled.
However, note that one FoxService property on the Supervisor (proxy tunnel server) affects platform
tunneling. That property is shown highlighted in Figure C-3.

Figure C-3 Supervisor’s FoxService, showing “Only Tunnel Known Stations” property

On the Supervisor, expand its Config, Drivers, nodes to reveal its NiagaraNetwork, then
right-click to select Views > Property Sheet. Expand the Fox Service container, and scroll
to the bottom of its contained properties.
• Tunneling Enabled
Can be either true or false, it affects Fox tunneling only (not platform tunneling). If Fox tunneling
is already enabled, this should already be true.
• Only Tunnel Known Stations
May be either true or false. This property was first introduced in AX-3.4.
Depending on its setting, this affects the ability to open a tunneled platform connection, including
how you enter the target (JACE) host in the Open Platform dialog:

NiagaraAX-3.6
C-2
Platform Guide
Appendix C – Platform Tunneling Platform tunneling usage
April 4, 2011

• If false, you can tunnel a platform connection to any AX-3.5 or later JACE that is reachable
from the Supervisor station, using the target IP address (or hostname) of that JACE.
• If true, you can tunnel a platform connection only to a JACE that is currently represented in
the Supervisor’s NiagaraNetwork. Here, you use its station name as the target destination—not
the JACE’s IP address or hostname.
Note this property was originally for Fox tunneling, and works in the same manner. However, it is a
bit more “intuitive” in Fox tunneling, where you equate Fox connections and stations.

Platform tunneling usage

Using Workbench AX-3.5 or later, open a tunneled platform connection through the Supervisor, whether
remote or local at the Supervisor. If a standard connection is not already open, or you are working on the
Supervisor itself, use the Open Platform dialog (Ctrl + Shift + P), also available from the File >
Open submenu.

Open Platform dialog if tunneling

Click the drop-down control in the Host field and select Tunnel (IP)

Figure C-4 Select Tunnel (IP) in Open Platform dialog

In the top Host field, enter the IP address or hostname of the Supervisor (the tunnel proxy server).

Figure C-5 Standard port 80 on Supervisor, “Tunnel to” depends on “Only Tunnel Known Stations”

• In the Port field, enter the configured Http Port property value in the Supervisor’s WebService,
where 80 is the standard (default) value.
• In the Tunnel to field, enter either:
• IP address or hostname of the endpoint JACE platform, if “Only Tunnel Known Stations” is
false in the FoxService of the NiagaraNetwork of the Supervisor. (Figure C-5, left), or
• Station name of the station associated with the endpoint JACE, if “Only Tunnel Known Sta-
tions” is true in the FoxService of the NiagaraNetwork of the Supervisor. (Figure C-5, right).
For related details, see “FoxService settings for platform tunneling” on page C-2.
Note: If the endpoint JACE platform is using a “non-standard” HTTP port for the platform daemon,
meaning not port 3011, append a colon (:) and that port number on the “Tunnel to” value. For
example:
– 192.168.1.88:3012 (if the JACE is using port 3012 for the platform daemon)
• In the Credentials fields (Username and Password), enter the JACE’s platform credentials .

NiagaraAX-3.6
C-3
Platform Guide
Connected in Workbench Appendix C – Platform Tunneling
April 4, 2011

Connected in Workbench
When connected, the tunneled platform shows a different platform icon, along with either the target
IP address or hostname (or station name if using “Only Tunnel Known Stations”). See Figure C-6.

Figure C-6 Tunnel-connected platform example showing IP address of endpoint JACE

Once connected, you can perform all the same platform operations as if directly platform connected to
the endpoint JACE, including running the Commissioning Wizard. See “Types of platform views” on
page 1-3.
Note if a Workbench connection to the remote Supervisor (either station or platform) is already open,
you can right-click on the host in the Nav tree, and select Open Tunnel Platform (http).

Figure C-7 Right-click remote Supervisor for Open Tunnel Platform menu item

In this similar Open Tunnel Platform dialog, enter values the same way as previously described (see
“Open Platform dialog if tunneling” on page C-3).

Notes on platform tunneling

These additional notes apply to platform tunneling:
• If needed, you can have multiple tunneled platform connections through the Supervisor station.
Traffic on each connection consumes some amount of resources, but typically capacity exists.
• Remember that tunneled platform connections are dependent on the running Supervisor station.
Avoid any Supervisor station restarts (or stops) during critical tunneled platform operations, other-
wise problems are likely to result.
• Although not necessarily recommended, currently there is nothing preventing a “loop back” plat-
form connection to the Supervisor platform itself, using only the HTTP port as configured in its
WebService. In this case the “Host” and “Tunnel to” fields would both have the same IP address.
This is a “workaround” solution if a firewall connection blocks all ports (for example, 3011) except
for that one HTTP port.

NiagaraAX-3.6
C-4
Platform Guide