Control Software Deployment Guide: Foxboro Evo Process Automation System

Foxboro Evo™
Process Automation System
Control Software Deployment

Guide
*B0750BA* *Z*
B0750BA
Rev Z
November 22, 2016
All rights reserved. No part of this documentation shall be
reproduced, stored in a retrieval system, or transmitted by any means,
electronic, mechanical, photocopying, recording, or otherwise,
without the prior written permission of Schneider Electric. No
copyright or patent liability is assumed with respect to the use of the
information contained herein. Although precautions have been taken
in the preparation of this documentation, the publisher and the author
assume no responsibility for errors or omissions. Neither is any
liability assumed for damages resulting from the use of the
information contained herein.
The information in this documentation is subject to change without

notice and does not represent a commitment on the part of
Schneider Electric. The software described in this documentation is
furnished under a license or nondisclosure agreement. This software
may be used or copied only in accordance with the terms of these
agreements.
© 2007-2016 Schneider Electric. All Rights Reserved.

Invensys is now part of Schneider Electric.
Trademarks
Schneider Electric, Invensys, Foxboro, Foxboro Evo and I/A Series
are trademarks of Schneider Electric SE, its subsidiaries and affiliates.
All other brand names may be trademarks of their respective owners.
iii
Contents
Before You Begin ...............................................ix
About This Book ................................................................................... ix
Assumption............................................................................................ ix
Revision Information............................................................................. ix
Where to Get More Information............................................................ ix
Related Wonderware Documentation ................................................. x
Foxboro Evo Documentation.............................................................. x
Glossary................................................................................................ xii
CHAPTER 1: General Concepts .........................1

Overview of Foxboro Evo Control Software Components.................... 1
Comparison between I/A Series and Foxboro Evo
Control Software Components ........................................................... 2
Definition of Objects.............................................................................. 4
PROFIBUS Objects ............................................................................ 4
Foundation fieldbus Objects ............................................................... 4
DeviceNet Objects .............................................................................. 4
HART® Objects ................................................................................. 4
RedundantDIObject ............................................................................ 5
I/A Series Browser ................................................................................. 5
CHAPTER 2: Sizing and Performance...............7

Minimum System Requirements............................................................ 7
How to Configure a Hard Disk .............................................................. 8
Extending a Drive ............................................................................. 10
New Volume Creation....................................................................... 13
Quick Reference of Recommendations................................................ 17
Configuration Guidelines ..................................................................... 18
System Topology Considerations ..................................................... 18
Control Editors Considerations ........................................................ 18
Terminal Server Considerations ....................................................... 20
Wonderware Historian and Historian Data
Collector Considerations .................................................................. 21
System Manager Considerations ...................................................... 21
Field Device Manager Considerations ............................................. 22
Asset Condition Monitor Considerations ......................................... 23
Interoperability with Solaris™ Workstations on
The Foxboro Evo Control Network.................................................. 27
Off-Platform Foxboro Evo Control Software
Server Considerations....................................................................... 29
Sample Configurations......................................................................... 32
Control Software Deployment Guide – B0750BA Rev Z

iv Contents
Configuration Notes..............................................................................40
Foxboro Evo Control Software Network
Troubleshooting Checklist ....................................................................42
CHAPTER 3: Historizing Data ..........................45

Overview of Historical Data Collection................................................45
Configuring a Historical Data Collector ...............................................46
Configuring the Wonderware Historian to
Collect from I/A Series Data Access Server .........................................46
Redundant Historian .............................................................................46
Additional Information .........................................................................47
CHAPTER 4: Security .......................................49

ArchestrA Security................................................................................49
Control HMI Security ...........................................................................50
Starting Control HMI Without a Windows Taskbar ..........................51
I/A Series Security Provider .................................................................53
Using Write Access Security .............................................................54
Foxboro Evo Security Considerations ..................................................54
Details of the ArchestrA Security Model..............................................54
Security Groups .................................................................................54
Users ..................................................................................................56
Roles ..................................................................................................57
Assigning Users to Roles ..................................................................57
Sample Procedure for Setting up Security in
Foxboro Evo Control Software .............................................................58
OS Based Security Configuration for Field Device Manager...............66
OS User Based Security ....................................................................66
OS Group Based Security..................................................................66
Unity Pro Object Template Security .....................................................71
Secure Installation by Default ...........................................................72
One Internal User with File Watcher Service....................................72
Separate Users for PLC and CS in a Single System with
File Watcher Service..........................................................................73
Separate Users for PLC and CS in Separate Systems with File
Watcher Service.................................................................................74
File Share Configuration for PLC Configuration Files .....................76
CHAPTER 5: Galaxy Sync Service ..................83

Software Components ...........................................................................83
Galaxy Sync Service Operation.........................................................83
Refreshing the History and Security Database .....................................83
Refresh Procedure .............................................................................84
Galaxy Sync Service Utility..................................................................87

Contents v
CHAPTER 6: Terminal Services and Remote

Desktop Services ..............................................89
Overview of Terminal Services and Remote Desktop Services........... 89
Terminal Services and Remote
Desktop Services for InTouch Software............................................... 90
(Windows Server 2003 Only) Remove Control HMI
Startup Shortcut from “All Users” Startup Directory....................... 91
User Accounts for InTouch over Terminal
Services and Remote Desktop Services............................................ 92
NAD Configuration for Terminal Services and
Remote Desktop Services ............................................................... 101
Configuring Start Program for Remote Users ................................ 104
Customizing Access for Remote Users of
Control HMI Software.................................................................... 105
Network Load Balancing for Remote Desktop Protocol Sessions..... 106
CHAPTER 7: Managed Control HMI

Application.......................................................109
Managed Control HMI Application Maintenance ............................. 109
Managed Control HMI Application Deployment and Runtime..........112
Managed Control HMI Application in Remote Desktop Sessions .....113
Backup of Managed Control HMI Application...................................113
CHAPTER 8: Remote Desktop Using InTouch

Access Anywhere™ ........................................ 115
Overview and Architecture .................................................................115
Licensing .............................................................................................117
Installation of the InTouch Access Anywhere Server .........................117
CHAPTER 9: Multi Monitor Setup for InTouch....

119
Setting Up InTouch Software to Run on Multiple Monitors...............119
CHAPTER 10: Configuration and Installation

Considerations ................................................123
Foxboro Evo Control and Host Workstation
Upgrade Considerations ..................................................................... 123
Foxboro Evo Control Software Support for I/A Series Software
v8.4.x-v8.8, and Control Core Services Software v9.0 or Later
Configurations ................................................................................ 124
Stand-alone Configuration ................................................................. 126
Backing up the Galaxy ....................................................................... 126

vi Contents
Migrating Configuration Data from Existing

I/A Series or Foxboro Evo Systems....................................................127
Creating Library Objects for Include Files......................................127
Using Base versus User-Defined Block Templates.........................128
Importing SaveAlls into a Single or
Multiple Bulk Data Objects.............................................................128
Migration from IACC with Field Device Manager.........................128
I/A Series Alarm Provider...................................................................129
Backup Alarm Provider...................................................................129
Alarm Logging Configuration.........................................................129
SMC Logging Configuration ..............................................................130
Ensure Time Master Node Is Not Enabled .........................................132
Changing Date and Time ....................................................................132
CHAPTER 11: Backing Up and Restoring

Data...................................................................133
Data to Back Up and Restore..............................................................133
Galaxy Data.........................................................................................134
Backing Up a Galaxy ..........................................................................134
Backing Up a Condition Monitor Database with
ACM Installed.....................................................................................135
Restoring a Galaxy from a Backup .....................................................135
Restoring a Condition Monitor Database with
ACM Installed.....................................................................................136
Exporting Selected Objects.................................................................136
Importing Selected Objects into a Galaxy ..........................................138
Importing Script Function Libraries ...................................................139
After You Import.................................................................................139
Backing Up the SQL Server Databases ..............................................140
Backing Up History Data....................................................................142
Restoring History Data........................................................................142
Backing Up the Alarm Message Database..........................................142
Control HMI and Data ........................................................................142
CHAPTER 12: Support for Multiple Galaxy

Servers on the Same Instance
of The Foxboro Evo Control
Network ............................................................143
General Considerations .......................................................................144
System Configuration Using System Definition.................................145
System Configuration Using the Foxboro Evo Control Software ......146
Runtime Security Considerations/Operations.....................................148
Historization........................................................................................149

Contents vii
Alarming............................................................................................. 149
CHAPTER 13: Using Direct Access for

Strategy Template Distribution ......................151
Overview ............................................................................................ 151
Running Direct Access....................................................................... 152
Exporting to a Command File ............................................................ 154
Added Control Blocks, Declarations .............................................. 156
Deleted Control Blocks, Declarations ............................................ 157
Control Block Parameter Changes ................................................. 159
Nested Strategies ............................................................................ 160
Validating the Update ..................................................................... 161
For More Information......................................................................... 161
CHAPTER 14: Setting up Multiple Galaxy

Communications .............................................163
Overview ............................................................................................ 163
Supported Multiple Galaxy Topologies.......................................... 165
Off-Control Network ...................................................................... 165
How to Pair Galaxies.......................................................................... 166
Procedure for Pairing Galaxies....................................................... 168
Deployment of ArchestrA Services ................................................ 173
Pairing Off-Control Network Galaxies........................................... 176
Pairing On-Control Network Galaxies ........................................... 177
CHAPTER 15: Foxboro Evo Control

Software Support for
RedundantDIObject.........................................179
CHAPTER 16: Triconex Integration ...............183

Overview ............................................................................................ 183
Triconex TSAA Device Integration Object (TSAA DI Object)......... 184
Unified Foxboro Evo System Triconex Configuration ...................... 185
Triconex Safety Configuration Data .................................................. 186
Importing Triconex Safety Configuration Data.............................. 187
Triconex Foxboro Evo System Unified
Configuration Network Diagram.................................................... 189
CHAPTER 17: Unity Pro Integration ..............191

Overview ............................................................................................ 191
Unified Control System Unity Pro Configuration.............................. 192
Unity Pro Configuration Data ............................................................ 193

viii Contents
Importing Unity Pro Configuration Data ........................................193
CHAPTER 18: Asset Condition Monitor -

Additional Considerations .............................195
Condition Monitor Runtime Application Objects...............................195
Changing Passwords for User Accounts for SQL Replication ...........196
Adding a New Asset Condition Monitor Client After Password
Change.............................................................................................196
Restarting the Galaxy Server After a Password Change .................196
Restarting the Client Workstation After a Password Change..........197
Configuring Device Condition Severity Mapping ..............................197
Asset Condition Monitor Uninstallation .............................................198
Backing Up Condition Monitor Databases .........................................199
Restoring Condition Monitor Database...........................................200
APPENDIX A: Multi Monitor Setup for InFusion

View 1.x ............................................................203
Multi Monitor Setup for InFusion View 1.x Overview ......................204
Installing the Multi-Monitor Driver on
Windows XP Workstations .................................................................204
Installing the Multi-Monitor Driver on Windows
Server 2003 Servers ............................................................................213

ix
Before You Begin
About This Book

This document is intended to be one of the first documents (if not the first
document) to be read by users who are setting up systems with Foxboro Evo™
Control Software (hereinafter referred to as the Control Software). It contains
general concepts and guidelines for planning, configuring and deploying
systems with the Control Software. However, always be sure to read the
applicable version of the release notes shipped with your software. The release
notes describe any known issues and important release-specific user notes.
Assumption
It is assumed that the user has read and is familiar with the terminology in the
Wonderware FactorySuite A2® Deployment Guide. Much of that information
applies but is not repeated here.
Revision Information
For Revision Z of this document, the following changes were made:
Chapter 6, "Terminal Services and Remote Desktop Services"
• Added a note to “Network Load Balancing for Remote Desktop Protocol
Sessions” on page 106.
Where to Get More Information

Since the Control Software runs on top of the ArchestrA architecture and
incorporates several Wonderware® products, much of the documentation
written by Wonderware is relevant. In addition, there are documents that
describe features specific to the Control Software. Below is a list of documents
that can provide additional information that is beyond the scope of this
document. These documents can be accessed from the Global Customer
Support web site:
https://pasupport.schneider-electric.com

x Before You Begin
Related Wonderware Documentation

The following documents are available on the corresponding Wonderware
product CD.
• Wonderware® FactorySuite A2 Deployment Guide
• Wonderware® Industrial Application Server User’s Guide
• ArchestrA™ Integrated Development Environment (IDE) User’s Guide
• Wonderware® FactorySuite® Terminal Services for InTouch® Deployment
Guide
• InTouch® Data Management Guide
• Wonderware® FactorySuite® InTouch® Reference Guide
• Wonderware® FactorySuite® IndustrialSQL Server™ Concepts Guide
• Wonderware® FactorySuite® IndustrialSQL Server™ Administration
Guide
• Wonderware® FactorySuite® IndustrialSQL Server™ Installation Guide
• Wonderware® FactorySuite® IndustrialSQL Server™ Database Reference
• Wonderware Tech Note 368 “Network Setup for AppEngine Redundancy”
• Wonderware Tech Note 401 “Fine-Tuning AppEngine Redundancy
Settings”
Foxboro Evo Documentation

During the Control Software installation, most of the documents associated
with the software components being installed are also installed. These
documents can be viewed from the Start > Programs > Invensys > InFusion
Documentation menu. These documents are also provided on the Control
Software installation media.
Additionally, updated user documentation can be found on the Global
Customer Support (GCS) website.
Installation and Getting Started

• Foxboro Evo Control Software Installation Guide (B0750RA)
• Hardware Configuration User’s Guide (B0750BB)
System Development
• Appearance Object Editor User’s Guide (B0750AE)
• Bulk Data Editor User’s Guide (B0750AF)
• Common Graphical Editor Features User's Guide (B0750AG)
• Block Configurator User’s Guide (B0750AH)
• Control Database Deployment User’s Guide (B0750AJ)
• PLB Ladder Logic Editor User's Guide (B0750AK)
• Sequence Block HLBL Editor User’s Guide (B0750AL)

Before You Begin xi
• Sequence Block SFC Editor User’s Guide (B0750AM)

• Strategy Editor User’s Guide (B0750AN)
• Configuration Utilities User’s Guide (B0750AZ)
• Logic Block Editor and Troubleshooting Tool User’s Guide (B0750BL)
• Scripting with Direct Access User’s Guide (B0750BM)
Security
• Access Manager User’s Guide (B0750AD)
End-user Graphical User Interface Configuration and

Operation
• System Manager (B0750AP)
• Control HMI Application User's Guide (B0750AQ)
• Framer and Alarm Management User’s Guide (B0750AR)
• Window Construction User’s Guide (B0750AS)
Field Devices
• Implementing FOUNDATION fieldbus in Foxboro Evo Control Software
Applications (B0750DA) or Implementing FOUNDATION™ fieldbus
User’s Guide for InFusion v1.x (B0750BC) (obsolete - for InFusion v1.x
only)
• Foxboro Field Device Manager and Foxboro Instrument Manager for
PROFIBUS Networks Installation Guide (B0750CK)
• Implementing PROFIBUS™ Networks in Foxboro Evo Control Software
Applications (B0750BE)
PROFIBUS Networks Installation Guide (B0750CJ)
• Implementing a DeviceNet Network on the Foxboro Evo Automated
Process Control System (B0750CH)
FOUNDATION fieldbus Installation Guide (B0750CL)
• Using HART Instrumentation for the Foxboro Evo Process Automation
System (B0750CM)
• Field Device Manager for HART Devices Installation Guide (B0750CN)
Printed Manuals
In addition, printed copies of the following documents are shipped with the
Foxboro Evo Control Software media kit:
• Foxboro Evo Control Software Deployment Guide (this document)
(B0750BA)
• Foxboro Evo Control Software Installation Guide (B0750RA)

xii Before You Begin
• The appropriate release notes for your version of the Foxboro Evo Control
Software.
Glossary
DA Server Data Access Server

DI Object Device Integration Object
Galaxy This is the database used by ArchestrA® architecture. All ArchestrA objects
and configuration data are stored in this database. Also referred to as
“Galaxy Repository.”
Note The Galaxy cannot be named "Galaxy". However, you can use the
word “Galaxy” as part of the name, for example: “MyGalaxy”.
Historian The Historian for the Control Software uses the Wonderware Historian —
formerly known as “IndustrialSQL Server™ Historian” or “InSQL™
Historian”.
HMI Human Machine Interface
IADAS I/A Series® Data Access Server
IDAS InSQL Data Acquisition Service. This is a software application that accepts
data coming from one or more I/O Servers and forwards it to a Wonderware
Historian Server.
IDE ArchestrA Integrated Development Environment
Control Core Services Core software environment, formerly known as “I/A Series software”. A
software workstation which runs this software is known as a “Control Core Services
workstation” or a “workstation”.
Foxboro Evo Control Formerly known as “FCS Configuration Tools”, “InFusion Engineering
Editors Environment”, or “IEE”, these are the Control Software engineering and
configuration tools built on the ArchestrA Integrated Development
Environment (IDE).
Foxboro Evo Control The collection of windows and related configuration files that make up the
HMI HMI as viewed within InTouch® software. Also formerly known as the
“FCS InTouch Application”.
The Foxboro Evo Formerly known as “The Mesh control network”, the Foxboro Evo Control
Control Network Network is a switch network that facilitates communications among the
workstations/servers and control processors.
Foxboro Evo Control Formerly known as “Foxboro Control Software (FCS)” and “InFusion”, a
Software suite of software built on the ArchestrA Integrated Development
Environment (IDE) to operate with the Control Core Services software.
Letterbug A six-character name given to a Foxboro Evo or I/A Series station. In the
case of a workstation or server, it is its computer name.
MX ArchestrA Message Exchange protocol

Before You Begin xiii
NAD Network Application Development. This refers to the InTouch mechanism

for centrally developing a Control HMI and then distributing the application
to client workstations. This is the mechanism used for making the Control
HMI application available to multiple clients on a Terminal Server
workstation.
Node A workstation or server. Do not confuse this with the definition of a node in
a Foxboro Evo or I/A Series system which is “a Local Area Network (LAN)
comprised of a grouping of hardware and software components.”
OAJ Operator Action Journal
Object This term can refer to standard ArchestrA objects (e.g., platforms,
application engines, areas, floats, ints, etc.) or Foxboro Evo objects
(compounds, control processors, etc.).
Off-control network A workstation or server which does not have Foxboro Evo software
installed on it, on a network which connects to the Foxboro Evo Control
Network. It may have the Foxboro Evo Control Editors installed on it,
though.
If used to describe a network, it refers to a customer-supplied network
which connects to the control network.
Point A data item. Also referred to as a “tag” or a “parameter” or a
“compound:block.parameter” or “C:B.P” in Foxboro Evo parlance.
SMC ArchestrA System Management Console
Stand-alone A station not connected to a Foxboro Evo or I/A Series network.

xiv Before You Begin

1
C H A P T E R 1
General Concepts
This chapter gives an overview of general concepts of a system with the

Control Software. It also describes differences and similarities of the Control
Software system and the Foxboro Evo/I/A Series system.
Contents
• Overview of Foxboro Evo Control Software Components
• Definition of Objects
• I/A Series Browser
Overview of Foxboro Evo Control Software

Components
The Control Software product line builds on the Foxboro Evo/I/A Series by
integrating it with ArchestrA and Wonderware products. The Control Software
includes the following main components:
• Control HMI – An InTouch display application providing an alternative
to FoxView™ software and FoxDraw™ software.
• Control Editors – Engineering and configuration tools built on the
ArchestrA Integrated Development Environment (IDE).
• System Manager – A system management user interface for Microsoft
Windows® workstations as an alternative to SMDH.
• Control Software Access Manager – Infrastructure integration with
Foxboro Evo/I/A Series real-time data and messaging in the form of a
I/A Series Device Integration Object, I/A Series History Provider,
I/A Series Control Security Provider, Galaxy Sync Service and an
I/A Series Alarm Provider.
• Control Software Installation – An application that consolidates the
installation of the individual software components into one installation
program.
• ArchestrA System Platform – The ArchestrA software that provides the
ArchestrA infrastructure and client applications such as the IDE and SMC.
This software provides for the creation of and the interaction with the
Galaxy Repository.

2 1. General Concepts
• Wonderware Historian – The data Historian based on SQL software.

Figure 1-1 shows the relationship between these components and the
Foxboro Evo/I/A Series components.
Comparison between I/A Series and Foxboro Evo

Control Software Components
Table 1-1 should be helpful to those who are transitioning from using previous
I/A Series software components to the new Control Software components.
Table 1-1. Comparison of I/A Series and Foxboro Evo Control Software Components
Foxboro Evo Control

Function I/A Series Component Software Component
Systems Management System Manager System Manager
Displaya
Process Graphicsb FoxView software Control HMI
Process Alarmsb Alarm Manager InTouch alarm control
Runtime Control Database FoxSelect™ software Block Select
Browser
System Configuration SysDef or IACC Hardware Objects (Control
Editors)
Control Configuration ICC, FoxCAE, or IACC Compound and Strategy Objects
software (Control Editors)
Data Historian AIM*Historian™ software Wonderware Historian
Alarm Historian AIM*Historian software SQL Server database
Historical trends FoxView software Historian client trends in Control
HMI
FOUNDATION fieldbus Field Device Manager for Field Device Manager for
support FOUNDATION fieldbus (IACC) FOUNDATION fieldbus (Control
Editors)
Profibus support Limited support for the Field Device Manager for
FBM222 is provided by ICC Profibus
DeviceNet support System Manager, Field Device Manager for
ICC,FoxCAE, or IACC DeviceNet
software
HART support System Manager, ICC, Field Device Manager for HART
FoxCAE, or IACC software Devices
a. The System Manager has a server component and a client component. The System Manager service and
SMDH cannot run side-by-side on the same station.
b. Users may continue to use FoxView software and Alarm Manager. However, users may not install both HMIs
(e.g., FoxView software and Control HMI software) on the same workstation. Different workstations in a sys-
tem may have different HMIs.

1. General Concepts 3
Foxboro Evo Control Software Components*

Control HMI Control Editors
Detail Displays (ArchestrA IDE-based)
Alarm Viewing Hardware Configuration System
Trend Displays Strategy Editor Manager
Navigation Configurator Block Configurator
Annunciator Configurator PLB Ladder Logic Editor
Block Select Sequence Block HLBL Editor
Control Galaxy Browser Sequence Block SFC Editor
Bulk Data Editor/Generation
Appearance Object Editor
Logic Block Editor
Wonderware InTouch Foxboro Evo/I/A Series Control Database Deployment
Annun.
Dist. Alarm Window Upload
Config.
Subsystem Viewer
Live Data
Display
Alarm
Annunciator Alarm Device Int. Security
Provider Provider Object Provider
Field Device Manager
Galaxy Configuring field device
Sync databases (e.g., resource
Service and transducer blocks)
Commissioning field devices
Running DD methods
Diagnosing field devices
History Using diagnostic applications
Alarms Provider from device vendors (DTMs)
and
Events
Wonderware
Historian
Annunciator Messages Control Compound System

(process and Object
Keyboards Station Summary Monitor
system alarms, Manager
(GCIO/USB) Database Access Subsystem
and OAJ)
Commit SFC and

I/A Series/Foxboro Evo Components* Media/ PLB
Reconcile Code
Media Files
* Galaxy repository and relationships between Foxboro Evo components are not shown in order to
reduce the diagram’s complexity.
Figure 1-1. Overview Relationship of Foxboro Evo Control Software
Components and I/A Series/Foxboro Evo Components

Note The Foxboro Evo Control HMI gains a significant performance boost in
processing when run on a workstation or server with the multiple CPU core
feature enabled. It is recommended that, if your Foxboro workstation or server
supports the multiple CPU core feature and you are running the Control HMI
on it, that you enable the multiple CPU core feature. Refer to the Hardware
and Software Specific Instructions included with your workstation or server to
determine if your station supports the multiple CPU core feature.
Definition of Objects
The ArchestrA technology is object-oriented. Objects can represent physical
entities such as pumps and valves or abstractions of concepts such as control
blocks. An object could be as simple as an integer value or as complex as a
plant unit.
Objects are configured using editors that are displayed in the Integrated
Development Environment (IDE). The Control Editors provide a set of editors
pertaining to objects related to Foxboro Evo systems that run in the IDE.
Note Many objects used in the Control Software (such as libraries, strategies,
certain block templates, etc.) are reliant on the Galaxy repository for their
attributes. If network access becomes unavailable to a client that is performing
modifications on these objects, these objects will be unusable and unavailable
for modification until network access to the Galaxy is restored.
PROFIBUS Objects
For information about PROFIBUS, refer to Implementing PROFIBUS™
Networks in Foxboro Evo Control Software Applications (B0750BE).
FOUNDATION fieldbus Objects

For information about FOUNDATION fieldbus, refer to Implementing
FOUNDATION fieldbus in Foxboro Evo Control Software Applications
(B0750DA).
DEVICENET Objects
For information about DeviceNet, refer to Implementing a DeviceNet Network
on the Foxboro Evo Automated Process Control System (B0750CH).
HART® Objects
For information about HART devices, refer to Using HART Instrumentation
for the Foxboro Evo Process Automation System (B0750CM) and HART
Communication Interface Modules User's Guide (B0400FF).

1. General Concepts 5
RedundantDIObject
Refer to Chapter 15, “Foxboro Evo Control Software Support for
RedundantDIObject” on page 179.
I/A Series Browser

A browser is provided in the IDE, WindowMaker™ application, and Framer to
facilitate the selection of compounds and blocks that have been configured in
the Galaxy. This browser uses a cache that is generated at the Galaxy
Repository server and is propagated to client workstations where the browser
is invoked. For a more detailed description, refer to Access Manager User’s
Guide (B0750AD).


7
C H A P T E R 2
Sizing and Performance
This chapter gives an overview of the sizing and performance of the Foxboro
Evo system components.
Contents
• Minimum System Requirements
• Configuration Guidelines
• Sample Configurations
Minimum System Requirements

The minimum system requirements for any workstations, servers, or domain
controllers which can operate in the Foxboro Evo system are detailed in the
“Hardware Requirements” chapter in the applicable Control Core Services v9.x
Release Notes included with your Foxboro Evo system.
Each workstation or server requires a certain amount of disk space to be
reserved for the following applications/services:
• For a Galaxy Repository server or an Wonderware Historian server -
20 GB
• For an operator workstation or a Historical Data Collector - 10 GB
• For a server hosting Terminal Services or Remote Desktop Services -
20 GB + 3 GB multiplied by "the number of remote InTouch users"
For ControlHMI Managed Applications, free disk space is required in the
C: drive. To configure the required disk space based for the number of
remote InTouch users, follow the procedure provided under “How to
Configure a Hard Disk” on page 8.
Note The Terminal Services feature that was available in Windows XP

and Windows Server 2003 has been renamed to “Remote Desktop
Services” for Windows 7 and Windows Server 2008 R2 Standard.
Notes:
1. All stations that will have SQL Server 2005 software installed on them
must have a DVD reader since the SQL Server 2005 software is only
provided on DVD media.

8 2. Sizing and Performance
2. The SMC log file can get large and quickly deplete available hard disk
space. By default, the SMC log file is installed on the C: drive and has a
default maximum size of 5 GB.
Caution It is highly recommended that you move the log file to the D: drive,
and if desired, reduce the maximum size of the log file. Refer to “SMC
Logging Configuration” on page 130 for instructions on how to move the log
file to the D: drive.
3. All stations that will be running Control HMI must have monitors capable
of being set to 1280 x 1024 or 1920 x 1080 screen resolution. This
includes remote client stations accessing a Terminal Server running the
Control HMI.
4. Multiple monitors are supported by the Control HMI.
How to Configure a Hard Disk

This section explains how a Hard disk can be configured based on the user
requirements after the Work station or server has been ghosted with the restore
DVD provided. Each user will require additional space from the C: drive. To
configure the hard disk, please follow the below steps.
1. Go to Start Menu > Control Panel > Administrative Tools.
2. Select and open Computer Management. A window will appear as
shown in Figure 2-1.
Figure 2-1. Opening Computer Management
3. Expand Storage and select Disk Management as shown in Figure 2-2.

2. Sizing and Performance 9
Figure 2-2. Selecting Disk Management

Extending a Drive
The C: drive must be extended, but to do so, the D: drive must be deleted first.
1. To delete the drive, select the D: drive as shown in Figure 2-3. Right click
on it, and select Delete Volume from the menu.
Figure 2-3. Deleting a Drive
2. Right click on the Free space partition (which was previously assigned to
D: drive) and select Delete Partition as shown in Figure 2-4. After the
partition has been deleted, the Free space label becomes Unallocated as
shown in Figure 2-5.
Figure 2-4. Deleting a Partition

Figure 2-5. Unallocated Free Space
3. Once the partition has been deleted, the C: drive can be expanded. Select
the C: drive and right click. Then select Extend Volume as shown in
Figure 2-6.
Figure 2-6. Extending Volume
4. A new window will appear with title Extend Volume Wizard as shown in
Figure 2-7. Click Next.

Figure 2-7. Extended Volume Wizard
5. Enter the amount of space by which you would like to expand the C: drive
into the Extend Volume Wizard dialog box. In the example in Figure 2-8,
the C: drive will be expanded by 50000MB, which comes to 48.82GB.
Click Next.
Figure 2-8. Extended Volume Wizard Dialog Box
6. Click Finish to complete the Extend Volume Wizard as shown in

Figure 2-9.

Figure 2-9. Completing the Extended Volume Editor
7. After completing the steps above, the C: drive’s new current capacity will
be shown, as seen in Figure 2-10.
Figure 2-10. Extended Drive
New Volume Creation

If you deleted the D: drive in the previous procedure, you must now bring it
back. The following procedure explains how to bring back the D: drive by
creating Simple Volume.
1. To allocate the other block of space, right click on it and select New
Simple Volume from the menu as shown in Figure 2-11.

Figure 2-11. Selecting a block of space
2. The New Simple Volume Wizard pop-up window will appear as shown
in Figure 2-12. Click Next.
Figure 2-12. New Simple Volume Wizard
3. In the editable field, enter the size to be allocated for the new Volume (as
shown in Figure 2-13). If you would like to allocate the entire space to one
drive, enter the maximum value (in this case 324015MB). If you need to
make multiple volumes, enter a value which suits the requirement. Click
Next.

Figure 2-13. Specifying Value Size
4. Select the 1st radio button Assign the following drive letter. Accept the
default drive letter or choose a different drive letter to identify the partition
(as shown in Figure 2-14), and click Next.
Figure 2-14. Assign the following drive letter
5. In the Format Partition step (as shown in figure 15), do the following.
a. Select the 2nd radio button Format this volume with the following
settings.
b. Select NTFS and Default from the drop downs against File system
and Allocation unit size respectively.
c. In the editable field against Volume label, enter preferred text by
which the drive can be recognized.
d. Select the checkbox against Perform a quick format.

e. Click Next.
Note If the checkbox is not selected for Perform a quick format, it will
take several minutes to format the partition.
Note Selecting the checkbox against Enable file and folder

compression will compress all the files and folders as and when they are
created.
Figure 2-15. Format Partition
6. The details will be displayed in the Completing the New Simple Volume
Wizard page as shown in Figure 2-16. Review the settings and click
Finish to complete the new volume creation.
Figure 2-16. Completing the New Simple Volume Wizard
7. The new drive D: is created as shown in Figure 2-17.

Figure 2-17. The Newly Created Drive
Quick Reference of Recommendations

Refer to the following table for sizing and performance recommendations for
components of the Control Software.
More
Item Supported/Recommended Information
Control Editors < 150 control blocks per strategy see page 18
Terminal Server Up to 10 remote clients on virtual or see page 20
physical machines without the
multicore feature enabled or 15 remote
clients on physical machines with the
multicore feature enabled, with 50
points updated per second
Wonderware up to 30,000 points per Historian see page 21
Historian collector
Security Provider up to 1000 attributes / second see page 53
Galaxy Sync Service refresh process time 5 to 15 minutes / see page 83
CP
Alarm Provider 2000 alarms / workstation (default see page 129
maximum)
SQL Databases Perform backup at least once per week see page 140

Configuration Guidelines
The following guidelines have been derived from test data and user experience.
They should help users to avoid some pitfalls and to configure successful
systems.
System Topology Considerations

1. While it is possible to install all the software on one computer, such a
system might not deliver the desired or expected performance. It is
recommended to separate basic functions into separate stations, e.g., have
separate stations for the following:
• Hosting the Galaxy Repository
• Storing the Wonderware Historian
• Operator stations
• Engineering stations
• Historical data collector
Note Refer to “Sample Configurations” on page 32.
2. For configurations that include the AIM*Historian software, this Historian

should not be installed on the Galaxy Repository server, or a Historical
Data Collector.AIM*Historian software may be installed on a workstation
that has the Control Editors installed on it.
3. For commissioning and device maintenance of field devices, the
engineering stations running Field Device Manager for FOUNDATION
fieldbus must be on the Foxboro Evo Control Network (hereinafter
referred to as the control network).
Control Editors Considerations

1. Plan to do as much initial configuration (e.g., system definition and
control database creation) as possible using a stand-alone computer. This
reduces the network and CPU load on the runtime system. Refer to
Chapter 10, "Configuration and Installation Considerations" for details.
The process of doing the initial configuration on a stand-alone
computer and migrating it to the Enterprise Control system should
only be done once because it completely replaces the Galaxy Repository
database on the runtime system. Once the initial configuration is migrated
to the runtime system, any modifications should be performed on the
runtime system.
2. When deploying a large number of objects, e.g., deploying all the blocks
that will reside in a controller at once, the workstation on which the
deployment operation is invoked and the Galaxy Repository server will be
very busy for some length of time. During such operations, both the
workstation and the Galaxy Repository server will not be very responsive.
Such operations should only be performed one at a time to completion
before starting another one. The list of such operations are:

• Import
• Export
• Bulk generate
• Bulk create
• Large deployments (such as an entire controller or equipment unit)
• Validate network (preparing for generating Commit media)
• Refresh History and Security Database.
While any of these operations are in effect, no additional operation from
the above list should be initiated from another IDE client. Normal
keyboard editing operations (such as editing a strategy or block), while
still possible, are adversely affected.
Note All operations on Galaxy Repository are serialized so that there is no

performance advantage initiating multiple long running operations from
multiple engineering workstations at the same time. This is in contrast to
performing these operations sequentially from a single workstation.
3. Backups of the Galaxy Repository should be done prior to and

immediately after large bulk operations. Refer to Chapter 11, "Backing Up
and Restoring Data" for details.
4. To restore a Galaxy cab file, make sure there is free disk space on the C:
drive, equivalent to 7 times the cab file size. If the cab file is "n" GB, then
the free disk space on C: should be "7*n" GB.
5. It is not recommended that strategies be generated with more than 150
blocks in them. This number of blocks in a single strategy has been
deemed more than sufficient for even the largest control applications.
Testing with larger strategies (e.g., 1000 blocks) has proven to have
several workstation performance-related issues, including editing and
saving the strategy. Be careful about using the option to place all blocks in
the same compound into a single strategy during an import SaveAll;
otherwise, overly large strategies may result.
Note A child strategy is considered to be a single block when dealing with

nested strategies.
6. The performance of the Live Data Display is directly impacted by the

number of parameters in a strategy that are displaying live data. Fewer
updating parameters result in better performance.
7. It is highly recommended that all SaveAlls for a particular configuration
be imported into the SAME bulk data object. This procedure ensures that
peer-to-peer connections between blocks in the various SaveAlls are kept
intact. Splitting up SaveAlls between multiple bulk data objects requires a
lot of extra work on the part of the user to re-establish peer-to-peer
connections.
The bulk generations of each CP do not have to be executed at the same
time.

8. When importing SaveAll data, be sure to generate the FBMs and related
hardware items first. Refer to the Bulk Data Editor User’s Guide
(B0750AF) document.
Terminal Server Considerations

1. A server that is providing Terminal Services or Remote Desktop Services
must be equipped with an adequate amount of memory (see below) to
handle the number and kind of applications that will be running on it for
remote sessions.
Note The minimum amount of memory for the 32-bit version of

Windows Server 2003 operating system is 4 GB.
2. The load on a Terminal Server can vary greatly depending on a number of

factors such as how many remote sessions are running simultaneously and
what kind of applications and operations are being performed in those
sessions. When running the Control HMI software on a client workstation,
the number of points on display and the rate at which data is being updated
has a direct impact on the CPU load of the server. As a rule of thumb, a
Dell PowerEdge® 2800 server with a 3.2 GHz single-core Xeon®
processor can support up to ten remote Control HMI sessions on virtual or
physical machines without the multicore feature enabled, or 15 remote
Control HMI sessions on physical machines with the multicore feature
enabled, each of which having 50 points updating every second.
3. Note that InTouch software requires that each remote session to a Terminal
Server be logged on using a different user account. The procedure for
setting up a Terminal Server for InTouch is described in Chapter 6,
"Terminal Services and Remote Desktop Services".
4. The first time Control HMI software is invoked from a remote user session
to a Terminal Server, a complete copy of the Control HMI is made for that
logged-on user account. Each application copy can require 1.5 to 3 GB.
Hence, if there are going to be five remote users using Control HMI
software, there must be enough hard drive space to hold 15 GB worth of
InTouch application data in the NAD folders.
5. The first time you log in to a Terminal Server with a user account
configured to start the Control HMI, it takes about 20 minutes for the
InTouch application to completely install. Some of that time is associated
with populating the NAD folder associated with that user account, but the
bulk of that time is required to compile the InTouch application. During
this time, it is normal to see the CPU load on the server reach 100%. To be
clear, this only occurs the first time a given user account is used to log in
to the terminal server. For subsequent logins using the same user account,
any new or modified windows need to be compiled. The length of time it
takes for the Control HMI window to come up and be functional is
dependent on the number of changes to the Control HMI.

Wonderware Historian and Historian Data

Collector Considerations
1. The Historian Data Collector can be installed on any workstation class
machine running the Windows 7® or Windows XP® operating system.
The Historian Data Collector cannot be installed on the server class
machine.
2. The maximum number of historical points per collector is 30,000 where
the collector is a Windows 7 or Windows XP workstation with a 3.2 GHz
processor and 2 GB RAM. This is assuming a scan rate of one second with
5,000 changes per second. For every additional 30,000 points being
historized, add a separate collector workstation.
3. The maximum number of tags that should be historized in a single
Wonderware Historian database on a Dell PowerEdge 2800 with 3 GB
RAM is 70,000.
4. It is recommended that you undeploy all history app engines
(<letterbug>_AppH) that are not used. This minimizes the load on the
workstations, as well as on the Galaxy Sync Service (which must respond
to periodic requests for configuration data from each of the deployed and
On Scan history app engines).
5. If communication between Wonderware Historian and an I/A Series
History Provider is interrupted (e.g., a network communication issue or
activity causing 90-100% CPU utilization for periods of more than a
second on the Wonderware Historian server), data being collected by the
I/A Series History Provider may be lost for the period of the interruption
and/or for several seconds following the period of interruption. This issue
can occur in both simplex and dual redundant collector configurations. To
minimize the chance of data loss due to CPU activity, ensure that the
Wonderware Historian server normally utilizes less than 50% of its CPU
and that activities such as file back-up, virus scanning, etc. on the
Wonderware Historian server run during non-critical times or do not cause
the system to exceed 75% CPU utilization.
System Manager Considerations

The System Manager has a server component and a client component. The
client component is typically installed on every operator workstation.
However, during the installation, you are asked to choose the workstations on
which you want to install the server component. It is recommended that you
install the server on only one or two workstations to avoid excessive traffic on
the network.
For information on starting and stopping the System Manager service, as well
as procedures for checking the status of the System Manager service, refer to
the section titled “The System Manager Service” in System Manager
(B0750AP).

Field Device Manager Considerations

The Field Device Manager for FOUNDATION fieldbus is an add-on application
to the Control Editors for configuring, calibrating, commissioning, diagnosing,
and maintaining FF devices. Related databases are maintained by the Galaxy
Repository. The communication path between Field Device Manager and the
field devices consists of an FDT compliant H1 Communication DTM on top of
a Field Device Access driver in the workstation that communicates to the
control network. Communication to the field devices over the control network
is independent of the boot host for the Control Processor. Field Device
Manager communications then pass through the Control Processor and FBM to
the H1 field bus. If Field Device Manager is installed on workstations off the
control network, only off-line field device engineering is possible.
The FOUNDATION fieldbus Support component must be installed on the Galaxy
server as well as each client that will utilize the Galaxy server. Therefore, when
using FF, Field Device Manager and FF Support should be installed on all
Control Editors clients. Field Device Manager software can be run on
Windows workstations.

Asset Condition Monitor Considerations

Asset Condition Monitor is an add-on application to configure, capture and
convert device conditions from FBM connected HART and FOUNDATION
fieldbus devices to human readable text that can be viewed and acknowledged
in Control HMI or in the separate Maintenance Response Center application.
Refer to the Maintenance Response Center User’s Guide (B0750CP) for more
information.
System Configuration
Asset Condition Monitor v1.0 requires Foxboro Evo Control software v6.0.4
or greater.
This optional software must be installed on both Galaxy servers and
engineering client workstations. It is not required on operator or historian
workstations. The software must be installed first on Galaxy server and then
installed on the client workstations. All client workstations running the Asset
Condition Monitor software must be connected to the Control Network.
You may choose to install Condition monitoring support for FOUNDATION
fieldbus or HART or both. The Asset Condition Monitor support for a fieldbus
protocol can be installed only if Field Device Manager v3.1.2 or greater for
that protocol has already been installed on the system. You should be able to
designate a single node in the Galaxy as the backup node for all of your
Condition Monitoring application engines. A sample configuration using ACM
is presented below.

Figure 2-18. Sample ACM Configuration with MRC
Asset Condition Monitor Installation

The Asset Condition Monitor install for FOUNDATION fieldbus creates the
FF Condition Monitor object template $FF_Device_AM and the install for
HART creates the Hart Condition Monitor object template
$HART_Device_AM. Asset Condition Monitor install also creates and
deploys a separate application engine instance, <WorkStationName>_AppAM,
on every machine on which it is installed. Condition Monitor runtime objects
will be hosted by this AppEngine. The name of the dedicated Condition
Monitor application engine instance must not be changed.
Asset Condition Monitor uses the Standard Microsoft SQL Replication feature
to replicate device condition configuration from Galaxy server to Client
systems where Asset Condition Monitor is installed. When Asset Condition
Monitor is installed on a Galaxy Server, you will be prompted for a user name
and password for configuring SQL replication. The default user name is
IAServices on a secure system and Fox on a standard system. We recommend
you use a user account whose password will not expire or change for
configuring SQL replication.
The user account must be created before installing Asset Condition Monitor.

For additional information, refer to the Asset Condition Monitor Installation

Guide (B0750CR).
Asset Condition Monitor Configuration

Device conditions for monitoring are configured using the device editor. DCI
blocks are configured to read the configured parameters. Area objects
representing the physical plant areas or logical parts of the automation process
need to be created manually and assigned to the Condition Monitor
Application engine. Devices for which conditions need to be monitored need to
be associated with an Area. This association is performed in the device editor.
A condition monitor runtime application object instance is created when the
first device instance is assigned to the Area.
There will be only one condition monitor runtime application object instance
per protocol under an Area and it will contain all devices of the protocol
assigned to the Area.
When condition monitor runtime application object is deployed to the Win
Platform, devices contained by the runtime object are continuously monitored
and condition messages are generated for conditions set in the devices.
Condition monitor runtime objects must be deployed to a Win Platform that
will not be shut down. Otherwise, there will be loss of conditions monitoring.
For optimum performance, it is recommended that you assign up to 5000
devices per Condition Monitoring application engine on a workstation.
It has been observed that the AppEngine scan period to be used depends on:
• The number of configured devices monitored by the AppEngine
• The rate at which device conditions occur and processed as alarms.
A scan period of two minutes was found to monitor 5000 devices with 100
alarms/minute and an average CPU usage of less than 5%.
Using a faster scan period was found to increase the CPU and memory usage,
which may impact other applications running on the same system.
Redundancy Support for Condition Monitoring

Application Engine
Asset Condition Monitor will use the standard ArchestrA Application Engine
Redundancy to ensure continued runtime operation. For Application Engine
redundancy you must configure two WinPlatforms. When redundancy is
enabled for an Application Engine, ArchestrA will automatically generate a
backup Application Engine.
Refer to Application Server User's Guide, provided as part of the Wonderware
Documentation for details on how to configure Application Engine
redundancy.
The Backup Condition Monitoring Application Engine must be assigned to the
WinPlatform of the computer that will just serve as backup system for
Condition Monitoring. This means the backup computer WinPlatform should
not have any Condition Monitor Runtime Application objects running in its

primary Condition Monitor Application Engine. This setup will cover

Condition Monitoring from a single point of failure.
You should be able to designate a single node in the galaxy as the backup node
for all of your Condition Monitoring Application Engines. If any one of the
primary nodes fails, the system will continue with no degradation. However, if
a second node should fail, only then would loss of condition monitoring occur.
Because loss of condition monitoring is possible, the messages routed to the
backup should be manually returned to the primary as soon as one of the
primary platform is back on line.
This manual switchover can be done from the SMC:
1. Navigate to the platform manager in SMC in the backup node and click on
the <backupnode>_Plat
2. Identify the AppAM of the primary, which should now be healthy and
restored, to which you are switching over. Initiate a forced shutdown by
selecting Stop Engine™ on the context menu of the AppAM.
3. Click on <primarynode>_Plat and set Primarynode_AppAM on scan
using the right-click context menu. This will return the control to the
primary platform and all the device alarms will now be monitored by the
primary.
4. Click on <backupnode >_Plat and set Primarynode_AppAM off scan
using the right-click context menu to prepare it for the next failover.

Interoperability with Solaris™ Workstations on

The Foxboro Evo Control Network
Figure 2-19 illustrates a Foxboro Evo Control System topology that includes
Solaris™ workstations on the control network.
Remote Remote
Desktop Desktop
Client Client
I/A Series AW I/A Series AW I/A Series AW

with with with
Windows XP Windows Server Solaris 10
(I/A Series 8.6 (I/A Series 8.6 (I/A Series 8.4.2)
with QF*) with QF*)
The Foxboro Evo Control Network
ATS
FCP280 Hosted xCP270 Hosted
by Windows by Solaris 10 Nodebus
WSTA70/WSRV70 AW
(Control Core (I/A Series 8.4.2)
Services v9.0
or later) CP60 CP40B GW
Figure 2-19. Foxboro Evo System Topology that Includes Solaris

Workstations on The Foxboro Evo Control Network
Notes:
1. Solaris workstations on the control network only support the I/A Series
software v8.4.2 at this point. (The workstation software is at 8.4.2 and all
the CP and FBM images are at 8.4.2).
2. You can have v8.3 CPs hosted by v8.3 Solaris workstations and CPs
hosted by Windows workstations on the control network at the same time.
3. Solaris v8.3 workstations can receive alarm messages from CPs running
newer versions of software with no problem.
4. Control Editors running on a Windows station can be used to configure a
Solaris workstation on the control network.
5. Controllers can be configured to be controlled by either Control Editors or
ICC but not both. If the controllers that are hosted by Solaris workstations
on the control network are configured so that they are controlled by ICC,
then ICC can be used on the Solaris workstation. If deployment to
I/A Series software v8.3 controllers is controlled by the Control Editors,
then Control Editors will deploy only those blocks and/or attributes that

are valid for 8.3 (based on the PDEF/OLIST files on the hosting Solaris
workstation). Refer to the section “ICC and InFusion IEE Coexistence” in
InFusion V1.1 Release Notes, Control Edition (B0750RF) for additional
information on configuring controllers to either Control Editors or ICC.
6. The System Manager can monitor Solaris workstations and the stations
they host. The System Manager can also perform change actions on them
(for example, reboot them) assuming that the System Monitor has been
configured with the privilege to perform equipment changes.
7. The System Manager can run on Control workstations while SMDH is
running on Solaris workstations at the same time.
8. If there is at least one Solaris workstation on the control network, a QF
must be installed on all Windows-based workstations, even if the Message
Manager (MM) is not used. For pre-8.4 Windows-based workstations,
apply QF1008884. For 8.4 Windows-based workstations, apply
QF1010022.
9. Even if there are no Solaris workstations on the control network, if
QF1008884 has already been installed on any pre-8.4 Windows-based
workstation, then QF1010022 must be installed on all 8.4 Windows-based
workstations.
10. If a pre-8.4 Windows-based workstation has QF1008884 installed and it is
upgraded to I/A Series software v8.4, then apply QF1010022 after the
upgrade.
Note Refer to the Release Notes and installation procedures included with
your version of I/A Series or Foxboro Evo documentation for more detailed
interoperability information.

Off-Platform Foxboro Evo Control Software

Server Considerations
A popular Control Software configuration consists of an off-platform Galaxy
Repository server existing on a second Ethernet network with workstations
connecting to both the control network (for OM communications) as well as
the second Ethernet (for Mx communications). One of the biggest advantages
to this configuration is the fact that virtually any size server can house the
Galaxy, allowing you to take advantage of recent technology for performance
gains, bypassing the restrictions placed on server configurations which connect
to the control network (i.e., single core, single processor).
Note Enabling multiple processors does not significantly improve the overall
performance of the Galaxy Repository Server. This occurs due to single
threaded design of the Control Software. However, unrelated operating system
and other tasks (for example, the anti-virus scanner) utilize the additional
processors to provide some minor performance gain.
Figure 2-20. Off-Platform Server Configuration
NIC Card Binding Order Requirements

Note The NIC card binding order on each workstation must be configured
correctly to avoid problems with either I/A Series/Foxboro Evo or Mx
communications.

The off platform Galaxy Repository server configuration, as shown in

Figure 2-20, is as follows:
1. A Galaxy Repository is configured off-platform (that is, on a second
Ethernet network).
2. All workstations have dual NICs - both attached to the control network,
and the local onboard NIC connected to the second Ethernet network.
3. Workstations must have their default binding order set so that the network
connection carrying ArchestrA traffic is first in the binding order (the
onboard NIC card that is attached to the second Ethernet). This procedure
is explained below.
4. The host access settings in the Hummingbird Exceed® X server must be
modified to grant access to the FoxNIC card. This procedure is explained
below.
Adding Workstation or Server Access to Hummingbird

Exceed® X Server
If you have changed the NIC card binding order on the workstations (for
example, to support Control HMI with an Alarm Provider), the Hummingbird
Exceed® X server may reject any connections from a Foxboro Evo
workstation. When Exceed starts, it acquires the first IP address in the binding
order (which may be the onboard NIC card instead of the FoxNIC card). As the
FoxNIC card is not on the same subnet as the onboard NIC card, Exceed will
refuse all connections from the I/A Series or Foxboro Evo subnet.
To resolve this issue, you must modify Exceed’s host access settings. Proceed
as follows:
1. Open Exceed. Click the Start menu, and select: Programs >
Hummingbird Connectivity 2008 > Exceed Tools > Xconfig.
2. When asked to log in, the credentials are:
• Exceed configuration password: foxboro
• Xconfig password: foxboro
3. Select “Pick a category”.
4. Select “Security, Access Control and System Administration”.
5. In the “Host Access Control List”, change the radio button from “No Host
Access” to “Any Host Access”.
6. On the top of the screen, select the large green check mark to save your
changes.
7. From the File menu, select Exit.
8. Reboot the workstation or server.
On restart, Exceed will accept connections from the FoxNIC card’s subnet.

Adjusting the NIC Card Binding Order on

Workstations and Servers with ArchestrA
Applications
To adjust the binding order on workstations running ArchestrA Applications,
perform the following procedure. This procedure works on both workstations
and servers on which an ArchestrA application is installed.
1. Record the Foxboro Evo system connection information as follows:
a. Click Start > Settings > Network Connections
b. Note the Name and Device Name of the connection to be used by the
Control Software or ArchestrA application.
For example, on a T3400 workstation with the Control Software using the
on-board NIC, typically the Name is “Local Area Connection” and the
Device Name is “Broadcom NetXtreme 57xx Gigabit Controller”.
2. Reboot the workstation in Safe Mode as follows:
a. Restart the workstation from within the Control HMI by selecting:
File > Shutdown Workstation > Reboot Workstation
b. During reboot, when you see the message "Please select the
operating system to start", press F8.
If you do not see this message, restart the workstation again and tap
the F8 key repeatedly during the memory test until the Windows
Advanced Options Menu appears.
c. Use the arrow keys to highlight the Safe Mode with Networking
option, and then press Enter.
d. Click Yes or OK to enter safe mode.
3. Adjust the binding order. Perform the following:
a. Click Start > Settings > Network Connections.
b. On the Advanced menu, click Advanced Settings…
c. Record the order of the connections seen under Connections:.
d. Under Connections:, click the connection used by the Control
Software or ArchestrA applications, which was determined in step 1
above. Click the up arrow to move the selected connection to the top
of the list.
e. Click OK.
Restart the workstation. Click Start > Shutdown… Select Restart and click
OK.

Sample Configurations
These are example configurations that adhere to the guidelines described
above.
• Configuration A (page 33) shows a Foxboro Evo system using the Control
HMI.
• Configuration B (page 34) adds a Terminal Server with remote clients
using Control HMI.
• Configuration C (page 35) shows a Foxboro Evo system using the
FoxView HMI.
• Configuration D (page 36) shows a medium size Foxboro Evo system
having two plant units using a single Galaxy.
• Configuration E (page 37) shows a large Foxboro Evo system with a
separate off-control network1 ArchestrA network on which the Galaxy
server or Wonderware Historian can reside. Since the ArchestrA MX
network traffic is not on the control network, these machines are can be a
high-end multiprocessor server.
• Configuration F (page 38) shows a large Foxboro Evo system with
multiple plant units each having its own Galaxy. The ArchestrA MX
network traffic is not on the control network. The Galaxy server can be a
high-end multiprocessor server.
1. This is a platform that does not have the Foxboro Evo Control Software in-
stalled on it, on a network that connects to the control network.

Figure 2-21. Example Configuration A – Foxboro Evo System with

Control HMI Software

Figure 2-22. Example Configuration B – Foxboro Evo System with

Terminal Server

Figure 2-23. Example Configuration C – Foxboro Evo System with

FoxView/FoxDraw Software

Notes:
1 The control network typically includes multiple switches but is represented above
as one switch to reduce the complexity of the drawing.
Figure 2-24. Example Configuration D – Medium Foxboro Evo System

Having Two Plant Units with One Galaxy

Notes:
2 At least one dedicated workstation needs to be used as a Historian collector.
3 The Wonderware Historian can be installed on one of these servers.
4 The ArchestrA MX network traffic is not on the control network but on this separate network.
5 This can be a either a Galaxy Server or Wonderware Historian. Since no Foxboro Evo software is
installed on it, this machine can be a high-end multi-processor server.
Figure 2-25. Example Configuration E – Large Foxboro Evo System
with Separate Off-Control Network ArchestrA Network

Notes:
2 The ArchestrA MX network traffic is not on the control network but on this separate network.
3 There is no I/A Series/Foxboro Evo software installed on these Galaxy servers. These can be high-end
multi-processor servers.
4 There are no peer-to-peer connections between plant units unless manually configured.
5 There is one CSA for all units.
Figure 2-26. Example Configuration F – Large Foxboro Evo System

with Multiple Plant Units Having Separate Galaxies

Foxboro
Evo
Workstation MG3B FD3B AB3B
Galaxy Repository
Windows Server 2008 (Control Editors)
R2 Standard Foxboro Evo
Workstation
(AW70P)
Switch MODE Nodebus
MODE Parameter
Parameter LI
LI
FCP270 w/ ZCP270 Address Translation
200 Series Station (ATS)
FBMs
200 Series
FBMs
FCP280 100 Series

FBMs CP60
Allen-Bradley™ ®
Device Integrator Integrator 30 Style B

Operational Status
Fieldbus
Ethernet
Tx
Tx
Rx
Rx
30B (FD3B) (AB3B) FCM10E

Communication
10 Mbps Coaxial Ethernet to
Address Translation FCM10E

2 Mbps Fieldbus
FBI10E DCM10E
P0914YM
®
Station (ATS)
100 Series 100 Series 200 Series

FBMs FBMs FBMs
Nodebus
Modbus™ Integrator 30 CP40B/
Style B (MG3B) CP60
CP40B/ 100 Series

CP60 CP60 FBMs
Operational Status
Fieldbus Tx Rx
Ethernet Tx Rx
100 Series
FBMs
FCM10E
Communication
10 Mbps Coaxial Ethernet to
2 Mbps Fieldbus
FCM10E
P0914YM
FBI10E DCM10E
®
100 Series 100 Series 200 Series

FBMs FBMs FBMs
Figure 2-27. Example Configuration for The Foxboro Evo Control

Network and Nodebus, When Used With a Foxboro
Control Software v4.0 or Foxboro Evo Control Software
v5.0 or Later System, Which Supports Legacy I/A Series
Software/Stations

Configuration Notes
While the sample configurations above show Control Editors running on a
different workstation than the operator workstation running either Control
HMI or FoxView software, it is possible to run them on the same workstation.
If your configuration involves putting the Galaxy server on an off-control
network and you do not want the InTouch software installed on that server, you
must create a “custom configuration” when using the Control HMI Installation
DVD. There is not a pre-defined configuration for this type of installation.
The following list provides additional notes on configurations of the systems
with the Control Software.
• The recommended amount of RAM in the client workstations is at least
2 GB.
• The recommended amount of RAM in the servers is 4 GB.
• Off-control network workstations and off-control network servers can
have multiple processors and cores. Workstations and servers that have
I/A Series or Control Core Services software installed on them only use a
single processor (or a single core on a multi-core processor).
• The sample configurations include both AIM* and Wonderware
Historians.
AIM*Historian software can historize both process data and event (alarm)
messages, whereas the Wonderware Historian software historizes the
process data, but event messages are collected through the InTouch Alarm
DB Logger into a separate SQL Server database. You must set up this SQL
database and then manually configure the Alarm Logger to log messages
to it. This SQL database can be on the same station as the Wonderware
Historian database but the Wonderware Historian does not interact with
this SQL database.
One advantage of employing the Wonderware Historian software and
historizing alarm messages in SQL Server is that there are many analysis
tools that can be used with these databases.
In the current implementation, when you are using FoxView software
rather than Control HMI software, you need the AIM*Historian to display
historized alarms in the Alarm Manager’s Alarm History display.
• The System Manager can be used with either choice of HMI, that is,
FoxView or Control HMI software.
• Multiple Galaxies on the same server are not supported.
• Multiple Galaxy repository servers on the SAME network are not
recommended since this can lead to database corruption when there is
version mismatch between Galaxies. Each Galaxy database and each
Galaxy server has versions of files that are distributed to client stations
when objects are deployed. If a client workstation attempts to connect to
different Galaxies that are at different versions (such as can be the case
during an upgrade to a new release), corruption of the Galaxy database
occurs.
• You can have multiple servers if they are totally isolated from one another,
such as depicted in Configuration F. In this case, a given client

workstation can only access one Galaxy server, thereby mitigating the risk
of database corruption. By keeping Galaxies in different plant units
isolated from each other, an upgrade of one Galaxy can occur without
impacting the other Galaxies.
• There is always only one CSA server per the control network. Even if
there are multiple plant units each having a separate Galaxy, there is still
one instance of the control network with one CSA server. If there are peer-
to-peer connections between devices in separate Galaxies, during
configuration operations users will not be able to browse to other Galaxies
for peer-to-peer connection references. These references would have to be
typed manually in C:B.P form.
• For configurations that have multiple Galaxy servers (such as
Configuration F), special consideration must be given to the system
definition process. As described in the “Installation Overview” chapter in
the Foxboro Evo Control Software Installation Guide (B0750RA), it is
recommended that a stand-alone station that has the Control Software
installed on it be used to generate the system configuration for the entire
instance of the control network. This will ensure that all the station IP and
MAC addresses are unique since they will be generated for the whole
instance of the control network. This system definition will include one
and only one CSA server.
From that stand-alone station, two essential outputs must be created:
system Commit media (for installing the I/A Series or Control Core
Services software on the Control Core Services workstations) and an
export file of the hardware objects that will be imported into each of the
Galaxies on the actual system.
After the I/A Series or Control Core Services software is installed on the
workstations in the actual system using the system Commit media
generated above and the Control Software is installed, the procedure
varies from what is in the “Installation Overview” chapter (which was for
a single Galaxy configuration). The next step is to take the exported file
from the stand-alone Galaxy and import it into the other Galaxies. After
importing the hardware objects into each Galaxy, it will be necessary to
delete all the controllers (and contained FCMs, FBMs, and devices) that
are not part of that specific Galaxy (plant unit). It is recommended to have
other types of stations appear in more than one plant unit, but not CPs and
their associated devices. This will ensure that global logical names for
printers, alarm destinations, and so forth are maintained properly.
The control configuration in each Galaxy will be limited to only those
blocks which run on that Galaxy’s controllers and associated devices.
If there is a change in the system configuration at a later date then the
change must be done in the master configuration that contains all stations,
i.e., the one initially created on the stand-alone station. Then, a new
Commit must be generated to do a Day 1 installation on the I/A Series or
Control Core Services stations to update them.
Changes made to existing CPs must also be made manually on the
associated Galaxy since the import operation will not overwrite existing
CPs.
• If employing Terminal Services or Remote Desktop Services for remote
access, it is not recommended to install Terminal Services or Remote

Desktop Services on the same server as the Galaxy server. Each remote
session adds processing and memory load to the server which could result
in unsatisfactory performance of the Galaxy server. To add Terminal
Services or Remote Desktop Services to configurations that have multiple
Galaxies (such as Configuration F), there should be a separate server with
Terminal Services (Windows Server 2003) or Remote Desktop Services
(Windows Server 2008 R2 Standard) on each Galaxy network for which
remote access is required. These servers with Terminal Services or
Remote Desktop Services could then be attached to another network
where the remote workstations are attached.
Foxboro Evo Control Software Network

Troubleshooting Checklist
1. If an off-control network is being used for the ArchestrA network traffic,
make sure the network address field in the General tab of each Platform
Object is set to the correct IP address on the off-control network (rather
than the computer name). During the Control Software installation, the
computer name is automatically configured in this field and this can
resolve to the wrong address, that is, the IP address on the control network
instead of the off-control network address.
This also applies to historizing Platform Object attributes when an off-
control network is involved. If you check the Enable storage to Historian
option on the Engine tab of the Platform Object, be sure to put the IP
address of the Wonderware Historian Server on the off-control network
instead of its computer name.
2. Make sure the LMHOSTS files are correct on all the workstations and
servers. This file is installed by the I/A Series or Control Core Services
software installation and is located in C:\Windows\System32\drivers\etc.
If off-control networks are involved and you want the workstations and
servers on the off-control network accessible by their computer names,
you can put those station names and IP address in the LMHOSTS file. For
example, if your Galaxy server and Wonderware Historian server are on
the off-control network, you would put the computer names and off-
control network IP addresses of those stations in the LMHOSTS file.

3. For the off-control network, make sure the switches are configured for
100 Mb, full duplex (no autonegotiation), spanning tree enabled, and flow
control is disabled. As an example, when configuring Enterasys A-Series
switches using the command line interface port, the following commands
are suggested:
set switch stack-port ethernet
(Note: This will reboot the switch.)
set flowcontrol disable
set spantree version rstp
set ip address x.x.x.x mask y.y.y.y
set port duplex fe.1.* full
set port speed fe.1.* 100
set port negotiation fe.1.* disable
show config outfile configs/OffMesh.cfg
4. For the off-control network, make sure the Network Interface Cards
(NICs) are configured to match the switch port to which they are
connected. For example, 100 Mb, full duplex (no autonegotiation),
disabled flow control.
5. If you are running out of network bandwidth, try putting the Galaxy server
on a 1 Gb switch port. This could greatly enhance performance if you have
many workstations accessing the Galaxy at the same time. (If you do this,
remember to configure the Galaxy server NIC that is connected to the
1 Gb port to 1000 Mb.)
6. Make sure the Wonderware Historian redundant path is on its own private
network.
7. For Enterasys A-Series switches, make sure ports 25 and 26 are
configured as uplinks, not stacking. Note that performing a set factory
default from the switch configurator tool will not perform this task. Refer
to The MESH Control Network Operation, and Switch Installation and
Configuration Guide (B0700CA) for information on configuring A-Series
switches.


45
C H A P T E R 3
Historizing Data
This chapter describes historical data collection in a Foxboro Evo system with
the Control Software.
Contents
• Overview of Historical Data Collection
• Configuring a Historical Data Collector
• Configuring the Wonderware Historian to Collect from I/A Series Data
Access Server
• Additional Information
Overview of Historical Data Collection

There are two ways to collect historical data in a Control Software system. The
first method is preferred for the reasons explained below; however, you can use
either or both methods. There is usually no need to collect the same parameter
using both methods, but it is sometimes necessary to collect some parameters
using the second method, particularly if the parameter’s timestamp is not
synchronized with the Wonderware Historian.
The first way is to configure a Historical Data Collector workstation to send
historical data to the Wonderware Historian. This is done from within the
Control Editors, using the editors for each compound or block containing the
parameters you wish to historize. This method takes advantage of the store and
forward capability of the collecting workstation and can be configured to use
redundant collecting workstations.
The second way is to configure the Wonderware Historian to collect data
directly from a Data Access Server. With this method, the Wonderware
Historian can either be configured to use redundancy (by specifying a Failover
Node) or can operate in Store Forward Mode, but not both.

46 3. Historizing Data
Configuring a Historical Data Collector

To start collecting historical data, do the following:
1. Identify all the workstations you wish to use for collecting historical data.
Note that each collecting workstation can collect at most 30,000 tags. If
more tags are needed, a proportional number of collecting workstations
will be required.
2. Specify which collecting workstation will collect the parameters
associated with each compound. In the Control Editors, edit each
compound that contains parameters (and/or blocks with parameters) that
you wish to have historized. Assign the letterbug of one collecting
workstation to each compound. If you have configured redundant
collecting workstations, select the letterbug of the primary workstation of
the redundant pair.
3. Specify each parameter to be historized. In the Control Editors, edit each
compound or block and check the History Enabled checkbox for each
parameter you wish to historize.
4. Deploy each compound/block.
When the compound/block(s) are deployed, the collecting workstations start
collecting data from the control processors stations and forward it to the
Wonderware Historian for storage. This activity continues until the
compound/blocks are undeployed.
Configuring the Wonderware Historian to

Collect from I/A Series Data Access Server
For devices that are not time synchronized with the Wonderware Historian or
do not provide timestamps in their messages, their data must be collected using
the IDAS (instead of the I/A Series History Provider) and configured so that
IDAS provides the timestamp. IDAS is an IndustrialSQL Server Data
Acquisition Service that accepts data values coming from one or more I/O
Servers and forwards it to Wonderware Historian. See the IndustrialSQL
Server Historian Administration Guide for information on how to configure
IDAS. Use the following settings for Wonderware Historian IDAS
configuration: Set Application to “IADAS.exe” and Topic to “IASeries”.
Redundant Historian
When using the History Collector method of history collection, the Historian
can be configured as part of a Redundant Historian pair. This configuration is
done through the SMC, and is a property of the Historian.
For more information on the use of redundant Historians, refer to Historian
Administration Guide.

3. Historizing Data 47
Additional Information
The I/A Series History Provider has additional configuration options for
collecting and storing historical data. The Block Configurator User’s Guide
(B0750AH) describes how to specify a parameter to be historized and their
related options. The Access Manager User’s Guide (B0750AD) includes
guidelines and instructions on configuring redundant collectors,
starting/stopping Wonderware Historian and troubleshooting the collecting
workstations.

48 3. Historizing Data

49
C H A P T E R 4
Security
Security in a Control Software system encompasses several components:

• Security within ArchestrA
• Control HMI Security
• I/A Series Security Provider.
Although each of these has been developed at different times and natively have
different security models, the Control Software integrates them under a
common approach to security.
This chapter is structured to provide higher-level overview information in the
first few sections with more detailed information provided in the latter
sections. More detailed information about ArchestrA security can be found in
the Wonderware documents FactorySuite A2 Deployment Guide and Industrial
Application Server User’s Guide.
Contents
• ArchestrA Security
• I/A Series Security Provider
• Foxboro Evo Security Considerations
• Details of the ArchestrA Security Model
• Sample Procedure for Setting up Security in Foxboro Evo Control
Software
• OS Based Security Configuration for Field Device Manager
• Unity Pro Object Template Security
ArchestrA Security
ArchestrA security includes controlling access to applications and to objects.
The applications include the IDE, used for configuring and managing objects
in the Galaxy, and the SMC, which is used for performing maintenance and
system administration.

50 4. Security
ArchestrA security controls access to the objects that are configured through
the ArchestrA IDE, such as control compounds and other ArchestrA objects
stored in the Galaxy. Every object in the Galaxy belongs to a “security group.”
Access is controlled through the concept of “roles” which have security groups
assigned to them.
The following authentication modes are available in the IDE:
• None (ArchestrA security is turned off)
• Galaxy
• OS User based
• OS Group based
FCS v4.0 and the Control Software v5.0 or later support all security
authentication modes whereas versions prior to FCS v4.0 only support the
Galaxy Authentication.
Security groups and roles are also created and configured using the IDE.
ArchestrA objects are assigned to user-configured security groups. Security
groups are then assigned to one or more roles. Each user is assigned one or
more roles. All users with a given role have access to the objects within the
security groups assigned to that role.
These security settings are in effect regardless of the ArchestrA application
interface. They are in effect when modifying run-time parameters through the
Live Data display, when making changes to control data within Control HMI,
or when using the Object Viewer to modify ArchestrA object data.
This security does not apply when accessing non-Galaxy objects. For example,
it does not include defining access to menu items within Control HMI software
or access to fields in the Control HMI Alarm Panel. However, Control HMI
software provides a security model that ties such access to ArchestrA role-
based security.
Control HMI Security

InTouch software security is normally based on using “access levels” to
determine the functionality available to users. Although users are free to
configure access level security within any user-built windows, access levels
are not used in the Control HMI software security model. Instead, Control
HMI software carries over the ArchestrA concept of “roles” and ties access to
its features based on the Galaxy-defined roles.
All menu selections and certain features within Control HMI software can be
enabled or disabled based on the role of the logged-on user. This controls
access to functionality such as the ability to launch another program or provide
standard actions such as minimizing and shutting down Control HMI software.
This security is configured in the Framer configuration software.
ArchestrA user accounts and passwords are shared with Control HMI software.
It is even possible to change these passwords in Control HMI software without
being an Administrator in the Galaxy.
The user roles are initially defined and configured in the IDE. Then, using the
Framer configuration software, permissions are configured to determine which

4. Security 51
menu picks are available for each role. At run time, Control HMI software
determines the role of a user based on their ArchestrA profile and then
determines if the menu pick has been configured to be enabled or disabled for
that role.
The Framer configuration software is invoked from the WindowMaker™
application software by selecting InFusion View Framer > Open from either
the Application Explorer or from the Special menu on the top menu bar. The
first time it starts up, the Framer configuration software comes up with
Security disabled.
Starting Control HMI Without a Windows Taskbar

In I/A Series software v8.7, the Control HMI security has the ability to launch
the Control HMI software without the Taskbar and/or disable Ctrl-Alt-Del.
There are two batch files available within the Tools directory to configure this
feature, InFusionViewStartupService.bat and
UndoInFusionViewStartupService.bat.
The following is a procedure to start up the Control HMI software without a
Windows taskbar.
Notes:
• If you are going to disable the taskbar and optionally Ctrl-Alt-Del, the
operator should not have access to Control HMI software’s Tools >
Windows Explorer menu selection. You can disable this through the
Framer software for the Roles that should not have desktop access. If
desktop access is needed for other Roles, access to Windows Explorer
should be allowed. Refer to Framer and Alarm Management User’s Guide
(B0750AR) for instructions.
• Access to the Control HMI software’s File > Exit InFusion View menu
selection should also be disabled if there is no taskbar, since the Control
HMI software will not be restarted on Exit. If the Control HMI software
exits while the workstation does not have a Taskbar enabled, the
workstation must be rebooted to recover.
To configure a workstation with Control HMI to start without a Taskbar:
1. From the C:\Program Files\Invensys\InFusion\View\Tools directory,
double-click the file InFusionViewStartupService.bat to run the setup
script. This script will move the startup of the Control HMI software from
the Windows Startup menu to a startup sequence through a Foxboro Evo
service. The Control HMI software must be started through this service
when the Control Core Services workstation is configured to run without a
taskbar.
2. Disable the taskbar from the Foxboro I/A Control Panel applet.
a. From the Windows desktop, double-click My Computer and double-
click Control Panel.
Or
b. From the taskbar, click Start > Settings > Control Panel.
c. Double-click Foxboro I/A. Choose either:

52 4. Security
Autologon (no taskbar)

Or
Autologon (no taskbar, Ctrl-Alt-Del disabled)
d. Reboot the workstation by selecting File > Shutdown Workstation >

Reboot Workstation from the Control HMI software top menu bar,
or by selecting Ctrl-Alt-Del on the keyboard.
After reboot, Exceed® software and Control HMI software are the only
applications available to the workstation operator. There is no desktop and no
taskbar. Access to other applications is only through Control HMI software.
To return the workstation to the default startup mode:
1. Reactivate the Windows taskbar and desktop:
a. From the Control HMI software top menu bar, select Tools >
Windows Explorer.
b. In the left pane of the Explorer window, double-click the Control
Panel icon under My Computer.
c. In the right pane of the window, double-click the Foxboro I/A icon.
The Foxboro I/A display appears.
d. Make sure that Autologon or Manual Logon in either the I/A Series
On or I/A Series Off group box, is checked. Otherwise, you do not
have access to tasks, programs, or files.
e. Click OK.
f. From Control HMI software, click File > Shutdown Workstation >
Reboot Workstation.
To return Control HMI software to start under the Programs > Startup:
1. From the Control HMI software top menu bar, select Tools > Windows
Explorer.
2. Double-click UndoInFusionViewStartupService.bat located in the
directory C:\Program Files\Invensys\InFusion\View\Tools.
3. Reboot the workstation from the Control HMI menu pick.

4. Security 53
Terminal Server:
Follow the same procedure for the console session of a terminal server. How to
enable/disable the taskbar for Windows Terminal Server clients can be found
in Chapter 6, “Terminal Services and Remote Desktop Services”.
I/A Series Security Provider

The I/A Series Security Provider bridges ArchestrA and Foxboro Evo
compound/block security by providing Foxboro Evo tag Security
Classification and Security Group information to the ArchestrA security
subsystem at run time. The ArchestrA security subsystem determines if a write
request should be processed based on this information.
Each tag has one of the following ArchestrA Security Classifications:
FreeAccess, Operate, SecuredWrite, VerifiedWrite, Tune, Configure, or
ReadOnly and is associated with one Security Group (Security Groups may be
user defined in the IDE).
To use the I/A Series Security Provider, ArchestrA security must be enabled in
the Galaxy.
The I/A Series Security Provider is a Windows service running on every
Foxboro Evo workstation.
Note that while on scan, the Configure Security Classification functions like
the ReadOnly Security Classification. This means that any tag with the
Configure classification is always read-only when accessed through the
I/A Series Device Integration Object.
The ArchestrA Security Classification for all Foxboro Evo blocks, ECB, and
compound attributes is set to Operate by default. Each workstation receives
attribute Security Classification settings using an exception based model. Only
attributes with settings different from the default are sent to the workstation, at
a maximum rate of 1000 attributes per second. The default Security
Classification can be redefined for every attribute type.
Attribute Security Classifications are reported using the default classification,
unless a non-default classification is received in the update. The total length of
the update time is proportional to the number of non-default attributes
configured.
The time for any individual attribute to receive a non-default security
classification depends on the number of attributes, their order in the
configuration, network load, server load and workstation load. This time may
be as short as one second or as long as several minutes. This time presents a
period of default security when the ArchestrA Security Classification may not
be what the system engineer intended.This period occurs on a system-wide
basis when the Refresh History and Security Database menu selection is
made in the IDE.
Refer to the “Controlling Access to Parameter Values” chapter of the Block
Configurator User’s Guide (B0750AH) document for more information related
to configuring security for Foxboro Evo control blocks.

54 4. Security
Using Write Access Security

To make use of tag-based write access security, Foxboro Evo tags must be
accessed through the I/A Series Device Integration Object. This means that the
tag name must include the name of the I/A Series Device Integration Object in
its full name, such as:
<DeviceIntegrationObject>.<Item>
or any of the other legal variations, including Galaxy, scan group, and/or
extensions.
When a write occurs to a tag configured in this way, a security information
request is sent to the I/A Series Device Integration Object from the ArchestrA
security subsystem. The ArchestrA security subsystem compares the user
credentials against the tag’s security classification and group. If the user has
the proper security credentials for the tag, the write request is sent to the
I/A Series Device Integration Object, otherwise it is rejected at the requesting
application. Useful information on the progress of the write request is logged
to the SMC Log Viewer.
Foxboro Evo shared variables always have the FreeAccess Security
Classification and are members of the Default Security Group. Parameters
accessed from legacy Foxboro Evo systems (but not configured with the IDE)
have the Operate Security Classification and are members of the Default
Security Group.
Foxboro Evo Security Considerations

Granting the “acknowledge alarms” permission to a Galaxy “role” does not
apply to acknowledging Foxboro Evo alarms. This security setting applies only
to acknowledging ArchestrA application object alarms. Use the “.UNACK”
Foxboro Evo parameter to control access to Foxboro Evo alarm
acknowledgement for specific blocks through the Control HMI faceplates. Use
the “AllowAck” property within Control HMI Permissions to control alarm
acknowledgement for all alarm acknowledgement through the Alarm Panel.
Security configurations for control compounds need to be deployed. Even if
there is nothing to deploy to the control station, all changes to the compound,
including modifications to security information, need to be deployed in order
for the changes to be distributed to each workstation.
Details of the ArchestrA Security Model

The following sections provide detailed information about the ArchestrA
security model. Additional information can be found in the “Security” sections
in the Wonderware documents Industrial Application Server User's Guide and
FactorySuite A2 Deployment Guide.
Security Groups
Every object in the Galaxy belongs to only one security group. You can create
and manage security groups that make sense for your organization. These

4. Security 55
security groups are mapped to roles on the Roles page. Each security group can
be mapped to multiple roles.
Permissions determine what kind of access users have for each attribute or
parameter. There are four basic operational permissions:
• Acknowledge alarms
• Change the value of attributes with security mode Configure
• Change the value of attributes with security mode Operate; this also
includes security modes Secured Write and Verified Write
• Change the value of attributes with security mode Tune
By default, all currently used objects are assigned to a security group called
Default.
By default, a user who been assigned the “Default” security role has
permission to:
• Acknowledge alarms
• Change attribute values with “configure” security mode
• Change attribute values with “operate” security mode, including “secured
write” and “verified write”
• Change attribute values with “tune” security mode.
For example, you want users in certain roles to only have permission to modify
“Operate” parameters. Users cannot modify parameters that have been
categorized as “Tune” or “Configure” parameters. These users can only modify
“Operate” parameters from compounds that have been assigned to Area1. They
can modify parameters from Area2.
1. Create two Security Groups, for example, SecGrpArea1 and
SecGrpArea2.
2. Assign all compounds that are contained in Area1 to the SecGrpArea1.
Assign all compounds contained in Area2 to the SecGrpArea2 Security
Group.
3. On the Roles page, create a role, for example, OperateArea1. In the
Operational Permissions for the security group SecGrpAreas1, select the
Can modify Operate attributes checkbox. Do not check any Operational
Permissions for the SecGrpArea2 security group.
Any user that belongs to the OperateArea1 role can modify “Operate”
parameters at runtime. Users in this role cannot modify parameters that have
been configured as “Configure” or “Tune”, nor can they modify any
parameters in compounds that have been assigned to the SecGrpArea2 security
group. Following is an example of this configuration.

56 4. Security
Figure 4-1. Example Operational Permissions Configured
Users
All users that access ArchestrA data must first be configured within the Galaxy
Repository.
Two users are defined by default when a new Galaxy is created: Administrator
and DefaultUser. These cannot be deleted in an open security setting and they
are both associated with the default roles, Administrator and Default.

4. Security 57
Roles
You can create and manage user roles that apply to your organization’s
processes and work-based authorities. Two roles are defined by default:
Administrator and Default.
Note Several of the roles that appear in Figure 4-1 are for FDM only.
You can specify General and Operational Permissions for each role.
General permissions relate to application configuration and administration
tasks.
Operational permissions relate to the security groups listed on the Security
Groups page. By default, the Administrator has all permissions.
Note You cannot modify the General permissions for the role of
Administrator.
The Operational Permissions that can be associated with a role:

• Can Modify “Operate” Attributes: Allows users with operational
permissions to do certain normal day-to-day tasks like changing setpoint,
output, and control mode for a PID object, or commanding a Discrete
Device object.
• Can Modify “Tune” Attributes: Allows users to tune the attribute in the
runtime environment. Examples of tuning are attributes that adjust alarm
setpoints and PID sensitivity.
• Can Modify “Configure” Attributes: Allows users to configure the
attribute’s value. Requires that the user first put the object Offscan.
Writing to these attributes is considered a significant configuration
change, for example, a PLC register that defines a Discrete Device input.
• Can Acknowledge Alarms: Allows users to manually acknowledge an
alarm in the run-time environment. This permission does not apply to
acknowledging control blocks.
Assigning Users to Roles

After you create users and roles, you can assign users to roles. On the Users
page, all users in the Galaxy and the roles they are assigned are listed.
By default, the new user is associated with the Default role but not the
Administrator role. This cannot be changed as every user belongs to the
Default role. Double-click in a text box to change its contents, if needed.
Note All users are automatically assigned to the Default role in addition to
any new roles you create and assign to them. The best way to manage
permissions is to limit the permissions of the Default role to those permissions
you want everyone to have. Then, add users to other roles with permissions for
other parts of Industrial Application Server.

58 4. Security
The Administrator user can log on any authentication mode except when
security is disabled. When logged on as Administrator on the Galaxy
Repository node, you can change the password of any Galaxy user without
providing the old password.
You can assign users to more than one role.
To assign a role to a user:
1. On the Galaxy menu, click Configure, and then click Security. The
Configure Security dialog box appears. Click the Users tab.
2. Select the user in the Authorized Users available area. Select a role in the
Associated Roles for <user name> area.
3. Provide each user with a password by clicking Change Password. The
Change Password dialog box appears.
Caution If an OS-based security mode is selected on the Authentication

Mode page, changing a user’s password changes the OS password for the user.
Enter the correct information. This information is used in the

configuration, administration and run-time environment to authenticate
users.
4. Click OK.
Sample Procedure for Setting up Security in

Foxboro Evo Control Software1
This procedure is intended to provide a typical sequence of steps that can be
used as a guideline for setting up security using the Galaxy authentication
mode. Once Security has been turned on, all users are required to log in when
connecting to the Galaxy.
1. Make sure there are no IDE objects checked out and there are no open
instances of the IDE accessing the Galaxy.
2. On the Galaxy Repository server, open the IDE and connect to the Galaxy.
1. For more information on groups and roles, see the section titled “Working with Security” in
the Wonderware® Industrial Application Server User’s Guide.

4. Security 59
3. Enable security by selecting Galaxy > Configure > Security.
Figure 4-2. Accessing Security Options

60 4. Security
4. Select the Galaxy authentication mode.
Figure 4-3. Configure Security - Authentication Mode Tab

4. Security 61
5. Select the Security Groups tab and create the security groups by clicking
the “+” button. The “X” button is used to delete a group. You cannot delete
the Default group.
Figure 4-4. Configure Security - Security Groups Tab
6. Assign objects to a security group by dragging and dropping.

62 4. Security
7. Select the Roles tab and create roles using the “+” button (e.g., manager,
operator, OperateArea1, tuner, configurator) and assign permissions to
each role. Permissions are actions like being able to start the IDE, deploy,
acknowledge alarms, and modify certain attributes (such as configure,
operate, tune).
Figure 4-5. Configure Security - Roles Tab

4. Security 63
8. Select the Users tab and create users, providing user names and
passwords.
Figure 4-6. Configure Security - Users Tab
Note Passwords for users can be blank. However, with a blank password,
the password cannot be changed with the InTouch software’s “change
password” interface. You need to enter the current password before
entering a new one and the dialog box does not accept blanks for the
current password.
9. Assign roles to users by checking the appropriate Roles from the list.
10. Close the IDE.
11. Invoke the WindowMaker application. From either the Application
Explorer or from the Special top menu bar menu, select Framer > Open
to invoke the Framer. Refer to Framer and Alarm Management User’s
Guide (B0750AR) for more information.

64 4. Security
12. Add the ArchestrA roles configured in the IDE to the Permissions by
right-clicking on Permissions and selecting New. Then, for each role,
check the appropriate property boxes in the right pane. By default, the
Default role is given permission to access all functions, except some
administrative privileges on remote terminal server clients. As with
configuring security in the Control Editors, the Default role should be
modified to define permissions that everyone should have. Then,
configure additional Roles with increased permissions as needed.
Figure 4-7. Framer Properties - Permissions

4. Security 65
13. Under Properties in the left pane, select Configuration. Check the box in
the Default column next to the ArchestraSecurity property.
Figure 4-8. Framer Properties - Configuration
14. Save the changes and exit Framer.

15. In the WindowMaker application, select Special > Notify Clients to
notify NAD client workstations that changes are ready to be propagated to
client workstations. (Note that this also propagates any other changes that
have been made to Control HMI software.)
16. Restart the Control HMI software.
Once ArchestrA security is enabled in the Galaxy, users have to log in to the
IDE, the Platform Manager portion of the SMC and to the Control HMI.
Control HMI can be started without logging in but functionality is restricted.

66 4. Security
Changing the ArchestrA Network Account

Password
Utilizing passwords to protect the system from unauthorized access is essential
to the ArchestrA security model. A password for your ArchestrA system is
required during the initial installation. If at any time after installation you
require the system password be changed, you must use a utility on each station
and enter identical information. This utility can be invoked through the Start
menu: Start > Programs > Wonderware > Common > Change Network
Account.
Warning The same account, user name and password must be used on each
computer that requires communication with others in the ArchestrA
environment. Failure to follow this requirement will result in system
communication failures.
OS Based Security Configuration for Field

Device Manager
This section describes the configuration of OS Based security for Field Device
Manager (FDM).
OS User Based Security

In OS User Based security, after logging in as one of the system users, the user
should make a selection of the FDT roles. The user should select
fdtadministrator and fdtplanningEngineer from the Users tab to allow full
access to FDM configuration.
If the user does not make a selection of FDT roles, the FDT role is defaulted to
Observer with minimum privileges.
OS Group Based Security

OS Group Based security should be configured as described in the following
procedure for complete access of FDM functionality.
The following FDT groups are available on PDC in a secure setup:
Table 4-1. FDT Groups that are Available on PDC in a Secure Setup
FDT Groups
fdtadministrator
fdtplanningEngineer
fdtmaintenance
fdtoperator
fdtobserver

4. Security 67
Perform the following steps to configure OS Group Based security on PDC:

1. Create user accounts.
For example, FDTEng1 user is created on the PDC as shown in Figure 4-9.
Figure 4-9. FDTEng1 User Created on PDC
2. Add User as a member of FCSEngineering, fdtadministrator, or other

FDT groups.
Note 1. For complete access of FDM functionality, user should be a member

of fdtadministrator and fdtplanningEngineer.
2. All users working with the Control Software should be a member of
FCSEngineering group.
3. A user can be a member of more than two FDT groups.

68 4. Security
For example, FDTEng1 is added as a member of FCSEngineering,

fdtadministrator, fdtplanningEngineer, and fdtoperator as shown in
Figure 4-10.
Figure 4-10. Add User as a Member of FDT Groups
After the Users are configured, security is configured in the Control Software.
3. Select OS Group Based security option in the Authentication Mode tab
of Configure Security dialog box in the Control Software.
4. Add FDT groups in the Roles Tab of Configure Security dialog box.
The FDT groups are added by selecting the + button and domain\group
from a drop down list.

4. Security 69
For example, IASERIES\fdtadministrator,

IASERIES\fdtplanningEngineer, and IASERIES\fdtoperator are added by
the user as shown in Figure 4-11.
Figure 4-11. Add FDT Groups in the Roles Tab
Note The user should manually add all the required groups. For example, user
should add both fdtadministrator and fdtplanningEngineer groups to
provide FDT Administrative privileges and Planning Engineer FDT role. It is
not enough to add only one of the roles.
5. User should login with a user account which is a member of the FDT
groups.

70 4. Security
The Users tab provides information about the Roles associated with the
domain\user as shown in Figure 4-12.
Figure 4-12. Associated User Roles in Users Tab
In the above example, the user login as FDTEng1. After logging in,
IASERIES\fdtadministrator, IASERIES\fdtplanningEngineer, and
IASERIES\fdtoperator are automatically selected as associated Roles in the
Users tab. This is mapped to FDT Planning Engineer role which gives full
privileges for working with Field Device Manager.
Note If the user login account belongs to a group that is not a FDT group, the
FDT role is defaulted to Observer with minimal privileges.

4. Security 71
Unity Pro Object Template Security

The Unity Pro object instance configuration uses the data from the PLC XVM
(application symbols) file. From this configuration data, Devices, Compounds,
Blocks and Strategy Objects for the PLC are created. It is therefore essential
that the validity and integrity of the XVM file is assured.
Note The Unity Pro Object is able to support the import of up to 10,000 tags
per XVM file. Any additional tags will be ignored. For more information on
the Unity Pro object template, refer to Unity Pro Object Template User’s Guide
(B0750DB).
The installation and configuration will default to the most secure

configuration. However this default configuration may not be applicable to
you, so the configuration alternatives are shown in this section. Each of these
clearly identifies their security risks and how these risks can be mitigated.
Note You need to manage Windows® user names and passwords per your
organization's defined policies, irrespective of the configuration you choose to
implement.
When you install the Foxboro Control Software v6.1, the UPO template is
installed along with File Watcher Service (FWS), which is installed to run as a
Windows service. However, it is not configured to run by default.
If you need to monitor changes made to the XVM files, you have to configure
the File Watcher Service using the Control Software Configurator application
first. For more information on how to configure the File Watcher as a Windows
service, refer to Control Software v6.1 Release Notes (B0750SJ). Once
configured, you can monitor the imported XVM files round the clock for
changes made to them.
You must provide the FWS special access privileges for monitoring the XVM
files. For more information on how to create an ACL to define credentials for
users and provide access privileges, refer to Modicon Controllers Platform
Cyber Security Reference Manual.
Note The FWS requires its own ArchestrA license wherever it is run. As an
alternative the IDE File Watcher does not require an additional license but has
less availability.
The FWS monitors changes to the referenced XVM files from the UPO in the
Galaxy, and updates the status of the UPO while ArchestrA is not running. A
modified warning is displayed when the FWS detects a change in the imported
XVM files that will disrupt the Modbus-DCS block configuration.
You will also be able to view log entries for changes made to the XVM file in
the ArchestrA System Management Console (SMC) log. The Import XVM
File button is enabled at this point. Once you reimport the updated XVM file,
the warning is resolved. You can then regenerate the configuration and deploy
it.
There are four configuration options:
• Secure Installation by Default
• One Internal User with File Watcher Service

72 4. Security
• Separate Users for PLC and CS in a Single System with File Watcher
Service
• Separate Users for PLC and CS in Separate Systems with File Watcher
Service
Secure Installation by Default

• There is only one internal user, the CS engineer, with authenticated and
secure access to the ArchestrA IDE.
• No additional file watcher is configured.
Figure 4-13. Secure Installation by Default
One Internal User with File Watcher Service

• There is only one internal user, the CS engineer, with authenticated and
secure access to the ArchestrA IDE.
• Once the XVM file is imported, a reference to it is maintained by the
FWS.
• FWS monitors the imported files to track changes being made to the
project.

4. Security 73
Figure 4-14. One User with File Watcher Service
These are some additional security guidelines for the system hosting the
ArchestrA IDE:
• You should periodically review the ArchestrA SMC log for unauthorized
usage.
• You should ensure that the FWS username and password should be of
adequate strength and must be updated using the FWS configurator before
it expires.
Separate Users for PLC and CS in a Single

System with File Watcher Service
• An internal user, the CS engineer, has authenticated access to the
ArchestrA IDE.
FWS.
project.
• An internal user, the PLC engineer, can update the XVM files.

74 4. Security
Figure 4-15. Separate Users for PLC and CS in a Single System with
File Watcher Service
These are some additional security guidelines for the system hosting the
ArchestrA IDE:
• You should periodically review the SMC log for unexpected changes to
the XVM files.
• You need to regularly back up the ArchestrA Galaxy at a frequency
defined by your organization.
• You should ensure that the FWS username and password should be of
it expires.
Separate Users for PLC and CS in Separate

Systems with File Watcher Service
• An internal user, the CS engineer, has authenticated access to the
ArchestrA IDE.
FWS.
project.
• An external user, the PLC engineer has access through file share and can
update the XVM files.

4. Security 75
Figure 4-16. Separate Users for PLC and CS in Separate Systems with
File Watcher Service
The following are some additional security guidelines for the system hosting
the ArchestrA IDE:
• You must ensure that the PLC engineer (external user) must be given least
privilege, with access to only that share within the domain of the CS
system. For more information, see “File Share Configuration for PLC
Configuration Files” on page 76.
• You must ensure that the PLC engineer (external user) must be
authenticated with secure credentials and access permissions. This
prevents impersonation of the PLC engineer and any subsequent
tampering with the Control system through an import of malicious XVM
files. For more information, see “File Share Configuration for PLC
Configuration Files” on page 76.
• You need to regularly back up the ArchestrA Galaxy at a frequency
defined by your organization.
• You must ensure that the FWS username and password should be of
it expires. This mitigates the risk of elevation of privilege provided for the
external user.
• The Control System administrator must regularly review the SMC log for
unauthorized usage. This includes verification of the modified XVM files
or if the UPO has been imported or exported. This prevents the risk of
repudiation of changes made to the Control System through XVM files.
Note The frequency of checking the SMC system logs is directly proportional
to the number of users and criticality of the process involved.
Upholding these security considerations will prevent information disclosure of

IP or resources contained within the Control system.
!
Warning Failure to adhere to these guidelines puts the configuration of the
CS system at considerable risk of being tampered with.

76 4. Security
For more information about the Unity Pro Object Template, refer to Unity Pro
Object Template User's Guide (B0750DB).
File Share Configuration for PLC Configuration

Files
This procedure describes two users - a PLC Engineer and a CS Engineer. These
names are used throughout the documentation to indicate the access privileges
each enjoy. These names can be replaced by any other applicable username or
group that is defined in your system.
• PLC Engineer – A user who is responsible for managing the Modicon
PLCs and creates the XVM and STU files.
• CS Engineer – A user who manages the Unity Pro templates in the
ArchestrA IDE.
Windows 2008
Sharing the Folder
You can share a folder on a Windows Server 2008 R2 computer, administrators
must follow the steps given as below:
1. Log on to the Windows Server 2008 R2 computer using an administrator
account.
2. Right-click the folder you want to share and click Properties.
3. In the Properties dialog box click Advanced Sharing under the Share tab.
4. In the Advanced Sharing dialog box, select the Share this folder check
box. In the Settings area, type a custom share name in the Share name
box, and click Permissions to change the default permissions for users.
5. In the Permissions dialog box, click Remove to remove any default users
or groups (Everyone). Click Add to add the PLC Engineer and the CS
Engineer as users.

4. Security 77
6. Once the users have been added, select the relevant user and provide
read/write privileges by selecting the Change or Read check boxes listed
in the Permissions for <user name> area.
T
h
e
P
L
C
e
E
Note The PLC engineer must not be given any other permissions or privileges
within the system except for write access to that secure folder. The CS engineer
will be provided with read access only. For more information, see “Unity Pro
Object Template Security” on page 71.
7. Click OK to save the settings.
Mapping Network Drive (Windows 2008 R2)

To map a shared folder as a network drive from any remote computer, follow
the steps listed below:
1. Log on to the Microsoft Windows server 2008 R2 operating system.
2. Use the UNC path to select the file server. Right-click the shared folder
you want to map and select Map Network Drive.
3. In the Map Network Drive dialog box, select the drive from the Drive list
and select the folder you want to connect to.

78 4. Security
4. Select the Reconnect at logon check box and click Finish.
Windows 7
Sharing the Folder
Follow the steps listed below to create a shared folder in Windows 7:
1. From the taksbar, click Start > Run > type shrpubw.exe > click OK to
start the Create A Shared Folder Wizard. by Run dialog box and then
typing in the resulting window. You can also type shrpubw in the Search
box and press Enter to invoke the wizard.
2. Click Next on the Welcome screen and the Create a Shared Folder
Wizard dialog box appears. do not change the default Computer name as
it might cause a conflict with the names defined by your system. Select the
folder you want to share, verify the folder path and click Next.
3. Provide a share name in the Share name box and a description (optional).
You can also change which files and programs will be accessible offline.

4. Security 79
• Click Change beside the Offline setting field. The Offline Settings
window appears.
• Select the relevant option and click OK.

4. Once you have saved the Offline settings for the shared folder, click Next.
The Shared Folder Permissions window appears.

80 4. Security
5. You will have to set different user permissions for different sets of users
(the PLC engineer has write access to the share while the CS engineer only
has read access). Select the Customize permissions option and then click
Custom to define the custom permissions .
Note The PLC engineer must not be given any other permissions or privileges
within the system except for write access to that secure folder. The CS engineer
will be provided with read access only. For more information, see “Unity Pro
Object Template Security” on page 71.
6. Click Finish to successfully make the shared folder immediately

accessible to all users. You can also run the wizard again to set up another
shared folder.

4. Security 81
Mapping the Network Drive

You can create a When user create a shortcut to a shared folder or computer on
a network (also called mapping a network drive), user can get to it from
Computer or Windows Explorer without having to look for it or type its
network address each time.
1. To open the Map Network Drive window, click Start > right-click
Computer > Map Network Drive.
2. Select the drive from the Drive list and then select the folder you want to
connect to. Since you are creating a network map, provide the share path
name created in Step 3 under Sharing the Folder on page 78.
Example: <machine Name>\share Name or <\\IPaddress>\share name
3. Select the Reconnect at logon check box and click Finish.
Note If you can't connect to a network drive or folder, the computer you're
trying to connect to might be turned off or you may not have the right user.
Contact your network administrator for assistance.
Your computer is now connected, or mapped, to the network drive.

82 4. Security

83
C H A P T E R 5
Galaxy Sync Service
This chapter describes the Galaxy Sync Service. The Galaxy Sync Service
collects configuration data during deployment from the Control Editors and
distributes it to history and security clients on the network. For more detailed
information about the Galaxy Sync Service, refer to Access Manager User’s
Guide (B0750AD).
Contents
• Software Components
• Galaxy Sync Service Operation
• Refreshing the History and Security Database
• Galaxy Sync Service Utility
Software Components
The Galaxy Sync Service is installed on the Galaxy Repository server and set
to start up automatically when the system boots. The COM interop component
and associated DLLs are installed on the clients where the I/A Series Security
and/or I/A Series History Provider objects are deployed. These objects connect
to the Galaxy Sync Service.
Galaxy Sync Service Operation

When tags configured within the Control Editors for history and/or security are
deployed, the Control Editors notify the Galaxy Sync Service to collect the
configuration data. It then distributes the data to the history and security clients
on the network. The Galaxy Sync Service supports redundant historical data
collectors. It effectively sends the same data set to both collectors in a
configured pair of redundant app engines.
Refreshing the History and Security Database

The Galaxy database maintains all deployed security and history information
used by the Galaxy clients for authorization of operator changes to Control
Process parameters and for historization or requested parameters. This
database is a list of the deploy and undeploy transactions that have occurred.

84 5. Galaxy Sync Service
After a period of repetitive deploys and undeploys, it may be appropriate to

repopulate this database only with records of the most recently deployed
history and security information. The refresh operation does not alter the
contents (i.e., deploy or undeploy) or affect the operation of the CPs.
The refresh operation can also be performed in a situation where the data on
the clients and server becomes out-of-sync for any reason such as re-ghosting
of work stations.
Note The refresh process is NOT intended for casual use. Rather, it is
designed for use after a system has been initially configured (that is, near the
end of system commissioning) or substantially re-configured (that is, during a
shutdown or maintenance period). It may also be used after a catastrophic
failure has occurred that caused a database to be corrupted or similar problem.
Note The Control Editors are not able to perform deploy, undeploy, or edit
actions while the refresh process is in progress. Users must avoid using
DirectAccess or Galaxy Sync Utility on any workstation in the Galaxy during
the refresh process.
Note Only administrators or users with administrator privileges can

perform the refresh operation.
The refresh operation process has two stages, the first involves populating the
security/history database with the latest deployed information, and the second
involves transmitting the new data to the clients.
The time of these operations is dependent upon the number of CPs and other
objects deployed in the Galaxy. It could take several minutes to complete the
first phase. The security information is transmitted at a rate of 60,000 tags per
minute, and history tags are be transmitted 18,000 tags per minute to the
clients.
When the History information is refreshed, the second stage causes a gap in
history collection if done on a running system, because points are not
historized until the History collector object (or IASeriesHistory object)
receives the refreshed set of tags, subscribes them with OM, and registers the
tags in the designated Wonderware Historian Server. Security is retained with
the old values that last deployed until refresh operation is completed.
Refresh Procedure
The refresh operation may be performed for either:
• Security database only
• History database only
• History and Security databases simultaneously in one operation
Proceed as follows to perform the refresh operation:
1. Login as a user with Administrator privileges.
2. Check in all templates and instances.

5. Galaxy Sync Service 85
Note All the Control Software templates and instances should be checked-in
before the refresh operation is started.
3. Open the ArchestrA IDE, preferably on the Galaxy Repository server.

4. Close all other IDE sessions in the Galaxy.
5. Choose Galaxy > Refresh History and Security Database from the main
menu.
Note If a user with non-administrator privileges attempts to start the Refresh

operation, the following dialog box will be displayed:
Figure 5-1. User Does Not Have Administrator Priviledges Dialog Box
Note If any templates or instance is checked out before the operation, the
following message will be displayed to indicate all objects should be in
checked-in state:
Figure 5-2. Templates or Instances Are Currently Checkedout Dialog

Box

6. The Refresh History and Security Database dialog box is displayed.
Figure 5-3. Refresh History and Security Database Dialog Box
7. Check either the Security checkbox, History checkbox or both History

and Security checkboxes.
8. Click the Refresh button. The following dialog box appears.
Note Because the window title varies depending on whether refreshing

History, Security or History and Security databases, the window title shown in
f.igures may not match what you see on the screen.
Figure 5-4. Close Other Instances of ArchestrA IDE Dialog Box
9. Click Yes to initiate the Refresh process. All buttons are grayed-out and
status messages are displayed in the status listbox.
Note If more than one ArchestrA IDE is open when attempting a Refresh
operation, the following dialog box will be displayed.
Figure 5-5. More Than One ArchestrA IDE Session Dialog Box

5. Galaxy Sync Service 87
10. When the first stage of the Refresh process is successfully completed, the
Refresh Successful dialog box is displayed.
Figure 5-6. Refresh Successful Dialog Box
Client workstations start receiving the history and security data as soon as the
refresh operation is complete.
Note The Galaxy database will be locked briefly while the refresh operation
is in progress. During this period, users are prevented from opening another
session of ArchestrA IDE that connects to this Galaxy.
Note For any reason, if the refresh operation is terminated or IDE is closed
before a successful completion, the refresh operation MUST BE re-run.
Otherwise, client workstations will not receive the updated security/history
data.
Galaxy Sync Service Utility

The Galaxy Sync Service Utility can be used to control and configure the
Galaxy Sync Service. This application may be used from any Control
workstation or from the server itself and is invoked by clicking Start >
Programs > Invensys > InFusion Access > GalaxySyncServiceUtility.


89
C H A P T E R 6
Terminal Services and

Remote Desktop Services
This chapter describes Terminal Services and Remote Desktop Services, which
allow applications to be run from remote client workstations.
Contents
• Overview of Terminal Services and Remote Desktop Services
• Terminal Services and Remote Desktop Services for InTouch Software
• Network Load Balancing for Remote Desktop Protocol Sessions
Overview of Terminal Services and Remote

Desktop Services
Terminal Services is a feature of the Microsoft Windows Server 2003
operating system, while Remote Desktop Services is the same feature of the
Windows Server 2008 R2 Standard operating system. They allow applications
to be run from remote client workstations. Refer to the Wonderware document
Terminal Services for InTouch Deployment Guide for setting up the appropriate
Terminal Services and Remote Desktop Services licensing. Terminal Services
is also covered in other documentation:
• For a server with Windows Server 2008 R2 Standard, refer to the section
“Terminal Services and Remote Desktop Services” in the release notes
included with your Control Core Services software.
• For a server with Windows Server 2003: Model P91 System
Administration Guide (Windows® Server 2003, Standard Edition with
Service Pack 1) (B0700BX).
It is important to note that the applications invoked from the remote client
workstation actually execute on the server but have their mouse/keyboard input
and their display output redirected to the remote client workstations. This
means that the number of remote clients logged in to the server directly
impacts the performance of the server, such as CPU loading, memory and disk
usage.

90 6. Terminal Services and Remote Desktop Services
Platforms that are used to display Control HMI windows must have monitors
capable of 1280 x 1024 or 1920 x 1080 screen resolution. This includes the
Terminal Server and any remote client stations that log into that server.
Note Regardless of the applications that are used by the remote client, refer to
the “(Windows Server 2003 Only) Remove Control HMI Startup Shortcut from
“All Users” Startup Directory” on page 91 and follow the instructions for
removing Control HMI from automatically starting up on a remote login. This
must be done prior to any remote logins to the terminal server.
Terminal Services and Remote

Desktop Services for InTouch Software
The appropriate Terminal Services licenses, which include InTouch remote
session licenses and Microsoft Terminal Server Client Access Licenses (TS
CALs) are required to access terminal services. The appropriate Remote
Desktop Services are similarly required to access these services.
The server that is hosting Terminal Services or Remote Desktop Services, and
Control HMI software must also have the Control Core Services software
running on it.
There are a number of steps that need to be followed in order to successfully
prepare a terminal server for hosting remote InTouch clients. These steps need
to be followed in the order presented in this document. This information is
based on the Wonderware document Terminal Services for InTouch
Deployment Guide.
The general set of steps are:
1. For Windows Server 2003 only, remove the Control HMI startup shortcut
from the Startup directory for All Users.
2. Create and configure the user accounts for each user that will be logging
into the terminal server. Users that access InTouch software require
specific privileges.
a. Create the user accounts.
b. Create the local user groups and configure connection security for
each group.
c. Associate the user accounts with the required local groups.
d. Configure the remote session properties for each user. This includes
adding the ability to access Foxboro Evo programs and configuring
session connect/disconnect properties.
3. Configure the NAD properties for each user account so that each user
accesses a separate copy of the Control HMI.
4. Configure automatic or manual startup of the Control HMI when a user
logs in.

6. Terminal Services and Remote Desktop Services 91
(Windows Server 2003 Only) Remove Control HMI

Startup Shortcut from “All Users” Startup
Directory
On stations with Windows Server 2003, the Control HMI software is started
automatically when a workstation boots. This is accomplished by placing a
shortcut to the Control HMI startup script in the Startup directory for “All
Users”. This means that when any user logs into the workstation, either locally
or remotely, Control HMI software starts up. However, this is not the desired
behavior for remote logins on the terminal server. To change this behavior, the
startup shortcut file, “InFusion View” must be moved from the “All Users”
startup directory to the “Fox” startup directory. The following picture shows
where this shortcut file would reside after moving this shortcut from the “All
Users” directory.
Note For the secure installation, move the “InFusionView” shortcut file to the
Plant Engineer's user group startup directory, similar to the shortcut file in the
“Fox” startup directory.

Figure 6-1. Location for Control HMI (“InFusion View”) Startup

Shortcut
User Accounts for InTouch over Terminal

Services and Remote Desktop Services
Each user that logs into the terminal server must do so with a unique login
name. Multiple users cannot use the same login name to log into the server. For
example, there cannot be multiple users logged into InTouch as “Guest” at the
same time. Accounts for each user must be created either locally on the server.
The discussion here assumes that accounts are created on local servers.
According to the Terminal Services for InTouch Deployment Guide, it is
recommended that three local groups be created on the terminal server.

Note For the secured install do not create local groups. Use the Plant
Engineers group for setting up Terminal Services and Remote Desktop
Services permissions instead of local groups.
• WW_Admins – Members of this group have administrative connectivity

rights on the terminal server. They are able to perform all functions on
other sessions including logging off, disconnecting, and resetting any
session.
• WW_Users – Members of this group have only user connectivity access
on this server. This is the preferred choice for operators.
• WW_Users_RC – Members of this group have user connectivity access
in addition to the ability to remotely control other users. This group is
optional, and accommodates users who require this privilege, such as
support engineers.
To create terminal server local groups:
1. Click Start on the Windows Taskbar, point to Programs, point to
Administrative Tools, and then click Computer Management. The
Computer Management dialog box appears.
Figure 6-2. Computer Management Dialog Box
2. In the navigation pane located in the left side of the window, under Local
Users and Groups, right-click the Groups folder.
3. Click New Group.
4. Add the three recommended local groups (WW_Admins, WW_Users,
and WW_Users_RC). For each group, fill in the Group Name field and
click Create.
5. When done, close the New Group dialog box and close the Computer
Management window.
After the groups have been created, the next step is to configure the connection
security for these groups. The tool that you use to manage connection settings
and security is the Terminal Services and Remote Desktop Services
Configuration program.

To configure connection security:

1. On Windows XP and Windows Server 2003 stations, click Start on the
Windows Taskbar, point to Programs, point to Administrative Tools, and
then click Terminal Services Configuration.
2. On Windows 7 and Windows Server 2008 R2 Standard stations, click
Start on the Windows Taskbar, point to Control Panel, point to
Administrative Tools, and then click Remote Desktop Services.
The Terminal Services Configuration dialog box appears listing all of the
created connection types for the terminal server in the right pane.
Figure 6-3. Terminal Services Configuration Dialog Box
Note When configuring security, make sure that you set the security for
each of the connection names that exist. Setting the security for one
connection name does not automatically set the security for all connection
names.
3. Double-click RDP-Tcp in the right pane. The RDP-Tcp Properties dialog

box appears.
4. Click the Permissions tab to activate the Permissions property sheet.

Figure 6-4. RDP-Tcp Properties Dialog Box - Permissions Tab
Note The RDP-Tcp Properties property sheet provides global settings

that override individual user settings. If you are having problems getting a
particular user setting to work (such as auto-logon), remember to refer to
this window to determine if there is a conflicting global setting.
5. Remove all the listed groups except Administrators and Remote

Desktop Users. The default groups are not appropriate for managing
access to your terminal server. For example, consider the Users group.
Under most circumstances, you do not want to have just any user
accessing the terminal server. If you wanted to restrict a user's access for
any reason, the only way to do so would be to remove them from the
Domain Users group, which would also restrict them from accessing other
non-TS domain resources.

6. Add the three recommended groups mentioned earlier, assigning them the
following permissions:
Group Permissions
WW_Admins Full Control
WW_Users User Access
WW_Users_RC Special Access (User Access + Remote Control)
Plant_Eng Full control
To add the three recommended groups and assign permissions, perform

the following:
a. Click Add, and then click Advanced.
b. Click Find Now, and scroll the bottom pane.
c. Click WW_Admins or Plant Engineers, select Allow Full Control,
and click Apply.
d. Click WW_Users, select Allow User Access, and click Apply.

e. Click WW_Users_RC and select Allow User Access. For the

WW_Users_RC group click Advanced to view the Access Control
Settings for RDP-Tcp dialog box. Select WW_Users_RC and then
click Edit. Check the Allow box for Remote Control.
Figure 6-5. WW_Users Group Permissions

7. Click OK.
The RDP-Tcp Properties Permissions tab should look similar to this:
Note On a secured install, Plant Engineers will be displayed on the RDP-

Tcp Properties Permissions Tab screen.
Figure 6-6. RDP-Tcp Properties - Permissions Tab Settings
8. Click OK. Close the Terminal Services Configuration window.

9. Now that the groups have been created and their permissions configured,
create the local user accounts. Each user that logs into the terminal server
needs to have a unique user id, i.e., each remote user must log on using a
different user account.
Note Make sure each user account has a non-blank password and is a
member of the Power Users and Remote Desktop Users groups.
Note The following steps are not needed for secured installations. The user
accounts are managed on the Primary Domain Controller.

To create and configure user accounts to access a terminal server:

Administrative Tools, and then click Computer Management.
2. In the navigation pane on the left side of the window, open the Users
folder under Local Users and Groups. To create a user, right-click in the
right pane and select New User. Enter a user name and password. Click
Create. Click Close.
3. For each user that is to access the server through a Terminal Services
session, double-click the desired user to open the Properties dialog box.
4. Click the Member Of tab to activate the Member Of property sheet.
Remove any default groups. Click Add, click Advanced, and then click
Find Now. Highlight the first group, hold down the Ctrl key and select the
other groups. Click OK. As a minimum, add the groups to each user
account as shown here:
Figure 6-7. Remote User Properties - Member Of Tab
Note If a user requires access to the IDE or SMC from the remote
terminal, that user must also be a member of the Administrators group on
the Terminal Server. If the Galaxy Repository server is separate from the
Terminal Server, then mirrored user accounts need to be created on the
Galaxy Repository server and be members of the Administrators group as
well.

5. Click the Profile tab to activate the Profile property sheet. Configure the
profile for each user as shown here:
Logon script: ia_user.bat
Figure 6-8. Remote User Properties - Profile Tab

6. Click the Sessions tab. Configure the fields as shown here:
Figure 6-9. Remote User Properties - Sessions Tab
7. Click OK to save your changes.
NAD Configuration for Terminal Services and

Remote Desktop Services
Network Application Development (NAD) is the preferred architecture on
terminal servers hosting InTouch. NAD provides a separate application folder
for every user. (For more information on how NAD works, see “Building a
Distributed Application” in the InTouch User's Guide.)
The NAD folders must be created manually. These folders can get quite large
(e.g., 3 GB), so be sure to create them on a drive with sufficient free space. On
a Control workstation, these folders should be on the D: drive.
To configure NAD:
1. From a local window on the terminal server, create a directory on the D:
drive named “D:\NAD”.
At this point, make sure that Control HMI software is not configured to
start up automatically for the user accounts that are to be used for remote
access. Verify that the Control HMI startup shortcut has been removed
from the “All Users” directory, as described in the previous section,

“(Windows Server 2003 Only) Remove Control HMI Startup Shortcut

from “All Users” Startup Directory” on page 91.
Another way to configure a user account to automatically start Control
HMI software is to fill in the Starting program fields in the Environment
tab of the user account Properties dialog box, as discussed in “Configuring
Start Program for Remote Users” on page 104. Make sure this has not
been done!
2. From a remote client workstation, log on to the terminal server (normally
using the Remote Desktop Connection application) under each of the
remote user accounts configured in the previous section and perform the
following steps from each remote session:
a. Create a directory under D:\NAD for each user, e.g., D:\NAD\User1,
substituting the real user account name in place of User1.
b. From the Start menu, select Programs > Wonderware > InTouch.
The InTouch Application (Control HMI) Manager window should
appear:
Figure 6-10. InTouch Application Manager Window

c. In the InTouch Application (Control HMI) Manager window, right-

click in the white space and click Node Properties. The Node
Properties dialog box appears with the App Development property
sheet active.
Figure 6-11. Node Properties - Application Development Tab
d. Select the Enable Network Application Development checkbox.

e. In the Local working directory field, type the path of the NAD
directory, e.g., D:\NAD\User1 (substituting the real user name in
place of User1).
f. In the Polling period (sec) field, type the appropriate seconds for the
polling period or accept the default.
g. Select the appropriate Change Mode option.
h. Click OK to close the Node Properties dialog box.
i. Within the InTouch Application (Control HMI) Manager, make sure
the Control HMI is selected. If not, add it to the list. The Control HMI
is normally found in D:\InFusion-View. To select the application
without starting up WindowViewer™, double click the application.
This action selects the Control HMI as the current application for the
logged on user. This action also attempts to start the WindowMaker
application, which is not allowed on a NAD client application. Click
OK to dismiss the error message box.
j. Log off from the remote session.
k. Repeat these steps for each remote user account.

Configuring Start Program for Remote Users

There are three options for configuring access to Control HMI software for
remote users:
• Manual Startup
• Automatic Startup with a Taskbar
• Automatic Startup without a Taskbar
Note Do not follow the steps listed in the Wonderware document Terminal
Services for InTouch Deployment Guide for starting InTouch software
automatically. Do one of the following instead.
Configure Control HMI Software for Manual

Startup
No additional configuration is required, as long as the “InFusionView”
shortcut file has been removed from the “All Users” directory. The Control
HMI software does not start automatically when the user logs into the terminal
server. The user must manually startup the Control HMI software.
Configure Control HMI Software for Automatic

Startup with Taskbar
Copy the “InFusionView” shortcut file from the Fox account directory into the
Startup directory for each user. For example, if users “User1” and “User2”
require taskbar access and automatic startup of Control HMI, copy the
“InFusionView” shortcut from the directory C:\Documents and
Settings\Fox\Start Menu\Programs\Startup into the directories C:\Documents
and Settings\User1\Start Menu\Programs\Startup and C:\Documents and
Settings\User2\Start Menu\Programs\Startup.
Configure Control HMI Software for Automatic

Startup without Taskbar (I/A Series Software
v8.7 on Windows Server 2003 Only)
The Control HMI software can be started automatically on the remote desktop
without a taskbar for an I/A Series software v8.7 Terminal Server on Windows
Server 2003 only. To configure, edit the user account properties as follows:
Administrative Tools, and then click Computer Management.
2. In the navigation pane on the left side of the window, open the Users
folder under Local Users and Groups.
3. Double-click a desired user to open the Properties dialog box.

4. Click the Environment tab. Configure the fields as shown here:

Program file name:
startp /b
“%FOXDRIVE%\usr\fox\customer\config\infusionviewLogon.cmd”
Note The “Program file name” in the following dialog box is case
sensitive. Be sure to type the file name as “infusionviewLogon.cmd”.
Start in:
%USERPROFILE%\Local Settings
Figure 6-12. Remote User Properties - Environment Tab
Customizing Access for Remote Users of

Control HMI Software
It is possible to configure what Control HMI software features are accessible
from remote user sessions based on roles set up in the ArchestrA application.
This configuration is done in the Framer configuration software. Refer to
Framer and Alarm Management User’s Guide (B0750AR) for details.

Network Load Balancing for Remote Desktop

Protocol Sessions
The use of Thin Clients or other Remote Desktop Protocol (RDP) clients is a
cost effective way to provide access to the Control HMI or FoxView. Using a
terminal server farm and Network Load Balancing (NLB), a standard feature in
Windows 2008 R2, you can enhance the availability and scalability of these
RDP applications by distributing the remote sessions across a number of server
machines.
Figure 6-13. Network Load Balancing Cluster
Note The Network Load Balancing feature is supported only in systems with
Security Enhanced Control Core Services.
A server machine is configured to be a Remote Session Broker as shown in

Figure 6-13. The Remote Session Broker manages the RDP sessions to the
Windows Server machines configured within the NLB Cluster. Remote clients
connect to the Control HMI or FoxView servers through the Remote Session
Broker, instead of directly connecting to a specific HMI server. The Remote
Session Broker determines to which server in the cluster the remote session
should be directed. This determination is based on configuration settings of the
Remote Session Broker and can be finely tuned to compensate for different
HMI Servers capacity or network topology differences. The Remote Session
Broker can be enabled on either a separate off-platform server, or on one of the
servers within the NLB cluster.
For more information on configuring the Network Load Balancing feature,
refer to the Wonderware InTouch for Terminal Services Deployment Guide
Planning and Implementation Guidelines Guide. For information on Thin
Clients, refer to Thin Client User's Guide (B0700VN).
The following are specific Foxboro Evo considerations when installing a
Network Load Balancing Cluster and Remote Session Broker:

• To maintain cyber security settings, the Remote Session Broker server

should be a Foxboro Evo H90 server, installed with the Foxboro Evo H90
server image.
• To ensure that NIC and other network configuration settings are correct
while installing the NLB Session Broker on an off-platform server, follow
the networking instructions in “Off-Platform Foxboro Evo Control
Software Server Considerations” on page 29.
• While the instructions in the Wonderware User Guide refer to the RDP
servers as VMs, a VM configuration is not required to implement the NLB
feature.


109
C H A P T E R 7
Managed Control HMI

Application
The managed Control HMI is an ArchestrA template that is derived from the
InTouchViewApp Object. Managed InTouchViewApp objects are InTouch
applications that are managed and maintained through the ArchestrA IDE.
This chapter describes the general maintenance and interfaces with the
managed Control HMI application. For detailed information about building the
HMI using ArchestrA Graphics, refer to Window Construction User's Guide
(B0750AS).
Contents
• Managed Control HMI Application Maintenance
• Managed Control HMI Application Deployment and Runtime
• Managed Control HMI Application in Remote Desktop Sessions
• Backup of Managed Control HMI Application
Managed Control HMI Application Maintenance

You can access the Control HMI template from the template toolbox of the
ArchestrA IDE.
Proceed as follows:
1. Open the ArchestrA IDE. Under the Template Toolbox, expand
Control HMI subfolder.
2. Select the $ControlHMI_vx template, where “x” is installed Control HMI
version. For example, for Control HMI v6.0, the name of this template is
$ControlHMI_v6.
3. Double-click the selected template to check out and edit. The template
opens in the WindowMaker.
WindowMaker for the managed Control HMI supports the use of
ArchestrA Graphics, including the Control Situational Awareness (CSA)
Library of graphic symbols.

110 7. Managed Control HMI Application
Figure 7-1. Window Maker
4. Add windows and scripts to the Control HMI Template.

For information about how to add new windows and scripts, refer Window
Construction User’s Guide (B0750AS).
5. Click Runtime switch to test the changes implemented in the Control
HMI template.
Note Use of Runtime switch opens a fully functional runtime application

using the WindowViewer and compiles. This minimizes the compile time
when deploying new edits to a client workstation.
In order to see the live data in the Runtime view, the workstation or server must
have Control Core Services software installed.
6. Exit the WindowMaker to check in the changes made to the Control HMI.

7. Managed Control HMI Application 111
7. Under Deployment, select the client workstation.
Figure 7-2. Deploy Changes to Client Workstation
8. Under the AppV, right-click the selected workstation Control HMI

instance and select Deploy from the context menu to deploy the changes
to the client workstation.

Managed Control HMI Application Deployment

and Runtime
The managed Control HMI can be deployed only to View Engines. The
Control HMI View Engine is renamed as <StationID>_AppV, where
<StationID> is the name of the Workstation. Following a similar convention,
the instance of the $ControlHMI template is named as <StationID>_HMI.
The managed Control HMI starts automatically when a user logs onto the
workstation. You can also start the Control HMI manually by opening the
InTouch Application Manager, selecting the Deployed instance, and launching
the WindowViewer.
Figure 7-3. Opening Managed Control HMI Manually
Note Launching WindowViewer for the first time requires the Control HMI
to be compiled. This may take five to ten minutes to complete.

7. Managed Control HMI Application 113
Managed Control HMI Application in Remote

Desktop Sessions
The Terminal Server requires only one deployed instance of the managed
Control HMI. When a new user logs onto the server, a separate work folder is
created automatically. The console session on the Terminal Server will also
have a separate work folder.
Figure 7-4. Managed Control HMI Deployed on Terminal Server
Note The work folder copies are created in the User's folder located on the C:
drive. Make sure that the C: drive partition on terminal servers have sufficient
space for all user work folder copies.
Each remote user needs to log into the Terminal Server and select the Control
HMI Application to start at log in.
1. Log into the Server.
2. Start the InTouch Application Manager.
3. Select the managed Control HMI application.
4. Start the WindowViewer.
The application is copied and compiled the first time the remote user logs in
and selects the managed application. For detailed instructions, refer to
Foxboro Evo Control Software Installation Guide (B0750RA).
Backup of Managed Control HMI Application

You cannot make a copy of the Control HMI template because it is a derived
template of the InTouchViewApp ArchestrA Object. You must export the
Control HMI template in order to make a backup copy. The exported package
file can be imported to restore the Control HMI.

When importing an Control HMI package, it is possible to overwrite the

existing template. To prevent this, make sure you rename the current template
in the template toolbox before importing the backup package.
For detailed instructions, refer to Managed Application Backup section in
Chapter 4 of Window Construction User's Guide (B0750AS).
For information about how to import and export templates, refer Configuration
Utilities User’s Guide (B0750AZ).

115
C H A P T E R 8
Remote Desktop Using

InTouch Access Anywhere™
InTouch Access Anywhere provides remote access to the Foxboro Evo Control
HMI InTouch application from any HTML5 compatible web browser. This
interface uses Remote Desktop technology to render the desktop in an HTML5
client. Any browser that supports HTML5 can be used as the client.
Contents
• Overview and Architecture
• Licensing
• Installation of the InTouch Access Anywhere Server
Overview and Architecture

InTouch Access Anywhere is fully documented in the following Wonderware
documents
• InTouch Access Anywhere Administrator’s Manual
• InTouch Access Anywhere Secure Gateway Administrator’s Manual
• InTouch Access Anywhere User Guide
The following information is an overview of this technology. More details can
be found in the InTouch Access Anywhere Administrator’s Manual.
InTouch Access Anywhere provides the following benefits:
• End-users can access and interact with Wonderware InTouch applications
from any device that has an HTML5 compatible web browser
• No need to install or configure any software on the end-point device
• No need to perform software updates or patches on end-point devices
• Works on platforms that only support web applications, and do not allow
application installation, such as Google Chrome OS
• Consistent look-and-feel on any platform that has an HTML5 compatible
browser
• It can be seamlessly integrated with other web-based applications and
portals.

116 8. Remote Desktop Using InTouch Access Anywhere™
InTouch Access Anywhere is comprised of two installable components:

• InTouch Access Anywhere Server (WebSocket server) that is installed on
the RDP host where Wonderware InTouch resides. This includes a
collection of web resources (HTML files, CSS, JavaScript, images, etc.).
• InTouch Access Anywhere Secure Gateway – This is an optional
component installed separately on a machine in a DMZ to enable access
beyond a firewall. This is the recommended architecture when you want
users on the business side of your operation to be able to access InTouch
applications running on the HMI SCADA network. For more information
on the InTouch Access Anywhere Secure Gateway, refer to the InTouch
Access Anywhere Secure Gateway Administrator’s Manual.
This diagram illustrates how the components of InTouch Access Anywhere
work together:
Figure 8-1. InTouch Access Anywhere Components
The user initiates the process by directing the browser to the start page hosted
on the web server (http://<machinename>:8080/). The Start.html page is
displayed in the web browser using HTTP/HTTPS.
1. The browser opens a WebSocket connection to the InTouch Access
Anywhere Server, which is running on the RDP host itself.
a. If the optional InTouch Access Anywhere Secure Gateway is used,
the InTouch Access Anywhere Server browser session will connect
through it.
2. The InTouch Access Anywhere Server translates the WebSocket
communication to and from RDP, thus establishing a connection from the
browser to the RDP host itself.
3. The browser then displays the content of the remote application.

8. Remote Desktop Using InTouch Access Anywhere™ 117
Licensing
InTouch Access Anywhere is licensed for use only with the Control HMI
InTouch WindowViewer application. Licensing is only through the InTouch
TSE Concurrent license.
Installation of the InTouch Access Anywhere

Server
The InTouch Access Anywhere server is installed on a Remote Desktop
Windows Terminal Server, where the Foxboro Evo Control HMI InTouch
application has been installed. Refer to the InTouch Access Anywhere
Administrator’s Guide for complete installation instructions, including pre-
requisites, pre-installation instructions, and firewall considerations. If the
InTouch Access Anywhere Secure Gateway will be installed, also refer to the
InTouch Access Anywhere Secure Gateway Administrator’s Manual.
InTouch Access Anywhere can be installed from the Wonderware System
Platform DVD, after the Control Software has been installed.
1. Insert the Wonderware System Platform DVD, and run setup.exe from the
root directory.
2. Select Modify from the initial dialog, and select Next.
3. Check the box next to InTouch Access Anywhere Server under the
InTouch product selection tree, and select Next.
Figure 8-2. Wonderware System Platform 2014 Installation
4. Accept the End User License Agreement, and click Agree.

118 8. Remote Desktop Using InTouch Access Anywhere™
5. Select Next on the Prerequisites dialog. All prerequisites should already

be met.
6. After the product is installed, select Finish from the final dialog.
Refer to the user documentation for complete information on configuring and
using the InTouch Access Anywhere products. These documents include
instructions to ensure that the InTouch application has been properly installed
and set up for remote desktop access. For information specific to the Control
HMI, refer to the chapters in this document Chapter 6, “Terminal Services and
Remote Desktop Services” and Chapter 7, “Managed Control HMI
Application”.

119
C H A P T E R 9
Multi Monitor Setup for

InTouch
InTouch 10.x software supports multiple monitor systems that use the default
multi-desktop video mode. This allows a single application with a resolution of
1280x1024 or 1920x1080 to be viewed on any multi-monitor workstation
without recompiling every time a change is made to the application. This also
does not require any special video drivers.
Note For setting up multiple monitors with InFusion View 1.x, refer to
Appendix A, “Multi Monitor Setup for InFusion View 1.x”.
Setting Up InTouch Software to Run on Multiple

Monitors
Multiple monitors are enabled by changing the InTouch MultiScreen settings
in the win.ini file. On server class boxes there may be additional win.ini files
for each configured user. All win.ini files should be configured.
1. Right-click on the Windows start menu and select Open Windows
Explorer or Explorer.
2. Click the C:\ drive and search for the filename: win.ini
3. On workstations with Windows XP or Windows 7, there should be only
one win.ini file.
Location on Windows XP:
• C:\Windows
Location on Windows 7:
• C:\ProgramData\Wonderware\InTouch
On server class stations, there are multiple win.ini files that need to be
modified. Servers have a separate win.ini file for each user that has logged
in. As well, there is a global wini.ini file that is used when new users log
in. All of these files must be modified when changing multi-monitor
settings. The locations of these win.ini files vary depending on the server’s
operating system. Figure 9-1 shows win.ini files found on a server with
Windows Server 2008.

120 9. Multi Monitor Setup for InTouch
Figure 9-1. Searching for win.ini File on Windows Server 2008
Locations on Windows Server 2003:

• C:\Windows\
• C:\Documents and Settings\<UserID>\Windows
Locations on Windows Server 2008:
• C:\ProgramData\Wonderware\InTouch
• C:\Users\<UserID>\AppData\Local\Wonderware
4. Open each win.ini file using Notepad.
5. Only modify win.ini files that have an [InTouch] or [InTouch Install]
section. If the file contains one of those sections, modify it as described in
the following steps. Here is a potential example of this section:
[InTouch]
MultiScreen=0
MultiScreenWidth=1280
MultiScreenHeight=1024
6. Change the MultiScreen setting to 1 to enable a multi-monitor
configuration.
Change the MultiScreen setting to 0 to disable a multi-monitor
configuration.
7. Add the three settings shown above to each win.ini file if they do not exist.
8. Save and close each file.
9. On Windows Server platforms, perform the same edit to each instance of
the win.ini file.

9. Multi Monitor Setup for InTouch 121
Note This setting has no effect on workstations with a single monitor. The
MultiScreen setting needs to be set to 0 to run the Control Editors on a single
monitor of a multi-monitor station.
Refer to the “Configuration of MultiMonitor Layout” section of the Framer

and Alarm Management User’s Guide (B0750AR) for instructions on setting
up the Control HMI to run on multiple monitors.

122 9. Multi Monitor Setup for InTouch

123
C H A P T E R 1 0
Configuration and Installation

Considerations
This chapter describes considerations for configuring and installing the Control
Software applications.
Contents
• Foxboro Evo Control and Host Workstation Upgrade Considerations
• Foxboro Evo Control Software Support for I/A Series Software v8.4.x-
v8.8, and Control Core Services Software v9.0 or Later Configurations
• Stand-alone Configuration
• Backing up the Galaxy
• Migrating Configuration Data from Existing I/A Series or Foxboro Evo
Systems
• I/A Series Alarm Provider
• Alarm Logging Configuration
• Changing Date and Time
Foxboro Evo Control and Host Workstation

Upgrade Considerations
All workstations in a Foxboro Evo Control Galaxy need to be running the same
version of the Control Software. For example, a Control Editors workstation
must be running the same version of the Control Software as the Galaxy server
to which it is connected. Keep this in mind when determining which
workstations and servers will have the Control Software installed on them,
paying particular attention to the upgrade strategy for the plant.
While ideally the Control Processor host workstations would have the Control
Software installed on them, this is not a requirement, and would allow the
Control Software to be updated without updating the CP host workstations.
FCS v3.x-v4.x and the Control Software v5.x and later will support
configuring CPs hosted by workstations at I/A Series software v8.4.x, as well
as the I/A Series and Control Core Services software versions supported by the
current Control Software.

124 10. Configuration and Installation Considerations
However, this configuration does have limitations, as identified below.
Foxboro Evo Control Software Support for

I/A Series Software v8.4.x-v8.8, and Control Core
Services Software v9.0 or Later Configurations
The Control Software supports the system configuration, engineering and
operation of systems hosted by I/A Series software v8.4.x-v8.8 or Control
Core Services software v9.0 or later. The Control Software cannot be installed
on workstations with I/A Series software v8.4.x-v8.6 and therefore care should
be taken to plan the Control Software upgrade or support of such a system in
general. The information below details the issues a team should account for
during any planning or operation of a system with I/A Series software v8.4.x-
v8.6.
Figure 10-1 illustrates a system that supports engineering and operation of a

CP hosted by a workstation with I/A Series software v8.4.x-v8.8 or Control
Core Services software. However, some of the workstations in this
configuration have limited deployment capability.
Figure 10-1. System Supporting Workstation with I/A Series Software

v8.4.x-v8.8 or Control Core Services Software
Deployment – CP Hosts Installed with I/A Series

Software v8.4.x
The deployment process needs a workstation with both the Control Software
and I/A Series software installed in order to perform deployment operations.

10. Configuration and Installation Considerations 125
The deployment process can only use the initiating workstation or the CP host.
For example, if deploying from an off-control network workstation (no
I/A Series software installed), the target CP’s host must be a Control
workstation. Or, if deploying from a Control station that is also on the
I/A Series, the CP host workstation does not need to be a Control workstation.
Therefore, in Figure 10-1 above, deployment to CP #1 is not supported from
the Galaxy, WS #4 and WS #5 as neither the CP host nor the deploying
workstations have both the Control Software and I/A Series software installed.
Also, no terminal service clients to WS #5 can deploy to CP #1.
Deployment operations to CP #2 are supported from all Control workstations
in Figure 10-1 above, as this CP is hosted by WS#3, which has both the
Control Software and I/A Series software installed.
Control Configuration
The deployment process validates the block type and parameter set prior to
sending control data to the CP. In order to avoid deployment warnings or errors
relating to CP versions, only configure parameters, parameter values and block
types that are supported by the target CP.
Each CP host machine has a Parameter Definition File (PDEF) installed as part
of the I/A Series or Control Core Services software installation process. The
PDEF contains block parameter information specific to the I/A Series or
Control Core Services version installed on the CP host. Using the PDEF on the
CP host, the Control Software deployment process will only deploy supported
block types and supported parameters to the CP. But, the deployment process
cannot validate if the valid range of the parameter has changed, for example, if
the parameter has been changed from a Boolean to an Integer. If an invalid
parameter is deployed to the CP, the deployment will proceed without any
warnings, but the CP may not operate as expected.
System Configuration
System configuration of the workstations with I/A Series software v8.4.x-v8.8
and Control Core Services software is supported via the current Control
Software. Creating Commit media and the reconcile process is supported for
I/A Series or Control Core Services installations with mixed versions as
detailed in Figure 10-1 on page 124.
Bulk Generation
The Control Bulk Generation processing uses an internal Control PDEF. The
integrated Control PDEF’s revision is the latest supported version. The Control
Software v5.0 release supports I/A Series software v8.7-v8.8, and Control
Core Services software v9.0; therefore the PDEF used during Export SaveAll
and Import SaveAll is Control Core Services software v9.0.
Generating the control database from the Bulk Generation Object uses the
integrated Control PDEF during its operation. Therefore, when bulk generating
configuration information targeted for CPs, whose image is not the version
supported by the internal Control PDEF, only use the block/parameter set that
is supported by the target CP image.

Export SaveAll
The Control export process uses the internal PDEF to determine the SaveAll’s
content. This export should never be used to perform a LoadAll on previous
releases of I/A Series software. The I/A Series/Control Core Services ICC
LoadAll process cannot process the block and parameter set generated by a
newer I/A Series/Control Core Services version.
Stand-alone Configuration
Loading and configuring large databases can place a heavy CPU load on the
Galaxy Repository server. During such operations, other users of the Galaxy
will experience delays or be prevented from doing other operations such as
bulk generation, import/export, or deployment. Therefore, prior to
commissioning, it is recommended that as much configuration as possible be
performed using a stand-alone platform. The predefined “Stand-Alone
Configuration Station” provided by the Control Software installation program
can be installed on any laptop or desktop running the Windows XP operating
system for this purpose.
Prior to performing stand-alone configuration activities, however, is it highly
recommended that the network topology be defined in a central Galaxy
Repository and distributed to the Galaxies on other stand-alone platforms. This
would involve configuring such things as equipment units, controllers,
workstations, and FBMs, and establishing the correct hosting relationships, etc.
Once that was completed, the Galaxy could be backed up, and used to “seed”
the other Galaxies on the stand-alone platforms. This gives the control
engineers a common base from which to start their control configuration
activities without worrying about conflicting letterbugs, TCP/IP addresses, etc.
when merging data later on. The “backup” and “restore” functions are
provided by the System Management Console (SMC). Refer to Chapter 11,
"Backing Up and Restoring Data" for detailed procedures. Note that the restore
operation completely replaces the Galaxy Repository database, so make sure
there is nothing you need to save in the existing Galaxy before doing a restore.
Once the Galaxies on individual stand-alone platforms have been created in the
manner described above, the control engineers may now perform their normal
control configuration activities, i.e., creating compounds, strategies, and
blocks. When control configuration has been completed, each engineer may
then export their control objects that were created on their stand-alone
platform, and import those same objects into the central Galaxy Repository.
(Refer to Chapter 11, "Backing Up and Restoring Data" for detailed
procedures.) The only thing remaining would then be to perform any control
configuration activities needed to tie the control objects together that were
generated on separate stand-alone platforms, if necessary.
Backing up the Galaxy

It is highly recommended that you back up the Galaxy often, especially before
making any significant changes. The procedure for doing this is described in
Chapter 11, "Backing Up and Restoring Data".

Migrating Configuration Data from Existing

I/A Series or Foxboro Evo Systems
It is possible to import data from existing I/A Series or Foxboro Evo systems
by using SaveAll media, System Definition exports, and IACC exports.
To load System Definition (SysDef) configuration data, perform an “export” of
the configuration while in the System Definition program. (Note: It is not
possible to import from Commit media.) Alternatively, you can import data
created by the IACC export command-line utility (ArchExport.exe), which
exports data for the Control Software.
1. Open ArchestrA IDE.
2. Create a bulk data object and import the SysDef files or IACC export into
it.
3. Bulk generate the hardware in order to create the matching hardware
components within the Control Editors.
To load compounds and blocks from SaveAll media, do the following:
1. Open the IDE.
2. Create a bulk data object and import the SaveAll data.
3. Bulk generate the blocks and compounds to create the control components
within the Control Editors.
Refer to the Bulk Data Editor User’s Guide (B0750AF) for more detailed
information for the above procedures.
Creating Library Objects for Include Files

Before or after importing the SaveAll into a bulk data object (but before the
generated block is compiled), you can import all of your referenced include
files into a Control Software Library Object. In the Import Bulk Data Wizard
dialog box, you can specify the “HLBL Library Object” and “SFC Library
Object” where include files will be found at Bulk Generate time.
The Import Bulk Data Wizard will extract the include files from the SaveAll
and place them in a user-specified includes library using the same directory
structure used in the Control Editors workstation. The files can then be
accessed from the library when they are compiled using either the Control
Editors Sequence Block HLBL Editor or the Sequence Block SFC Editor.
• If the sequence block code was developed using the HLBL Editor, refer to
Sequence Block HLBL Editor User’s Guide (B0750AL) for information on
setting up an HLBL Includes library.
• If the code contained in the sequence blocks was developed using the
FoxSFC Editor, see Sequence Block SFC Editor User’s Guide (B0750AM)
for information on setting up an SFC Includes library.
For example, consider a DEP block in a SaveAll that contains sequence source
code in it that contains the line:
#include “C:\usr\fox\source\includes\myfile.h”

If you configure the “HLBL Library Object” in the Import Bulk Data Wizard
as $HLBL_Library, this line will be converted to:
#include “$HLBL_Library\usr\fox\source\includes\myfile.h”
After Bulk Generate, when the block is compiled, the compiler will look in the
$HLBL_Library object for the included source.
Using Base versus User-Defined Block

Templates
If you accept all the defaults for block types when importing SaveAlls, all
blocks will be derived from their base types: $AIN, $AOUT, $PIDA, and so
forth. If you bulk generate using a base type such as $AIN, you will not be able
to define the appearance for anything derived from $AIN when seen in a
control strategy.
However, if you bulk generate using a user-defined template such as $MyAIN,
you will be able to define the appearance of anything derived from $MyAIN
when seen in a control strategy. If you wish to change the appearance of the
blocks, make sure you bulk generate using user-defined block templates, for
example, $MyAIN, $MyAOUT, or $MyPIDA.
Importing SaveAlls into a Single or

Multiple Bulk Data Objects
If SaveAlls are imported into the same bulk data object, all connections
between blocks that span SaveAlls are maintained properly as the Control
Software connections. However, if SaveAlls are imported into different bulk
data objects, the cross-references between SaveAlls will remain Foxboro Evo
type connections.
It is highly recommended that all SaveAlls for a particular configuration be
imported into the same bulk data object to ensure that peer-to-peer connections
between blocks in the various SaveAlls are kept intact. Splitting up SaveAlls
between multiple bulk data objects requires a lot of extra work on the part of
the user to re-establish peer-to-peer connections. Refer to Bulk Data Editor
User’s Guide (B0750AF) for more information on resolving peer-to-peer
connections.
Migration from IACC with Field Device Manager

FOUNDATION fieldbus applications developed and maintained with the
I/A Series Configuration Component (IACC) with Field Device Manager can
be migrated to the Control Editors using an IACC export format and the Bulk
Data Editor.
The XML Export in IACC is a specialized format that provides a migration
path from IACC to the Control Editors. Import of the IACC file includes
conversion of the IACC control strategy diagrams (CSDs) to the Control
Software strategies and resolution of conflicts resulting from differences
between IACC and Control Editors naming rules.

If the IACC database includes FOUNDATION fieldbus H1 devices, the export

creates a separate directory structure containing DD files, device templates,
and device instance data that will be used in bulk-generating new device
templates and instances in the Control Editors.
The procedures for migrating IACC control and device configurations are
covered in Bulk Data Editor User’s Guide (B0750AF).
I/A Series Alarm Provider

The I/A Series Alarm Provider forwards process and system alarms to the
InTouch alarm subsystem. By default, the I/A Series Alarm Provider on each
workstation is configured to store a maximum of 2000 alarms. If there are
more than this maximum number of active alarms on the workstation, the
Alarm Provider discards alarms according to the Discard Sort Order. By
default, the Discard Sort Order is set to LowestPriorityOldestAlarms.
The Maximum Alarms in Database and the Discard Sort Order are part of
I/A Series Alarm Provider Application Object configuration and can be
modified to reflect the desired settings. For example, if the user wants to have a
different setting from the default setting of 2000 alarms for the maximum
number of active alarms on the workstation, the user may select some other
value within the range of 10-32000. The user may also choose a different
option for the Discard Sort Order. Any changes to an I/A Series Alarm
Provider object requires Undeploy-Redeploy of the parent App Engine
(_AppA). For more details refer to the chapter in the Framer and Alarm
Management User’s Guide (B0750AR) document titled “Alarm Planning and
Configuration” under the “Process Alarm Database size and Discard Sort
Order” section.
Backup Alarm Provider

To support the alarm provider failover feature, install a redundant alarm
provider. This is equivalent to the “Alarm Hot Backup” feature in Wonderware
products. Setting up this alarm provider is discussed in the Wonderware
InTouch® HMI Alarms and Events Guide (ITAlarmsAndEvents.pdf), in the
chapter titled “Enhancing Plant Security Through Alarm Redundancy”.
Alarm Logging Configuration

Process and System alarm messages can be logged to a printer using the
InTouch Alarm Printer utility and can be logged to a historical database using
the InTouch Alarm DB Logger. Refer to Framer and Alarm Management
User’s Guide (B0750AR) as well as the InTouch® Data Management Guide for
instructions about configuring these interfaces.
Note Do not start Alarm DB Logger as a Service while ControlHMI is in use

on the same station. However, you can continue to use Alarm DB Logger as an
application on any configuration.

SMC Logging Configuration

The SMC log file has a maximum size of 5 GB. It is recommended that you
install the log file to the D: drive, and if desired, reduce the maximum size of
the log file to conserve disk space.
Perform the following steps:
1. Open the Wonderware SMC (Start > Programs > Wonderware >
System Management Console).
2. Open the Configure dialog box using one of two methods.
a. Expand Log Viewer and select the Galaxy.
b. Select the local host, right-click on it, and select Configure from the
pop-up menu.
_OR-
a. Click Log to open the log in SMC, shown on the right-hand side in
Figure 10-2.
b. From the Action menu, select Configure, as shown in Figure 10-2.

Figure 10-2. Opening the Configure Dialog Box from the Log
3. When the Configure dialog box opens, click the Storage tab as shown in
Figure 10-3.
4. Make sure Enable Logging is selected, and change the Store log
messages in this path field to the D:\SMCLog path, as shown in
Figure 10-3.
5. If desired, change the value in the Limit the total diskspace used for
storing log message to field. Enter a value in MB. (The default at
installation is 5000 MB. The following figure shows a smaller maximum
size of 3000 MB, or approximately 3 GB.)

Figure 10-3. Configuring the SMC Logs
Ensure Time Master Node Is Not Enabled

The Control Editors have a configuration setting called “Time Master Node”
which must not be enabled. If enabled, it will direct all deployed platforms in
your system to synchronize their times to a specific node, and this will cause
confusion and conflicts with the master Timekeeper.
The “Time Master Node” is disabled by default. Do not enable it.
Changing Date and Time

The Wonderware Historian should always be turned off prior to changing the
date and time on the system. Once the time is set, the Wonderware Historian
can be turned back on.
Note When changing time in Master Timekeeper, be sure the time is the same
on all servers and clients, and then restart the systems affected by the time
change.
Note Without restarting systems affected by the time change, the

communication between various services will be blocked, because services
such as syncserver, securityservice, and deployservice will be in a “fault” state.
As a result, deployment, history, and security changes will not be updated.

133
C H A P T E R 1 1
Backing Up and Restoring

Data
This chapter gives procedures for backing up and restoring data.
Contents
• Data to Back Up and Restore
• Galaxy Data
• Backing Up a Galaxy
• Backing Up a Condition Monitor Database with ACM Installed
• Restoring a Galaxy from a Backup
• Restoring a Condition Monitor Database with ACM Installed
• Exporting Selected Objects
• Importing Selected Objects into a Galaxy
• Importing Script Function Libraries
• After You Import
• Backing Up the SQL Server Databases
• Backing Up History Data
• Restoring History Data
• Backing Up the Alarm Message Database
• Control HMI and Data
Data to Back Up and Restore

There are several types of data that should be backed up as recommended by
best practices, such as:
• The entire Galaxy Repository
• Selected objects in the Galaxy
• Runtime databases
• Control HMI and data.

134 11. Backing Up and Restoring Data
To be sure that all data is backed up and nothing is missed, it is recommended

that you periodically create images of your hard drive using drive imaging
software. This software is readily available and in common practice today.
Typically, this process requires shutting down the computer that is being
imaged and saving the image to an external drive.
The following sections discuss what would be required to back up individual
types of data rather than creating complete images of the hard drive.
Galaxy Data
There are several ways to save data from a Galaxy and it is important to
understand the differences and implications of these features. First of all, some
features are available in the ArchestrA IDE window and some are available in
the System Management Console (SMC) window. The following table
summarizes this.
Feature Where Description

Backup SMC Backs up an entire Galaxy to a .cab file.
Restore SMC Restores (replaces) an entire Galaxy from a .cab
file created using SMC Backup.
Export > Automation Object(s) IDE Saves selected objects to a .aqPKG file.
Export > All Automation Objects IDE Saves all automation objects to a .aqPKG file.
Export > Galaxy Dump IDE Saves only selected objects from the Deployment
view to a .csv file. It does not capture the entire
Galaxy.
Note This feature cannot be used for the Control

Software objects, such as Strategies, Compounds,
Equipment Units, etc., since it does not export all
the relationships that are needed to be preserved.
Using this feature for the Control Software objects
causes the resulting file to be corrupt.
Import > Automation Object(s) IDE Imports objects from .aqPKG, .aaPKG and .aaPDF
files.
Import > Galaxy Load IDE Imports data from a Galaxy Dump (.csv) file.
Note This feature is not used in the Control

Software.
Backing Up a Galaxy
Periodically, you should back up your Galaxy. Backing up your Galaxy helps if
you have a computer failure or other problem. If there is a failure, you can
restore your Galaxy from the backup.
Use the Galaxy Database Manager to back up and restore your Galaxy. The
Galaxy Database Manager is part of the suite of ArchestrA System

11. Backing Up and Restoring Data 135
Management Console utilities. The backup function of the Galaxy Database

Manager archives all files and configuration data required to recreate the
selected Galaxy in an empty Galaxy Repository. This includes the ArchestrA
security information you have configured.
To backup an entire Galaxy:
1. Invoke the Galaxy Database Manager. Click Start > Programs >
Wonderware > System Management Console. Expand the Galaxy
Database Manager entry in the left pane.
2. Right-click on the name of the Galaxy to be backed up and select Backup
from the menu.
Note This can only be performed by a user that has Administrator

privileges.
3. Read the warning message. Note that no write operations are allowed to
the Galaxy Repository while the backup process occurs. If write activity is
occurring, you should back up at a later time. Click Yes to continue
backing up and No to terminate the backup function. If you click Yes,
continue with the next step.
4. Enter the path and filename (.cab extension) of the backup file you want to
create. Either type the path and filename or use the browse button to
explore for a file and/or location.
5. When the backup function is finished, click OK.
Backing Up a Condition Monitor Database with

ACM Installed
Asset Condition Monitor uses a separate database (IAMSMasterDB) on the
Galaxy server workstation to store condition monitor configuration. This data
is replicated to a separate database (IAMSClientDB) under
INFUSIONSECURITY on all client workstations.
When the Galaxy backup is performed periodically, you must also backup the
condition monitor database (IAMSMasterDB) from the Galaxy repository
server, if Asset Condition Monitor is installed, in order to restore the condition
monitoring configuration on the system.
The details for backing up a condition monitoring database are described in
“Backing Up Condition Monitor Databases” on page 199.
Restoring a Galaxy from a Backup

To restore a Galaxy from a backup .cab file, a Galaxy of that name must
already exist. If it does not exist, you must first create a Galaxy with that name.
To restore an entire Galaxy:
1. Invoke the Galaxy Database Manager. Click Start > Programs >
Wonderware > System Management Console. Expand the Galaxy
Database Manager entry in the left pane.

2. Right-click on the name of the Galaxy to be restored and select Restore

from the menu.
Note This can only be performed by a user that has Administrator

privileges.
3. Select the backup .cab file to be restored.
Note Restoring a Galaxy in this manner will overwrite the entire Galaxy
by that name. Do not perform this operation unless you intend to restore the
Galaxy to a previous state. All changes made to objects in that Galaxy since the
backup was performed will be overwritten.
Restoring a Condition Monitor Database with

ACM Installed
After the Galaxy is restored, you must restore the condition monitor database
(IAMSMasterDB) on the Galaxy server if Asset Condition Monitor is
installed.
After restoring the IAMSMasterDB, all the publications are required to be
reinitialized to synchronize IAMSClientDB with content in the
IAMSMasterDB.
The details for restoring a condition monitoring database are described in
“Restoring Condition Monitor Database” on page 200.
Exporting Selected Objects

Refer to Configuration Utilities User’s Guide (B0750AZ) and Strategy Editor
User’s Guide (B0750AN) for additional information regarding the Control
Software objects.
You can export some or all of your Galaxy objects. When you export, you are
exporting the objects’ associated templates, configuration state, and
containment state of those objects. The information is saved in an .aaPKG (or
.aqPKG) file.
After the Galaxy objects are exported, you can import into the same or another
Galaxy.
If your objects have scripts associated with them, you need to export the script
library separately. For more information about exporting script libraries, see
“Exporting Script Function Libraries” in the Industrial Application Server
Scripting Guide.
Before you start, make sure all objects you want to export are checked in. If an
object selected for export is checked out, the checked in version of that object
is exported instead. This can lead to old versions of objects being exported.
Exporting an entire Galaxy is different than backing up the database. Unlike
with backups, change logs for the objects are not exported. When you export

objects, only the related security information for the specific object is
exported.
To export selected automation objects:
1. Invoke the IDE.
2. Highlight an instance of an object (or multiple objects using the Ctrl or
Shift key) in the Deployment View.
3. From the Galaxy menu, select Export, then select either Automation
Object(s)… or All Automation Objects. An alternative method is to
right-click on an instance and select Automation Object from its menu.
Then, select a location and provide a name for the file. These operations
produce a file with a “.aqPKG” extension.
4. In the Export dialog box, browse to a path and type a name for the
exported file.
5. Click Save. The file is saved with the specified name and extension.
6. When the export is complete, click Close. Now you can import the saved
file into another existing Galaxy.
Note Information about the ArchestrA security model implemented in the

Galaxy is not saved with an export, even if you select Export All... If the
ArchestrA security role for an object does not exist when it gets imported, it is
placed in the “Default” group.

Importing Selected Objects into a Galaxy

Refer to Configuration Utilities User’s Guide (B0750AZ) and Strategy Editor
User’s Guide (B0750AN) for additional information regarding the Control
Software objects.
You can reuse objects from one Galaxy in another Galaxy. This saves you a lot
of time if the objects are already set up in another Galaxy.
Importing instances previously exported from a Galaxy retains previous
associations, when possible, such as assignment, containment, derivation, and
area.
You can import objects from exported .aqPKG files, .aaPKG files, or from an
.aaPDF file. (An .aaPDF file contains the configuration data and
implementation code for one or more base templates. It is created by a
developer using the ArchestrA Object Toolkit.)
Before you start, you cannot have two objects with the same name or more
than one copy of the same version of an object in the same Galaxy. When you
import an object, these conflicts are identified and you can manage them.
To import selected automation objects:
1. Invoke the IDE.
2. From the Galaxy menu, select Import, then select Automation
Object(s)… Then, select a location and select a file that contains exported
objects. (The file extension can be .aqPKG, .aaPKG, or .aaPDF.)
3. Click Open. The Import Preferences dialog box appears.
4. Do the following:
a. In the Object Version Conflict area, select what happens if there is a
conflict in object versions.
• Skip leaves the existing object unchanged.
• Migrate imports the object(s) that have gone through a major version
upgrade. If your Galaxy has not been upgraded and you select
Migrate, the objects are skipped. For more information about
migrating, see the Industrial Application Server Installation Guide.
b. In the Object Name Conflict area, do the following:
Control Editors do not allow two objects in the same Galaxy to have
the same name, and prevent the import of an object that has both the
same name and the same type as one already in the database. For
objects that have the same name but a different type, Control Editors
present two options in the Import Preferences dialog box for resolving
the name conflict.
• Skip does not import the object when a name match exists in the
Galaxy.
• Rename Object in Galaxy renames the existing object by appending
to its current name the string (up to four characters) you type in the
Append to Object Name box. The default value is _old but you can
change it to any 4-character string.

Note Object name conflict resolution only applies to templates and

instances derived from different base templates.
5. Click OK. The import process starts.

6. When the import process is complete, you can start using the objects you
imported.
Importing Script Function Libraries

You can enhance an object’s functionality by attaching a script to it. Some
scripts include functions that depend on external files called script function
libraries. Scripts are included in the object import operation, but you must
import the script function libraries separately.
If you import an object whose script references a script function library that is
not resident in the Galaxy, the imported object is set to Bad state and cannot be
deployed. To correct this, import the script function library and validate the
object. For more information about scripts, see the Industrial Application
Server Scripting Guide.
After You Import

Imported templates are listed in the proper toolset in the Template Toolset as
defined in the object. Imported instances are shown in the Application views.
The following post-import rules apply:
• If a toolset does not exist, it is created.
• If the object belongs to a security group that does not exist, it is associated
with the Default security group.
• If the object belongs to an area that does not exist, it is associated with the
Unassigned Area.
• If the host to which the object is assigned does not exist, it is assigned to
the Unassigned Host.
Note If you import a new version of an existing instance, the new version is
marked as requiring deployment if the existing object is already deployed.

Backing Up the SQL Server Databases

It is highly recommended that you back up all of the IndustrialSQL Server and
SQL databases:
• Before you make any changes to the database, in case you want to return
to the original configuration.
• On a regular schedule, to minimize data loss in the event of a disk failure.
The best way to perform database backups is to set up automatic backups
using SQL Server Management Studio. You should back up your database
at least once a week.
When you perform a database backup, all system tables, user-defined objects
and data are copied to a separate file located on a backup device. Backup
devices include disk drives, flash drives, and tape drives. Backups can be
easily managed using the SQL Server Management Studio.
The master and msdb databases should be on the same backup schedule as the
Runtime database.
Backing Up the IndustrialSQL Server Database

Note Any transactions that are in progress when the backup is performed are
rolled back if that backup is later restored.
To backup the database:

1. Select Start > Programs > Microsoft SQL Server 2005 > SQL Server
Management Studio.
2. In Microsoft SQL Server Management Studio, expand the IndustrialSQL
Server [YourMachineName], and then expand Databases.
3. Right-click on the Runtime database, point to Tasks, and then click Back
Up. The SQL Server Backup dialog box appears.
4. Click the General tab.
5. In the Database box, select Runtime.
6. To use an existing backup device or file for the backup, select the
destination in the Destination window and then click OK to begin the
backup.
Tip For details on a particular backup destination, select the destination in

the list and then click Contents.
7. If you do not have a backup destination defined, click Add to add a new
destination. The Select Backup Destination dialog box appears.
8. Select to back up to either a file or device:
• File name – Type or browse to a path for the location of the backup
file. Be sure that you have enough free disk space to store the backup.
• Backup device – Select an existing backup device or select <New
Backup Device>. The Backup Device Properties dialog box appears.
In the File name box, type a name for the device. As you type the

name, the path for the backup is modified. Verify that the path for the
backup is correct. When you are done, click OK to create the backup
device.
9. Click OK to close the Select Backup Destination dialog box.
10. The newly created backup device now appears in the Destination window
of the SQL Server Backup dialog box. Select the new backup device.
11. Click OK to perform the backup.
You can configure various options for database backups, such as an expiration
date for a backup. You can also schedule automatic backups.
For a complete description of database backup and restoration using SQL
Server Management Studio, including scheduling recommendations and
transaction log backup, see your SQL Server Management Studio
documentation.
Restoring the IndustrialSQL Server Database

When restoring the Runtime data from backup copies, be sure to completely
stop InSQL software, including retrieval. This is done in the System
Management Console under IndustrialSQL Server > IndustrialSQL Server
Group > computer name > Management Console. Right-click Status and
click All Tasks > Shutdown (and disable) InSQL. After the restore, restart in
similar fashion, but with All Tasks/ Enable (allow to run) InSQL.
When you restore a database from backup, any information saved to the
database since the backup was performed is overwritten with the restored
information. All changes to the database since the backup are lost. Also,
any transactions in progress when the backup was performed are rolled back.
To restore the database:
1. In Microsoft SQL Server Management Studio, expand the IndustrialSQL
Server, and then expand Databases.
2. Right-click on the Runtime database, point to All Tasks, and then click
Restore Database. The Restore Database dialog box appears.
4. In the Restore as database list, select the Runtime database.
5. Select Database from the Restore options.
6. In the First backup to restore list, select the desired backup.
7. Click OK. The information is restored.
You can configure various options for database restoration. For more
information on restoring from a backup using SQL Server Management
Studio, see your SQL Server Management Studio documentation.

Backing Up History Data

The Wonderware Historian has four main storage locations referred to as:
• Circular
• Alternate
• Buffer
• Permanent.
These are described in more detail in the online help of the SMC. The paths to
these locations can be configured in the System Management Console under
IndustrialSQL Server > IndustrialSQL Server Group > computer name >
Configuration Editor > Storage > Storage Locations. The circular storage
location must be a local drive on the server machine. The alternate, buffer, and
permanent storage locations can be anywhere on the network, provided that the
ArchestrA service user has full access to those network locations.
The scenario assumed here is that you want to back up the data on the local
hard drive of the Historian server. By default, all the Control Software History
data is stored in “history blocks” in the D:\INSQL\DATA\Circular folder. The
history blocks are folders below this path which have the date included in their
name with this format: Ayymmdd_nnn, e.g., A061123_001. These folders and
files contain all of the real time data being sent to the Wonderware Historian
and can be backed up by manually copying them to a backup device (except
for the currently opened file). The other storage locations can be backed up in
the same way.
Restoring History Data

Restoring History data consists of copying the history blocks you backed up
above to the folders on the hard drive where they came from.
Backing Up the Alarm Message Database

In the Control Software systems, alarm and event history is not in the same
database as the history of real-time points (unlike in the AIM*Historian
software). Refer to the InTouch® Data Management Guide for information
about archiving the InTouch Alarm DB Logger historical alarm message
database. This database contains alarm event messages.
Control HMI and Data

It is important to back up the Control HMI and data. This is described in
Window Construction User’s Guide (B0750AS).

143
C H A P T E R 1 2
Support for Multiple Galaxy

Servers on the Same Instance
of The Foxboro Evo Control
Network
This chapter provides recommendations for supporting a Control Software

system with multiple Galaxy repositories in a single Foxboro Evo
configuration.
Utilizing multiple Galaxies on a single instance of the control network has the
following advantages:
• Multiple smaller databases versus a single large database - Separating
control-related database objects into multiple databases leads to faster
execution times, since there are fewer objects to operate on.
• Negates the need for off-platform Galaxy servers - The off-platform server
increases the Galaxy Repository and ArchestrA throughput since the
server is not also tasked running Control Core Services software. Off-
platform servers require connectivity to all client workstations over a
separate network from the control network. These two networks
complicate the network configuration and troubleshooting.
Utilizing multiple Galaxies requires the user to be diligent in the following
areas:
• Object naming - Name uniqueness for objects is not maintained across
multiple Galaxy databases. This complicates control and template object
naming since the Foxboro Evo system requires compounds and blocks
have unique names. Naming conflicts for these objects arise during
deployment to control processors system and import of data into other
peer Galaxies.
• System Configuration - The resource (TCPIP address, FTMAC address,
Name/Letterbug) allocation performed for the Foxboro Evo system
configuration is not maintained across databases. This chapter will outline
how to mitigate the issues.
Note Creating multiple Galaxies on the same Galaxy Repository server is

NOT recommended.

144 12. Support for Multiple Galaxy Servers on the Same Instance of The Foxboro
Contents
• General Considerations
• System Configuration Using System Definition
• System Configuration Using the Foxboro Evo Control Software
• Runtime Security Considerations/Operations
• Historization
• Alarming
General Considerations
Consider the following:
• Issue: Connecting to different Galaxies from a client workstation.
Connecting to different Galaxies installs the Control Editors software on
the machine multiple times. This can complicate upgrades and
uninstallations and should be avoided.
Control Editors clients are prohibited from connecting to Galaxies of a
different version of the Control Software. But your site's policies should
be expanded to restrict the workstation to only connect to the Galaxy from
which its platform was created and deployed.
• Issue: Compound naming conflicts.
Naming conflicts are not detected or prevented across Galaxies. The CSA
subsystem will prevent duplicate names during deployment, but
Compound names should be chosen carefully to anticipate this issue.
Selecting a prefix, per Galaxy, for compound names will alleviate this
issue.
• Issue: Template naming conflicts.
Naming conflicts are not detected or prevented across Galaxies. If
instances of templates will be used for import/export operations across
Galaxies, the templates may or may not get imported. If the template's
instance will be imported into other Galaxies where there are duplicate
template names, the instance import may fail. Selecting a prefix for all
templates, per Galaxy, will alleviate this issue.

12. Support for Multiple Galaxy Servers on the Same Instance of The Foxboro Evo
System Configuration Using System Definition

Issue: System configuration with multiple Galaxies can create issues with the
commit/reconcile process. Resource (TCPIP and FTMAC) allocation does not
account for multiple Galaxies and duplicate resources may/will be utilized.
To avoid this use the following information.
The system configuration created by SysDef can be used in the Control
Software system. The SysDef System Configuration data can be imported into
a Control Software BulkData object. Then the BulkData object can be used to
generate the desired configuration in the Control Software system.
In a multi-Galaxy configuration, when System Definition is used as the
configuration tool, follow this workflow:
Initial configuration distribution:
• Select a workstation that will be the “master” System Configuration
machine. Configure System Configuration via SysDef on that machine.
• Perform Commit/Reconcile operations from SysDef on the “master”
machine.
• Export the SysDef system configuration via the “Standard Export
Diskette” process.
Figure 12-1. SysDef Standard Export Diskette

• For each Galaxy -

• Create a new BulkData object (BDO) in each Galaxy. This requires
the user to visit a client machine that is designated to connect to each
Galaxy.
• Import the “Standard Export Diskette” output into the newly created
BDO.
• For each BDO only bulk generate the objects needed for control
configuration in that Galaxy.
• For Alarming device configuration, all workstations may also be
generated.
Modification Configuration distribution:
• Make modifications at the “master” workstation via SysDef.
• Export the SysDef system configuration via the “Standard Export
Diskette” process.
• For each Galaxy -
• The user must visit a client machine that is designated to connect to
the Galaxy.
• Import the “Standard Export Diskette” output into the BDO replacing
the old information.
• For each BDO bulk generate only the objects with changes or
additions.
• For Alarming device configuration, only generate added workstations
as needed.
Note If your system has any hardware that the Control Software does not
support, you must use SysDef software to configure this unsupported
hardware; for example, configuring the TCP/IP and FTMAC addresses for this
hardware. This is an issue with multi-Galaxy systems since resource allocation
configuration and maintenance is more difficult on these systems.
System Configuration Using the Foxboro Evo

Control Software
Issue: System configuration with multiple Galaxies can create issues with the
commit/reconcile process. Resource (TCPIP and FTMAC) allocation does not
account for multiple Galaxies and duplicate resources may/will be utilized.
To avoid this use the following information.
System configuration performed in the Control Software system relies on the
following workflow:
Designate a “Master” system. This system should be able to maintain all
hardware objects in the control network. It can be a standalone machine that
will only be used for System Configuration. This system will be used for all
System Configuration operations (maintenance, commit, reconcile, and so
forth).

Initial System Configuration:

• The configuration maintenance is performed via the BulkData Object
(BDO) on the Master Galaxy.
• Export the BDO from the master Galaxy using the Object context menu
Export > Objects feature.
• For each Galaxy station:
a. Import the BDO into the target Galaxy using the Main Menu >
Galaxy > Import > Objects feature.
b. Bulk generate, from the system configuration BDO, the objects
needed for control configuration in that Galaxy.
c. For Alarm device configuration, workstations would also need to be
generated.
Maintenance of System Configuration:
• Make modifications on the “Master” system to the BDO
• Export the BDO from the “Master” Galaxy.
• For each Galaxy machine:
a. Import the BDO into the target Galaxy.
b. Bulk generate only those object that have been changed or added,
from the system configuration BDO.
c. For Alarm device configuration, workstations may also need to be
generated.

Runtime Security Considerations/Operations

The Runtime security is controlled/configured by the Control Editors.
Issue: Multi-Galaxy security configuration fails since a client machine only receives
security settings from the platform’s originating Galaxy. All other Galaxies’
security information will not be received and therefore the other Galaxies’
configured control objects will not have security limitations.
Description: The only functionality available to manage runtime security, in a multi-
Galaxy configuration, is via XML file. The Sync Server has the ability to
configure security via an XML file. It reads the XML file and distributes the
contained security information. It distributes to all machines that have
platforms deployed from that Galaxy.
The user would create an XML Document for security configuration that
would include all Compounds and Tags for the configuration. This file would
then be imported via the GalaxySync Service Utility on each Galaxy. The
utility is found via Program Files > Invensys > InFusion Access >
InFusion SyncService Utility:
Details on editing/constructing this XML file can be found in the Access

Manager User’s Guide (B0750AD).
The user must configure, in the Control Editors, all parameters to have
security of “Operate”. The security subsystem defaults parameter security to
“Operate”. The Sync Server therefore will ignore any parameter set to
“Operate” and therefore deploys none of these settings.
If at any time the Refresh History/Security utility is run from the IDE, this
process will need to be run again. The Refresh History/Security utility deletes
all entries from the security database and subsequently rebuilds it from the
Galaxy’s database. However, the process will also delete all security data
from other Galaxies added via the script.

Historization
Historian information being collected on multiple collecting workstations can
be routed to a central Historian. Configuring the History Application object to
reference the central Historian may require the Central Historian's IP address if
the Historian is off-platform (not on the control network).
This is required due to a network name resolution issue. If the workstation’s
“host” files are configured with the Historian’s IP address/Netname, the
netname can be used. If not, the IP address must be used.
Alarming
There are no issues with Alarm configuration as long as the workstations being
used are bulk generated or the workstations being used as alarm destinations
are present in the Galaxy (via BulkGen, for example). If the workstations used
for Alarm destinations are not present, the user may manually enter this value.
In order to simplify the Alarm destination process, the user may create
Compound templates. The alarm destinations can be configured at the template
level and propagated to the instances. This is especially helpful if workstations
are manually entered.


151
C H A P T E R 1 3
Using Direct Access for

Strategy Template
Distribution
Direct Access provides a facility to create a command file that contains all the
Direct Access instructions to recreate selected object(s). This facility can be
used, with some user intervention, to make updates to these objects after they
have been recreated in a remote Galaxy Repository. This chapter provides
procedures and examples of this process.
Contents
• Overview
• Running Direct Access
• Exporting to a Command File
• Added Control Blocks, Declarations
• Deleted I/A Blocks, Declarations
• I/A Block Parameter Changes
• Nested Strategies
• Validating the Update
• For More Information
Overview
The general philosophy for the procedures is as follows:
• A Primary Galaxy maintains all templates, which is where they are
managed and edited. The Primary Galaxy owns the templates.
• One or more Satellite Galaxies contain the distributed and updated
templates. These Satellite Galaxies can create instances of these templates,
but updates are to be distributed from the Primary Galaxy.
• The first distribution of the templates to Satellite Galaxies is done via
Export > Automation Object from within the Control Editors Galaxy
menu.

152 13. Using Direct Access for Strategy Template Distribution
• When updates are made to templates in the Primary Galaxy, the

procedures described in this document are used to distribute the updates to
the Satellite Galaxies.
The overview of the update distribution procedure is:
• Using Direct Access, the template in the Primary Galaxy is exported to a
Command File.
• The template in the Satellite Galaxy is exported to a Command File.
• The two command files are compared.
• Command differences are manually extracted to a new Direct Access
Command File.
• The differences Command File is executed on the Satellite Galaxy to
perform the update.
Running Direct Access

For detailed instructions on Direct Access execution, refer to the Scripting with
Direct Access User’s Guide (B0750BM). A brief summary is provided here.
The Direct Access executable, DirectAccess.exe, commonly resides in
D:\Program Files\Archestra\framework\bin\Invensys on
Foxboro Evo systems.
Executing this program displays the following dialog which allows for
execution of XML command scripts.
Figure 13-1. Direct Access Display
The following table provides an explanation of the pull-down menus, fields

and buttons on the Direct Access display.
Table 13-1. Direct Access Display Components
Pull-down Menu Description

Node Station name of the Galaxy Repository
Galaxy Name of the Galaxy Repository

13. Using Direct Access for Strategy Template Distribution 153
Table 13-1. Direct Access Display Components (Continued)
Fields Description
UserName Login name of the user, if security is enabled
Password User password if security is enabled
Buttons Description
File Name of the file containing Direct Access
commands to be executed. Click
to browse for the file.
Execute Processes the commands in the selected file.
Close Closes the dialog.
There is also a command line version of Direct Access called
DirectAccess_Cmd.exe that can be used in batch files.
Refer to the Scripting with Direct Access User’s Guide
(B0750BM) for details.
The general format for a Direct Access command file is as follows:
<?xml version="1.0" encoding="utf-8"?>
<DirectAccess>
<Command attribute1="value1" attribute2="value2" />
</DirectAccess>
The steps to execute a DirectAccess script are:
1. Execute DirectAccess.exe.
2. From the Direct Access dialog, select or enter the node hosting the
Galaxy.
3. Select the Galaxy.
4. Enter UserName/Password if Security is enabled for this Galaxy.
5. Select the Script to run by invoking the file browser.
6. Click Execute.

Exporting to a Command File

To begin the process of merging templates, one must first export the template
to be updated. The command file to do this export is shown in Figure 13-2.
Figure 13-2. Sample Export Command File
The strategy being exported for this sample is shown in Figure 13-3:
Figure 13-3. Sample Strategy Template

Figure 13-4 is an edited sample of the type of output you will get from
executing the script in Figure 13-2. This shows a partial content of what would
be in the file Stratgy_001.xml.
Figure 13-4. Sample Generated Command File
Following is a description of the components of this generated file:

Line 1 - Create Strategy Command. This is the create command generated
for the top level strategy template exported.
Lines 2,4,11 - Create Block Commands. These create the blocks contained
within the top level strategy template and nested strategy template.
Lines 3,5,12 - Update Attribute Commands. These set block parameter
values.
Line 6 - Create Connection Command. Creates a connection between
block parameters.
Lines 7,8,13,14 - Create / Update Declaration Commands. These create
and set the values of the Strategy's input and output declarations.
Lines 9,10 - Create and assign contained strategy template commands.
These commands create the nested strategy template.
Lines 15-22 - Update Execution Order Commands. These commands set
the execution order for the blocks.
The export script from Figure 13-2 is run on both the Primary and Satellite
Galaxies producing output files that will be compared to show differences
between the templates.
The following subsections describe the types of differences that may be
encountered.

Added Control Blocks, Declarations

The command files in Figure 13-5 show the differences that one would expect
to see after blocks and declarations were added to the strategy template in the
Primary Galaxy. The left side shows the added blocks and declarations from
the Primary Galaxy versus the output from the Satellite Galaxy containing the
original version of the strategy template.
Figure 13-5. Command File Comparison after Additions
In Figure 13-5 you can see the differences between the newly exported
template from the Primary Galaxy (left) and the original export from the
Satellite Galaxy (right).
Lines 4-5,13-14,19-20,23-24 represent two added blocks and two added I/O
declarations. Lines 29,33 show the new blocks added to the overall execution
order.
To make the Direct Access script for execution in Satellite Galaxies, extract the
lines from the export file that represent the new additions and extract the entire
execution order command set.

Figure 13-6. Extracted Updates to Run in Satellite Galaxies
This command file can now be run in every Satellite Galaxy to update the
template with the new configuration from the Primary Galaxy.
Deleted Control Blocks, Declarations

to see after blocks and declarations were deleted from the strategy template in
the Primary Galaxy. The left side shows no entries for the deleted blocks and
declarations from the Primary Galaxy versus the output from the Satellite
Galaxy containing the original version of the strategy template.

Figure 13-7. Command File Comparison after Deletions
The first thing you should notice is that this is the mirror image of the situation
when blocks and declarations were added to the strategy template. This time
the Satellite Galaxy has the extra Create commands.
Lines 4-5,13-14,19-20,23-24 represent two blocks and two I/O declarations to
be removed. Lines 29,33 show the blocks still in the execution order.
Create lines from the export file that represent the blocks and declarations to be
removed. In this case, you do not need to extract the Update commands or the
Execution Order commands because you will be deleting these components.
Figure 13-8 shows what was extracted.
Figure 13-8. Extracted Create Commands from Satellite Galaxy Output

We now convert the Create commands to Delete commands as shown in

Figure 13-9.
Figure 13-9. Delete Commands to Run in Satellite Galaxies
Control Block Parameter Changes

to see after block parameters and declarations were modified in the strategy
template in the Primary Galaxy. The left side shows the modifications from the
Primary Galaxy versus the output from the Satellite Galaxy containing the
original version of the strategy template.
Figure 13-10. Command File Comparison after Modifications
lines from the export file that represent the modifications as shown in
Figure 13-11.

Figure 13-11. Extracted Updates to Run in Satellite Galaxies
Nested Strategies
Adding or deleting nested strategies is done in a similar way to adding or
deleting blocks. The command files in Figure 13-12 show the differences that
one would expect to see after a nested strategy is deleted in the Primary
Galaxy.
Figure 13-12. Command File Comparison after Nested Strategy Deletion
Satellite Galaxy (right). The commands to create the nested strategy no longer
exist in the command file from the Primary Galaxy. So, here you must perform
the same type of edits you did for deleted blocks.
Create line only for the strategy. In this case, you do not need to extract the
Update commands or the Execution Order commands or the block Create

commands because we will be deleting these components. Figure 13-13 shows

what is extracted.
Figure 13-13. Figure 13. Extracted Create Commands from Satellite

Galaxy Output
You can now convert the Create command to a Delete command. Converting
nested strategies requires updating the strategy name to include the full path to
the nested template. This means including its parent template name as shown
in Figure 13-14.
Figure 13-14. Figure 14. Delete Commands to Run in Satellite Galaxies
template with the new configuration from the Primary Galaxy. Note that any
delete commands will fail if instances of blocks that are to be deleted are
deployed.
Validating the Update

After any Satellite Galaxy update using the procedures outlined here, the
command file export script shown in Figure 13-2 can be run in the Satellite
Galaxy and compared to the output of the same script run in the Primary
Galaxy. Comparing these files validates that the changes have been properly
made in the Satellite Galaxy.
For More Information

Refer to the Scripting with Direct Access User’s Guide (B0750BM) for
information on Direct Access usage and command reference.


163
C H A P T E R 1 4
Setting up Multiple Galaxy

Communications
This chapter will discuss how the Multiple Galaxy feature can be used with
systems with the Control Software. It will discuss what the issues are and how
to mitigate them. Before using the Multiple Galaxy Communications feature, it
is highly recommended that the “Working with Multiple Galaxies” section, of
the Industrial Application Server User’s Guide, provided as part of the
Wonderware documentation, be fully read and understood.
Contents
• Overview
• Supported Multiple Galaxy Topologies
• Off-Control Network
• How to Pair Galaxies
• Procedure for Pairing Galaxies
• Deployment of ArchestrA Services
• Pairing Off-Control Network Galaxies
• Pairing On-Control Network Galaxies
Overview
ArchestrA System Platform allows multiple Galaxies to be connected or
paired. With paired Galaxies, objects in one Galaxy can be configured to
connect to objects in another Galaxy. IO values deployed in one Galaxy can be
viewed and written to from the runtime environment in the other paired
Galaxy.
This chapter generally discusses how to pair two Galaxies. It is possible to pair
more than two Galaxies, but for communications to work between all galaxies,
each galaxy must be paired with all other galaxies as shown in the following
examples. In Figure 14-1, objects in Galaxy 2 can communicate with objects in
Galaxy 1and 3 but objects in Galaxy 1 cannot communicate with objects in
Galaxy 3.

164 14. Setting up Multiple Galaxy Communications
Figure 14-1. Simple Arrangement with Three Galaxies
Users must also pair Galaxy 1 and 3 together to provide connectivity between
them, as shown in Figure 14-2.
Figure 14-2. Multiple Galaxy Arrangement with All Galaxies Paired
The multiple Galaxy environment uses three tiers of discovery services that
enable connectivity and data exchange between paired Galaxies (Refer to
Figure 14-3.)
Figure 14-3. Multiple Galaxy Communication Services
Station data requests are passed from the local station server to its Local
Galaxy Server. The Local Galaxy Server then passes the request to the remote
Galaxy through the Cross Galaxy Server.

14. Setting up Multiple Galaxy Communications 165
• Local Discovery This is automatically deployed with the

Server ArchestrA Platform to every station in both
Galaxy.
• Local Galaxy Server This is configured and deployed from the IDE
Discovery Server Configurator. This server can
be deployed to any station in the local Galaxy.
For off-control network configuration it can only
be deployed to stations without Control Core
Services software in the Local Galaxy.
• Cross Galaxy Server This is configured and deployed from the IDE
Discovery Server configurator. This server can
be deployed to any station in one of the paired
Galaxies. For off-control network Configuration
it can only be deployed to stations without
Control Core Services software in the either
Galaxy.
The ASB MXDataProvider Services must be deployed to designated Galaxy

and Cross Galaxy Server stations. By default, the GR Node automatically has
the appropriate services deployed. Refer to the refer to the section “Working
with Multiple Galaxies” in the Industrial Application Server User’s Guide,
provided as part of the Wonderware documentation, for instructions on
creating and deploying additional services if the GR Node is not being used as
either the Galaxy or Cross Galaxy Server.
Supported Multiple Galaxy Topologies

There are primarily two network scenarios that are supported with the Control
Software.
• Off-Control Network: All stations of paired Galaxies are deployed
and running on the same secondary off-control network.
• On the Foxboro Evo Control Network: All stations of paired Galaxies
are deployed and running on the same instance of the control network.
Off-Control Network
There are many possible scenarios for connecting multiple Galaxies together.
This section describes connecting a non-Control ArchestrA Galaxy with a
Control Galaxy. The setup in both Galaxies is the same but there are some
constraints for the Control Galaxy.
Key Points:
• All Station platforms in both Galaxies are deployed to the same secondary
off-control network.
• Local Galaxy and Cross Galaxy servers must be deployed to off-control
network workstations.
The GR Node is typically a station without Control Core Services software in
an off-control network configuration. It can be used as a Local and Cross

Galaxy Server. In non-redundant systems, it is better if the GR is not used as

the primary server, as this can lead to lost cross-Galaxy functionality during
GR Node migrations or maintenance downtimes. In redundant systems the GR
is best used as the secondary backup server.
The off-control network is the preferred configuration for the Control Software
with multiple Galaxies. The ArchestrA platforms of all stations are configured
and deployed with the IP Address of the secondary network. To configure a
Control off-control network, the platforms must be deployed to the second off-
control network. Refer to “Off-Platform Foxboro Evo Control Software Server
Considerations” on page 29.
How to Pair Galaxies

It is important to have all paired Galaxies deployed to the same network. The
example in Figure 14-4 shows a standard ArchestrA (non- Control) Galaxy
connected with a basic off-control network Control Galaxy.
Figure 14-4. ArchestrA Galaxy with 1 GR and 2 Clients
Figure 14-5 shows an off-control network Control Galaxy connected with one
off-control network GR and two Foxboro Evo client workstations.

Figure 14-5. Off-Control Network Control Galaxy with an Off-Control

Network GR and Two Foxboro Evo Client Stations

Procedure for Pairing Galaxies

1. Connect all Stations in both Galaxies to the same common network. (See
Figure 14-6.)
Figure 14-6. Standard and Foxboro Evo Control Software Galaxies

Deployed to the Same Off-Control Network
2. Identify which stations will host the Local and cross-Galaxy services
based on the following rules:
• The Local Galaxy Server can be any station without Control Core
Services software in the local Galaxy.
• The Cross Galaxy Server can be any station without Control Core
Services software from either paired Galaxy.
Keeping these rules in mind, you can see that in Figure 12-6 Galaxy 1 has
enough to support the Local and Cross Galaxy Servers without using the
GR Node, and that Galaxy 2 needs an extra station to support a redundant
Local Galaxy Server or to avoid using the GR Node. Figure 12-7 shows a
suggested layout for hosting Local and Cross Galaxy Services on stations
without Control Core Services software for this example.
Note Redundancy is purely optional and is described in Wonderware Tech

Note 368 “Network Setup for AppEngine Redundancy” and Wonderware Tech
Note 401 “Fine-Tuning AppEngine Redundancy Settings”.

Figure 14-7. Plan for Redundant Multiple Galaxy Communication

Servers
3. Configure the ArchestrA Services in both Galaxies.

Services should only be configured after all stations are connected and
deployed to the same common network. Refer to “Working with Multiple
Galaxies” section, of the Industrial Application Server User’s Guide,
provided as part of the Wonderware documentation, for complete details.
a. Configure ArchestrA Services for Galaxy 1:
• Open the ArchestrA IDE on Galaxy 1.
• Browse to Galaxy > Configure > Service Discovery.
• Configure the local and cross-Galaxy primary nodes. See
Figure 14-8.
• If redundancy is required, configure the secondary nodes.

Figure 14-8. Galaxy 1 Service Discovery Configuration
b. Configure ArchestrA Services for Galaxy 2.

• Open ArchestrA IDE on Galaxy 2.
• Browse to Galaxy > Configure > Service Discovery.
• Configure the Local and cross-Galaxy primary nodes (see
Figure 14-9).
• Configure the secondary nodes if redundancy is required.
• Make sure the Cross Galaxy Service is configured with the same
nodes as in the Galaxy 1 configuration.
Note There can only be one Cross Galaxy Server in a Multiple Galaxy
Environment. Make sure the Cross Galaxy Server settings are the same on all
pairings.

Figure 14-9. Galaxy 2 Service Discovery Configuration
4. Create and deploy new ArchestrA Services (if needed). Refer to

“Deployment of ArchestrA Services” on page 173.
5. Enable Galaxy Pairing.
Note Both Galaxies must have Multi-Galaxy Pairing enabled and a remote
connection passphrase must be configured.
a. Open the ArchestrA IDE.

b. Browse to Galaxy > Configure > Multi-Galaxy. Refer to

Figure 14-10.
Figure 14-10. Multi-Galaxy Configuration Dialog Box
c. Check Enable Remote Pairing.

d. Set the Remote Connection Passphrase.
e. Click OK.
f. Repeat On Galaxy 2.
Note The passphrase must be identical in both Galaxies
6. Pair the Galaxies together
Note Galaxies can be paired when all previous steps are complete.
a. Open ArchestrA IDE on the GR Node of Galaxy 1.

b. Open the Multi-Galaxy Configuration dialog. Refer to Figure 14-10.
c. Press plus button under Paired Galaxies to create a new pairing.This
opens the Remote Pairing Dialog box. Refer to Figure 14-11.

Figure 14-11. Remote Pairing Dialog Box
d. Enter the off-control network IP address of the GR node in Galaxy 2.

e. Set passphrase and click OK to pair the Galaxies.
f. The name of the Galaxy2 will appear in the Galaxy repository list of
the Multi-Galaxy configuration dialog box when the pairing is
successful.
Deployment of ArchestrA Services

To use stations other than the GR Node, new ArchestrA Services must be
created, modified and deployed to each station that is hosting the Multiple
Galaxy Services. Please refer to the “Working with ArchestrA Services”
section, of the Industrial Application Server User’s Guide, provided as part of
the Wonderware documentation, for complete details.
Note By default only the GR Node has deployed running Services.
Note One set of ArchestrA Services are automatically deployed to the GR

Node during installation. If desired, these services can be deployed to other
stations. Additional services can also be created and deployed to improve
performance.

There are three ASB services:
• ASBGRBrowsingService Handles Tag Browsing between

paired Galaxies
• ASBMXDataProviderService Handles runtime data between paired

Galaxies.This service can impact
system resources. To manage possible
performance issues refer to the
“Enhancing Multi-Galaxy
Performance” section of the
Industrial Application Server User’s
Guide, provided as part of the
Wonderware documentation.
• ASBAuthenticationService Handles runtime security
authentication Between paired
Galaxies.
1. Create new ArchestrA Services:

a. Open ArchestrA IDE.
b. Browse to Galaxy >Configure >ArchestrA > Services. See
Figure 14-12 below.
Figure 14-12. Configure ArchestrA Services Dialog Box
c. Select the Nodes tab and click on the plus icon in the toolbar.
d. Add the workstation IDs (refer to "Figure 14-13. Galaxy 1 non-GR
Nodes Added" on page 175).

Figure 14-13. Galaxy 1 non-GR Nodes Added
e. Select the Services tab. See Figure 14-14.

f. On the left pane, right- click on each service and select Create to
create services for each station.
Figure 14-14. Galaxy 1 Service Created for non-GR Nodes
g. On the left pane, right-click the new service instance and select
Check-out.
h. Change the Port ID to avoid port conflicts. Refer to Figure 14-15.

i. Check the node where the service will be deployed in the assignment
pane. Refer to “Configuring ArchestrA Service TCP Ports” in the
Industrial Application Server User’s Guide, provided as part of the
Wonderware documentation and to Figure 14-15.
Figure 14-15. Example Configure Service Dialog Box
j. Select the Update tab to set the assignment

k. On the left pane, right-click on the service and select Check-In to
complete and save the settings.
l. On the left pane, right-click on the service instance and select Deploy.
Pairing Off-Control Network Galaxies

The process is exactly as described in the previous section. See Figure 14-16
for typical service host and station layouts.
1. Deploy all platforms to a common off-control network.
2. Add stations without Control Core Services software to host Discovery
Servers (if needed).
3. Create and deploy ArchestrA services (if needed)
4. Configure local and Cross Galaxy Servers.
5. Enable multi-Galaxy pairing.
6. Pair the Galaxies.

Figure 14-16. Two Control Galaxies Paired on Off-Control Network
Pairing On-Control Network Galaxies

This process is exactly as described in previous sections with one exception:
There is no restriction to deploy Multiple Galaxy Services to stations without
Control Core Services software.
There are no network card conflicts. All ArchestrA communications and
Foxboro Evo communications are on the same instance of the control network.
The procedure is the same as with any other multiple Galaxy environment. See
Figure 12-17.
1. Deploy all Platforms to the common instance of the control network.
a. Connect and deploy the standard Galaxy platforms to the I/A control
network IP Address.
2. Create and deploy ArchestrA Services (if needed).
a. There is no restriction for deploying to only workstations without
Control Core Services software. In a configuration on the control
network, there are no network conflicts between Foxboro Evo and
ArchestrA communications.
b. Any station in each Galaxy can be used.
3. Configure Local and Cross Galaxy Servers.
a. There is no restriction for deploying to only workstations without
Control Core Services software. In a configuration on the control
network, there are no network conflicts between Foxboro Evo and
ArchestrA communications.
b. All configurations should be to the control network IP addresses.

4. Enable Multi-Galaxy Pairing.

5. Pair the Galaxies.
Figure 14-17. Two Foxboro Evo Control Software Galaxies on the same
I/A Series/Foxboro Evo Instance of The Foxboro Evo
Control Network

179
C H A P T E R 1 5
Foxboro Evo Control

Software Support for
RedundantDIObject
For the Control Software v5.0 and later, the IASeriesIntegrator Device
Integration (DI) object implements support for RedundantDIObject.
RedundantDIObject is a standard ArchestrA object located in the Template
Toolbox under the Device Integration toolset. It provides support for accessing
data through redundant data sources, and monitors and controls the redundant
IASeriesIntegrator DI object at the object level. Only one IASeriesIntegrator
provides control processor data through the RedundantDIObject at a time. The
RedundantDIObject determines which IASeriesIntegrator is active at any
given time. More details on RedundantDIObject can be found in the Industrial
Application Server User’s Guide, provided as part of the Wonderware
documentation.
By default, Control Software creates one DI Object based on the
$IASeriesIntegrator template. This can be used as a Primary DI object. To
create and configure a secondary DI Object:
1. Create an instance from $IASeriesIntegrator, for example: SecondaryDI
2. Configure the SecondaryDI object with the same parameter settings as the
existing DI (primary DI) object
a. Open the editor for the Primary DI Object.
b. Open the editor for the SecondaryDI object.
c. For each attribute listed in the Primary DI Object, review and
configure the same value in the SecondaryDI Object.
d. Save and Close the SecondaryDI Object with the configured settings.
3. Configure the Redundant DI object's primary and backup DI objects by
pointing to the respective DI instances.
Figure 15-1 shows an example of a configuration that uses a
RedundantDIObject to acquire data from a Foxboro Evo system. From the
Template Toolbox, an instance of the RedundantDIObject was created, and
given a name consistent with the Control DI object naming convention:
AWSE00_IADI. This object will be deployed to the platform on workstation
AWSE00. In Figure 15-1, the AWSE10 and AWSE11 platforms have
respectively AWSE10_IADI, and AWSE11_IADI IASeriesIntegrator DI
objects.

180 15. Foxboro Evo Control Software Support for RedundantDIObject
Figure 15-1. Deployment View
The AWSE00_IADI RedundantDIObject is configured to receive data from

two IASeriesIntegrator DI objects. As shown in Figure 15-2, the
AWSE10_IADI object is configured as a Primary DI source. The
AWSE11_IADI is configured as a Backup DI source. The <Default> scan
group is configured as a Common Scan Group.
Figure 15-2. RedundantDIObject Configuration

15. Foxboro Evo Control Software Support for RedundantDIObject 181
Figure 15-3 shows the data flow in a system with a RedundantDIObject. If

AWSE10_IADI becomes unavailable, the RDI AWSE00_IADI object
automatically switches to retrieve data from the backup DI object,
AWSE11_IADI. For more information, refer to the Industrial Application
Server User’s Guide, provided as part of the Wonderware documentation.
Figure 15-3. Data Diagram

182 15. Foxboro Evo Control Software Support for RedundantDIObject

183
C H A P T E R 1 6
Triconex Integration
This chapter gives an overview of the components that comprise the Triconex
Foxboro Evo Process Automation System integration.
Contents
• Overview
• Triconex TSAA Device Integration Object (TSAA DI Object)
• Unified Foxboro Evo System Triconex Configuration
• Triconex Safety Configuration Data
• Importing Triconex Safety Configuration Data
• Triconex Foxboro Evo System Unified Configuration Network
Diagram
Overview
The following components comprise the Triconex Foxboro Evo System
integration. These components provide an integrated approach to configuring
the Control logic, HMI, and Historian tags.
The Safety Template provides a linkage between the Triconex TriStation
configuration and the Foxboro Evo System configuration. The Safety Template
initiates the TriStation editing of the safety configuration and processes the
resulting aliased tags for Foxboro Evo System integration. The Control Editors
Bulk Data Object supports direct import of the Safety Template's aliased safety
tag information into the Control Editors. This alleviates the duplication of
aliased safety tag data entry in both the TriStation and the Foxboro Evo
System.
The TSAA Device Integration (DI) Object provides TriStation aliased tag data
directly to the Control HMI and the Wonderware Historian, without the need to
pass this tag data through the Control Processor. This pathway reduces the
need for the Foxboro Evo System to process safety data.
The System Manager can directly invoke the Triconex® Enhanced Diagnostic
Monitor (EnDM). EnDM is a software program for monitoring the hardware,
communication, and application status of Tricon™, Trident™, and Triconex
General Purpose (Tri-GP) controllers. When selecting a FDSI FBM in System
Manager, the EnDM menu item is available when EnDM is installed.

184 16. Triconex Integration
Triconex TSAA Device Integration Object

(TSAA DI Object)
The Control HMI and Wonderware Historian integrate directly with data from
the TSAA DI Object. The object translates the TSAA protocol into MX,
facilitating the HMI and Historian consuming TriStation runtime data. The
Triconex data that is needed for the HMI or Historian does not need to be
routed through the Foxboro Evo System FDSI pathway. The TSAA DI object
creates a direct pathway from the TriStation to the HMI or Historian.
The TSAA DI object is a standard ArchestrA application object that is
deployed and operates on a workstation.
Figure 16-1. TSAA DI Object
The object reads the TriStation’s Safety configuration data to populate its list
of tags that will be made available to the HMI or historized. The graphic below
depicts the TSAA DI object that has been configured to process the tags listed
in the graphic.

16. Triconex Integration 185
Figure 16-2. TSAA DI Object Configuration
The workstation running the TSAA DI Object must be connected to the

network that carries both the ArchestrA network traffic (on the control network
or off-control network) and the TriStation traffic. These may be the same
network or they may be distinct.
Unified Foxboro Evo System Triconex

Configuration
The Control Editors configuration of the Foxboro Evo System/Triconex
integration allows Safety tags to be directly added to the Bulk Data object so
that the FDSI and block data can be bulk generated.

The Safety Template object interfaces with the Tricon/Trident/Tri-GP station

and extracts the Triconex safety Configuration data for import by the bulk data
object.
Figure 16-3. Safety Templates in the Galaxy
Triconex Safety Configuration Data

Triconex configuration data consists of Tricon/Trident/Tri-GP station data
(Station name, Station type, IP Address, etc.) and associated tag data
(Tagname, alias number, data type, etc.) for the tags defined for that station.
The Safety Template extracts the Triconex configuration data from the
TriStation PT2 or exported XML data and allows the user to select specific
tags for Foxboro Evo System integration. The safety system data is brought
into and stored in the Safety Template. This is an automation object which
represents Triconex stations within System Platform. The Triconex data is
imported to this node and the tags that are to be “exposed” to the Foxboro Evo
System are marked here. This data is then saved within the Safety Node for use
by BulkData. The Safety Templates Foxboro Evo System Configuration dialog
is shown below. It allows the user to individually select tags that the Bulk Data
object will use.

Figure 16-4. Safety Template Foxboro Evo System Configuration

Dialog Box
Importing Triconex Safety Configuration Data

Triconex Safety configuration data is imported into a Bulk Data object via its
import mechanism. The safety data imported consists of general information
about a given Triconex node and aliased tags that are made available to the
Foxboro Evo System.
Figure 16-5. Import Bulk Data Wizard Dialog Box

In order for the Foxboro Evo System system to communicate with the safety
system via FDSI (FBM232/FBM233), the ECBs, Compounds, Strategies, and
Blocks need to be configured properly. Each safety station requires at least one
FDSI and one ECB201 to be configured for communication and one control
block per tag to be configured to get/set data.
This safety data, combined with internal and user-defined formulas, allows the
user to create Bulk Data entries for the FDSIs, Devices, Compounds,
Strategies, and Blocks needed for the Triconex safety system to interact with
the Foxboro Evo System.
Once the entries are made in the Bulk Data object as the result of the import,
they can be Bulk Generated to create the Foxboro Evo System configuration.
Triconex Enhanced Diagnostic Monitor

The Triconex® Enhanced Diagnostic Monitor (EnDM) is a software program
for monitoring the hardware, communication, and application status of
Tricon™, Trident™, and Triconex General Purpose (Tri-GP) controllers.
Figure 16-6. Triconex Enhanced Diagnostic Monitor
When installed on an I/A Series or Foxboro Evo Workstation, Triconex EnDM

will need to use a non-Foxboro Evo control network interface card (NIC) for
its communication to the Triconex node.
If Triconex EnDM is installed on an I/A Series or Foxboro Evo workstation,
Triconex EnDM can be launched directly from System Manager to the
Triconex node corresponding to the configured FDSI FBM232/233 ECB201

object. The ability to launch Triconex EnDM directly from System Manager
requires the following minimum software versions:
• System Manager 2.5
• Triconex EnDM 2.8.0
Note Triconex EnDM can be still used as a standalone application on an

I/A Series or Foxboro Evo workstation even if the above System Manager
and/or Triconex EnDM versions are not met.
If the above minimum software versions are met for System Manager and
Triconex EnDM, then System Manager will display a Triconex Enhanced
Diagnostic Monitor menu pick as part of the Equipment Change actions of an
ECB201 under a FBM232/233 configured for TSAA FDSI Driver.
Triconex Foxboro Evo System Unified

Configuration Network Diagram
The diagram below illustrates a possible configuration that supports the
workflow discussed above, but the workstations can be combined into different
combinations.
Figure 16-7. Example Triconex Foxboro Evo System Unified

Configuration Network


191
C H A P T E R 1 7
Unity Pro Integration
This chapter gives an overview of the components that comprise the Unity Pro
Foxboro Evo Process Automation System integration.
Contents
• Overview
• Unified Control System Unity Pro Configuration
• Unity Pro Configuration Data
• Importing Unity Pro Configuration Data
Overview
The following components comprise the Unity Pro Foxboro Evo Control
System integration. These components provide an integrated approach to
configuring the Control logic, HMI, and Historian tags. See "Figure 17-1.
Unity Pro Deployment - Basic Overview" on page 192 for a basic overview.
The Unity Pro Template provides a link between the Modicon PLC
configuration and the Control System configuration. The Unity Pro Object
Template initiates the extraction of the PLC configuration files and processes
the resulting aliased tags from the extracted data for Control System
integration. The Control Editors Bulk Data Object supports direct import of the
Unity Pro Object Template's aliased tag information into the Control Editors.
This reduces the likelihood of errors that may occur during manual
configuration.

192 17. Unity Pro Integration
Figure 17-1. Unity Pro Deployment - Basic Overview
Unified Control System Unity Pro Configuration

The Control Editors configuration of the Control System/Unity Pro integration
allows Unity Pro tags to be directly added to the Bulk Data object so that the
FDSI and block data can be bulk generated.
The Unity Pro Template object interfaces with the Modicon PLCs and extracts
the Unity Pro configuration data for import by the bulk data object.
Figure 17-2. Unity Pro Object Templates in the Galaxy

17. Unity Pro Integration 193
Unity Pro Configuration Data

Unity Pro configuration data consists of Modicon PLC data (XVM files, STU
files, IP Address, etc.) and associated tag data (Tagname, alias number, data
type, etc.) for the tags defined for that PLC.
The Unity Pro Template extracts the Unity Pro configuration data from the
PLC project or exported XML data and allows the user to select specific tags
for Foxboro Evo System integration. The Unity Pro configuration data is
brought into and stored in the Unity Pro Object Template. This is an
automation object which represents Modicon PLCs within the ArchestrA
platform. The PLC configuration data is imported to this node and the tags that
are to be “shared” with the Control System are marked here. This data is then
saved within the Unity Pro Node for use by BulkData. The Unity Pro Object
Template Foxboro Evo System Configuration dialog is shown below. It allows
you to individually select tags that the Bulk Data object will use.
Figure 17-3. Unity Pro Object Template Foxboro Evo System

Configuration Dialog Box
Importing Unity Pro Configuration Data

Unity Pro configuration data is imported into a Bulk Data object via its import
mechanism. The configuration data imported consists of general information
about a given Unity Pro node and aliased tags that are made available to the
Control System.

194 17. Unity Pro Integration
Figure 17-4. Import Bulk Data Wizard Dialog Box
In order for the control system to communicate via FDSI (FBM232/FBM233),

the ECBs, Compounds, Strategies, and Blocks need to be configured properly.
Each controller requires at least one FDSI and one ECB201 to be configured
for communication and one control block per tag to be configured to get/set
data. During the import of the Unity Pro object, this configuration data
combined with internal and user-defined formulas allows you to create Bulk
Data entries for the FDSIs, Devices, Compounds, Strategies, and Blocks. Once
the entries are made in the Bulk Data object as the result of the import, they can
be bulk generated to create the control block configuration.

195
C H A P T E R 1 8
Asset Condition Monitor -

Additional Considerations
Contents
• Condition Monitor Runtime Application Objects
• Changing Passwords for User Accounts for SQL Replication
• Configuring Device Condition Severity Mapping
• Asset Condition Monitor Uninstallation
• Backing Up Condition Monitor Databases
Condition Monitor Runtime Application Objects

When a Condition Monitor runtime application object is deployed to
WinPlatform hosted by a workstation that does not have Asset Condition
Monitor installed, the following error message is logged in SMC:
"Asset Condition Monitor is not installed for <fieldbus protocol> on
<workstationname>". <Runtime application object name> cannot start
execution."
The message will be logged in SMC once every 24 hours. The Condition
Monitor Runtime Application object will be deployed but device conditions
will not be generated.
You must perform the following steps to clear the error:
1. Undeploy Asset Management Application Engine (_AppAM) instance
with 'Cascade Deploy' and 'Include Redundant Partner' options enabled if
redundancy is setup.
2. Install Asset Condition monitor on the workstation
3. Redeploy the Asset Management Application Engine instance.
When runtime application objects are deployed to a System Platform hosted by
a workstation where SQL Replication has not been configured, the following
warning message is logged in SMC:
"If Replication is not configured, Configure Replication from Galaxy
Configurator. Replication needs to be configured on GR and Client
machines with Asset Condition Monitor. Before configuring Replication
Un-deploy Asset Management AppEngine with "Cascade Deploy" and

196 18. Asset Condition Monitor - Additional Considerations
"Include Redundant Partner" options enabled. After Replication

Configuration redeploy the AppEngine."
You must perform the following steps to clear the error:
1. Undeploy Asset Management Application Engine instance with 'Cascade
Deploy' and 'Include Redundant Partner' options enabled if redundancy is
setup
2. Configure Replication from Configurator on the Galaxy Server.
3. Configure Replication from Configurator on the Client system.
4. Redeploy the Asset Management Application Engine instance.
Changing Passwords for User Accounts for

SQL Replication
If the password is changed for the user account used for replication, you must
run Replication Configuration on the Galaxy server, otherwise there will be a
replication failure.
Refer to Asset Condition Monitor Installation Guide (B0750CR) for details on
how to configure replication.
The following section lists failure scenarios if replication configurator is not
run after a password change, and the recovery steps.
Adding a New Asset Condition Monitor Client

After Password Change
If Asset Condition Monitor is installed on a client workstation after the
password is changed for the user account used by Condition Monitoring for
configuring SQL replication, a warning message will appear in the
Configurator indicating “Invalid Login Credentials”. You must perform the
following steps to correct the error:
1. Configure Replication from Configurator on the Galaxy Server providing
the new password.
2. Configure Replication from Configurator on the Client workstation.
Restarting the Galaxy Server After a Password

Change
If the Galaxy Server is restarted after a password change the Windows
Application Event Log on the Galaxy Server will indicate an error message for
replication failure:

18. Asset Condition Monitor - Additional Considerations 197
Figure 18-1. Replication Failure Error Message
You must configure replication from the Configurator on the Galaxy Server
and provide the new password to clear the error messages.
Restarting the Client Workstation After a

Password Change
If a client workstation is restarted after password change the Windows
Application Event Log on the Galaxy Server will indicate an error message for
replication failure as shown in "Figure 18-1. Replication Failure Error
Message" on page 197.
Perform the following steps to configure replication and clear the error
messages:
1. Configure replication from Configurator on the Galaxy Server, providing
the new password.
2. Configure replication from Configurator on the client workstation.
Configuring Device Condition Severity

Mapping
Every device condition is associated with a severity level of
Failure/Function_Check/Out of Specification/Maintenance. Each Severity
level is mapped to a numeric value such that highest severity level has the
lowest numeric value. The mapping can be configured using
'DeviceConditionPriorities.xml' which is installed on Galaxy server under
\\<GalaxyServerName>\aaFileRepository\IAMS folder.
The default priorities in the configuration file are as indicated below:

Severity (NAMUR
category) Value
FAILURE 201
FUNCTION_CHECK 202
OUT_OF_SPECIFICATI 203
ON
MAINTENANCE 204
NORMAL 205
The content of DeviceConditionPriorities.xml is as follows:

<DeviceConditionPriorities>
<FAILURE>201</FAILURE>
<FUNCTION_CHECK>202</FUNCTION_CHECK>
<OUT_OF_SPECIFICATION>203</OUT_OF_SPECIFICATION>
<MAINTENANCE>204</MAINTENANCE>
<NORMAL>205</NORMAL>
</DeviceConditionPriorities>
When updating the XML, only the values are to be updated. Each severity
must have a different value with the highest severity having the lowest value.
After updating the 'DeviceConditionPriorities.xml' with new values, device
severity settings in Control HMI Framer must also be updated to reflect the
correct priority and color for the device messages in the Device Condition
panel in Control HMI.
The Device Severity Mapping section in the Framer And Alarm Management
Users Guide (B0750AR) describes how to configure the alarm priority
mapping to be used in the Control HMI Device Condition Panel.
If you are a Maintenance Response Center user, then stop the
MRCEvoConditionAdapter service before modifying the file and restart the
service after the file is modified.
Here is the order in which the change needs to happen:
1. Modify the device severity mapping in the Framer and redeploy the
control HMI instances
2. Stop the MRCEvoConditionAdapter service (only MRC users).
3. Modify the DeviceConditionPriorities.xml file
4. Start the MRCEvoConditionAdapter service (only MRC users).
Asset Condition Monitor Uninstallation

You must manually undeploy all Condition Monitor Runtime Application
Objects for a specific fieldbus protocol before uninstalling Asset Condition

Monitor for the fieldbus protocol. If Runtime Application objects are not
undeployed before uninstalling condition monitor, the deployed objects will
continue to execute with old device condition configuration and the following
error message will be logged in SMC every 24 hours:
"Asset Condition Monitor is not installed on <workstationname>."
Asset Condition Monitor must be uninstalled on all client workstations before
uninstalling on the Galaxy Server.
Asset Condition Monitor must be uninstalled before uninstalling Field Device
Manager.
Backing Up Condition Monitor Databases

Backing up the database for Condition Monitor configuration involves:
• Backing up the IAMSMasterDB
• Backing up the individual databases under the System Database
To back up the IAMSMasterDB:
1. Invoke the SQL Server Management Studio from Start > Programs >
Microsoft SQL Server 2008 > SQL Server Management Studio and
connect to the main database with [Machine Name].
2. Expand Databases under [Machine Name].
3. Right-click on the IAMSMasterDB database, point to Tasks, and then
click BackUp. The SQL Server Backup dialog box appears.
4. Click the General tab. The Database box will show IAMSMasterDB.
5. To use an existing backup device or file for the backup, select the
destination in the Destination window and then click OK to begin the
backup. By default, the destination is set to the backup folder of the SQL
Server installation.
6. If you want to use a new destination:
a. Click Add to add a new destination. The Select Backup Destination
dialog box appears. Select to back up to a file:
b. File name - Type or browse to a path for the location of the backup
file. Be sure that you have enough free disk space to store the backup.
Provide the file name as IAMSMasterDB.bak.
c. Click OK to close the Select Backup Destination dialog box.
d. The new destination file with path appears in the Destination window
of the SQL Server Backup dialog box.
e. Click OK to perform the backup.
To back up the System Databases:
Repeat the above steps to backup the distribution, master, model, and MSDB
databases. These databases are under Databases > System Databases. Provide
the backup file names matching the database names.

Restoring Condition Monitor Database

IAMSMasterDB must be restored after restoring the Galaxy in order to
synchronize the device condition monitor configuration data in the
IAMSMasterDB with the device objects in the Galaxy.
Before starting the restore process, make sure the database is not in use by the
replication agents or the aaGR process, otherwise the backup will show an
error message indicating database in use.
1. Stop the GR process by opening a command prompt and running the
command:
Net stop aaGR
2. Stop the SQL agent by following below steps
a. Select Start > Programs > Microsoft SQL Server 2008 > SQL Server
Management Studio and connect to the main database with [Machine
Name].
b. Right click on SQL Server Agent and click Stop.
Restoring IAMSMasterDB Database

1. Expand Databases under [Machine Name].
2. Right-click on the IAMSMasterDB database, point to Tasks, and then
click Restore Database. The SQL Server Backup dialog box appears.
4. In the Destination for Restore, make sure IAMSMasterDB is selected as
the database to restore.
5. In the Source for Restore, select From Device and click the browse
button. This will bring up the Specify Backup dialog box.
6. In the Specify Backup dialog box, click Add to browse to the backup
location and select the backup file.
7. Click OK to close the Specify Backup dialog box.
8. The backup appears in the Select Backup to Restore window. Check the
restore checkbox.
9. Click the Options tab.
10. Under the Restore options, check the “Oevrwrite the existing database”
and “Preserve the replication settings” options.
11. Click OK to restore the IAMSMasterDB database.
Restoring System Databases

Repeat the above steps to restore the distribution, model, and MSDB databases
under system databases.

Post-Restore Operations
In the SQL Management Studio:
1. Start SQL Agent by right-clicking on SQL Agent and clicking Start. This
should start all the jobs under SQL Agent.
2. Perform the following steps to reinitialize all publications and
subscriptions:
a. Navigate to [Machine Name] > Replication > Local publications.
b. Right-click on each publication and click “Reinitialize All
Subscriptions”.
c. The Reinitialize Subscriptions dialog box will appear. Check the box
for “Generate the new snapshot now”.
d. Click Mark for Reinitialization.
The data in IAMSClientDB is now synchronized with IAMSMasterDB.
Note The following error will appear under the current SQL log and
Windows Event Viewer after restoring the IAMSMasterDB if the data is not
replicated to IAMSClientDB:
“Replication-Replication Transaction-LogReader Subsystem: agent [publisher

name] failed. The process could not execute ‘sp-repldone/sp-replcounters’ on
[system name].”
Subscriptions have to be reinitialized to replicate data from IAMSMasterDB to

IAMSClientDB. To open the current SQL log in SQL Management Studio,
navigate to: [System Name] > Management > SQL Server Logs
In Archestra IDE
It is necessary to perform the below mentioned post restore operations from
IDE in order to synchronise the condition monitor runtime application objects
with the IAMSMasterDB.
1. If new areas were created after the Galaxy backup was made and
assignment of devices was done to these areas, the restore will result in
some orphan alarms being generated by the devices under this area in
Control HMI. To clean up alarms generated from these orphan
areas/runtime application objects, it is necessary to undeploy the AppAM
application engine hosting the areas/application objects and redeploy from
IDE. This will result in removal of all orphan runtime application objects
running under the engine.
2. If new devices were added under existing areas/new device condition
monitoring configuration was done after the backup was made, they will
not be removed after Galaxy restore. To synchronize the devices under the
area, you must undeploy the application objects and redeploy from IDE.
This will result in all alarms from orphan conditions/devices to RTN and
bring the entire system synchronized.


203
A P P E N D I X A
Multi Monitor Setup for

InFusion View 1.x
InFusion v2.x and later versions of the Control Software support multiple
monitors with default OS multi-desktop settings. These systems do not require
the desktop to be in the SPANNED or STRETCHED mode. These systems will
use the existing video drivers that come installed on the workstations and do
not require additional drivers to be installed. Additional drivers are required,
however, for InFusion 1.x system configurations. Refer to the following tables
for more details:
Table A-1. InFusion 2.x, FCS v3.x-v4.x, and Foxboro Evo Control
Software v5.0 or Later
Style Manufacturer Action

P90/P91/P92 All Styles No driver required.
H90/H91/H92
Table A-2. InFusion 1.x
Style Manufacturer Action

P92 below Style F Rev A Dell 340, 360, 370 Follow instructions in
this chapter to install
special InFusion video
driver.
P92 Style F or newer Dell 380 or newer *No driver required.
Includes Dell PW380,
PW390, T3400, T3500
Gen I, T3500 Gen II
P90/P91 Style C or below Dell PE2800/2850 Follow instructions in
Dell 2900/2950 Gen 1 this chapter to install
special InFusion video
driver.
P90/P91 Style D or newer Dell 2900/2950 Gen 1 *No driver required.
H90/H91/H92 All Styles *No driver required.
* For instructions on setting up a SPANNED or STRETCHED desktop mode, refer to the video
setup instructions in the Hardware and Software Specific Instructions document for Model P9x or
H9x that comes with each workstation.

204 A. Multi Monitor Setup for InFusion View 1.x
This chapter gives procedures for setting up multiple monitors on workstations

that are running InFusion 1.x software and require special video drivers to
support SPAN Mode. This chapter also gives instructions for setting up multi-
monitor stations running InFusion 2.x, FCS v3.x-4.x, the Control Software
v5.0 or later.
Contents
• Multi Monitor Setup for InFusion View 1.x Overview
• Installing the Multi-Monitor Driver on Windows XP Workstations
• Installing the Multi-Monitor Driver on Windows Server 2003 Servers
Multi Monitor Setup for InFusion View 1.x

Overview
On Foxboro Evo Control Workstations (hereinafter referred to as Foxboro Evo
Workstation) with multiple monitors, the InFusion View 1.x application can be
configured to span across all monitors. With the workstation in SPAN mode,
all monitors on the workstation behave as a single monitor. This is the required
setting for multi-monitors with the InFusion View 1.x application.
This functionality requires that an updated graphics driver be installed on some
older workstations. The steps for doing this are different for the Windows XP
and Windows Server 2003 operating systems, and are provided in separate
sections below.
Note If the InFusion View 1.x application is only to be displayed on a single

monitor, it is not necessary to install the updated graphics driver. If it is
installed, do not configure the driver to use the STRETCHED mode.
Installing the Multi-Monitor Driver on

Windows XP Workstations
Perform the following steps to install the multi-monitor driver on a
Windows XP workstation:
1. Exit from the InFusion View, if it is running.
2. The updated graphics driver is located on the InFusion Software
Installation Primary CD. However, when the Primary CD is placed in the
CD drive, the installation program automatically starts up. Cancel out
of this program.

A. Multi Monitor Setup for InFusion View 1.x 205
3. With the InFusion Installation Primary CD in the CD drive, start Windows

Explorer and navigate to the Drivers directory as shown in the following
figure. Double-click on the file 77.56_win2kxp_english_whql.exe to run
the self-extracting graphics driver installation program.
Figure 18-2. Location of Drivers Directory
4. When the program starts up, click I accept… and then select Next.
Figure 18-3. Licensing Agreement

5. Click Next on the NVIDIA Windows 2000/XP Display Drivers dialog

box.
Figure 18-4. Graphics Driver File Directory
6. The graphics driver installation program starts up. Select Next on the
NVIDIA Windows XP Display Drivers dialog box.
Figure 18-5. InstallShield Wizard for NVIDIA - Initial Screen

7. After the graphics driver installation program is installed, the workstation

must be rebooted. Select No, I will restart my computer later then select
Finish. Reboot the workstation manually using the Ctrl-Alt-Del dialog
box.
Figure 18-6. InstallShield Wizard for NVIDIA - Reboot Options
8. After the workstation reboots, start the nVidia Desktop Manager by

selecting the NVIDIA icon from the taskbar.
9. Select the Desktop Management tab and the Display Wizard… button.

Figure 18-7. nView Desktop Manager - Desktop Management Tab

10. Click Next in the NVIDIA Display Setup Wizard.
Figure 18-8. NVIDIA Display Setup Wizard - Welcome Screen
11. Select Custom setup and then select Next.
Figure 18-9. NVIDIA Display Setup Wizard - Custom Setup

12. Select the monitor that is to be the first monitor in the multi-monitor
configuration. Click Next.
Note Depending on the connected monitors, specific display type

information may not appear on the dialog box.
Figure 18-10. NVIDIA Display Setup Wizard - Primary Display Setting
13. Select Span for the NVIDIA Display Mode. Click Next.
Figure 18-11. NVIDIA Display Setup Wizard - Display Mode Setting

14. Select 1280 x 1024. Click Next.
Figure 18-12. NVIDIA Display Setup Wizard - Display Appearance

Settings
15. Configuration is complete. Right-click on the desktop and select

Properties. Verify the display properties are now set to span. The dialog
box below shows a dual-monitor system in SPAN mode. The screen
resolution should be set to 2560 x 1024.

Figure 18-13. Display Properties - Settings Tab
16. If I/A Series or Control Core Services software is running, the following
dialog box appears. Click No.
Figure 18-14. Display Settings Changed Dialog Box
17. Reboot the workstation.

18. When InFusion starts, the following dialog box appears. Click Yes. The
InFusion View recompiles against the new screen resolution.
Figure 18-15. Screen Resolution Dialog Box

19. When WindowViewer exits, deselect the Terminate InTouch Processes

checkbox and click Continue.
Figure 18-16. Restart Options
20. The WindowMaker application software starts up to recompile the

InTouch Application. Click Yes when asked to recompile the application.
This can take up to 20 minutes or more depending on the size of the
application.
21. When the WindowMaker application software is finished recompiling the
application, exit out of the WindowMaker application software and start
the InFusion View. Use the Start menu or reboot the workstation.
22. To complete the configuration of the InFusion View, follow the procedure
under the topic “Configuration for Multi-monitor Layout” in the Framer
and Alarm Management User’s Guide (B0750AR) document.
Installing the Multi-Monitor Driver on Windows

Server 2003 Servers
This procedure pertains to P91 Servers at Style C or earlier.
For P90 servers and later styles of P91 servers, the updated graphics driver
should be available in the C:\Drivers folder of the server’s hard drive. Refer to
the installation instructions in the Hardware and Software Specific Instructions
for Model P9x document that came with the server hardware to install this
driver if it is not already installed. However, even for these servers, if you want
the Control HMI to use multiple monitors, it will be necessary to put the driver
in the STRETCHED mode after the driver is installed. To do this, perform the
procedure below starting with Step 14.
Note If the Control Editors are only to be displayed on a single monitor, it is

not necessary to install the updated graphics driver. If it is installed, do not
configure the driver to use the STRETCHED mode.
Note If this driver is not installed and the card has been installed on the
workstation as a single head, the Galaxy Preparation utility will fail unless the
card is removed.

If the multi-monitor graphics card is being installed for the first time, follow
the installation instructions in the Hardware and Software Specific Instructions
for Model P91 (B0700CQ) document that accompanied the server hardware
before performing the following procedure.
Perform the following steps to install the multi-monitor driver on a
Windows Server 2003 server which will have the Control Software installed on
it.
1. Exit from the I/A Series, if it is running.
2. If the I/A Series software is running, turn it off using the Fox applet in the
Control Panel.
3. If a Matrox® display driver is already installed, uninstall it using the
Add/Remove applet in the Control Panel.
4. Reboot if you have turned off I/A Series/Control Core Services software
or uninstalled a display driver.
5. The required Matrox driver is located on the Control Software installation
media. However, when the media is placed in the CD drive, the Control
Software installation program will automatically start up. Cancel out of
this program.
6. With the Control Software installation media in the CD drive, start
Windows Explorer and navigate to the Drivers directory. Double-click on
the file vxp2K_204_00_179_se_u.exe to run the self-extracting graphics
driver installation program.
The following window appears:
Figure 18-17. Matrox Display Driver Initial Installation Screen

7. Click Next. The following window appears.
Figure 18-18. Matrox Display Driver Selection
Figure 18-19. Ready to Install the Matrox Display Driver

Figure 18-20. Confirmation of Hardware Installation
10. Click Continue Anyway. When the installation is completed, the

following window should appear.
Figure 18-21. Matrox Display Driver Installation Details

11. Click Next. The following window should appear.
Figure 18-22. Driver Installation Complete
12. Deselect the Restart computer option. Click Finish.

13. Reboot the server manually using the Ctrl-Alt-Del dialog box.
14. After the server reboots, start the Matrox PowerDesk-SE program by
single-clicking on the Matrox icon in the system tray and selecting Multi-
Display Setup… in the menu that pops up. The following window should
appear.
Figure 18-23. Configuring the Matrox Display Options

15. Select Use advanced Matrox display controls and Stretched mode and
2x1 for the desktop to span two horizontal monitors (or 1x2 for two
vertical monitors). Also, be sure to change the Color palette to 16-bit
color. Click OK. The desktop should be spanned across the two monitors
and the following window will appear.
Figure 18-24. Confirming Matrox Display Option Changes
16. Click Yes.

17. Right-click the mouse over any blank area on the desktop and select
Properties. Select the Settings tab and verify that the resolution is set to
2560 by 1024 pixels as shown in the following window.
Figure 18-25. Verifying Screen Resolution

18. Click the Advanced button. Select the Troubleshoot tab and move the
Hardware acceleration slider all the way to “Full” as shown here:
Figure 18-26. Setting the Hardware Acceleration to Full
19. If the I/A Series software has been turned off, turn it back on using the Fox
applet in the Control Panel.
20. Reboot the workstation (using Ctrl-Alt-Del).
21. When the Control Editors start, the following dialog box will be displayed.
Click Yes. The Control HMI will be recompiled against the new screen
resolution.
Figure 18-27. Updating Control HMI for a New Screen Resolution
22. When WindowViewer exits, deselect the Terminate InTouch Processes

checkbox and click Continue.
23. The WindowMaker application software will start up to recompile the

Control HMI. Click Yes when asked to recompile the application. This can
take up to 20 minutes or more depending on the size of the application.
24. When WindowMaker software is finished recompiling the application,
exit out of WindowMaker and start the Control HMI. Use the Start menu
or reboot the workstation.
25. To complete the configuration of the Control Editors, follow the procedure
under the topic “Configuration for Multi-monitor Layout” in the Framer
and Alarm Management User’s Guide (B0750AR) document.

Invensys Systems, Inc.
38 Neponset Avenue
Foxborough, MA 02035-2037
United States of America
www.schneider-electric.com
Global Customer Support

Inside U.S.: 1-866-746-6477
Outside U.S.: 1-508-549-2424
Website: https://pasupport.schneider-electric.com

Control Software Deployment Guide: Foxboro Evo Process Automation System

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Control Software Deployment Guide: Foxboro Evo Process Automation System

Caricato da

Copyright:

Formati disponibili

Foxboro Evo™

Process Automation System

Control Software Deployment

The information in this documentation is subject to change without

© 2007-2016 Schneider Electric. All Rights Reserved.

CHAPTER 1: General Concepts .........................1

CHAPTER 2: Sizing and Performance...............7

Control Software Deployment Guide – B0750BA Rev Z

CHAPTER 3: Historizing Data ..........................45

CHAPTER 4: Security .......................................49

CHAPTER 5: Galaxy Sync Service ..................83

Control Software Deployment Guide – B0750BA Rev Z

CHAPTER 6: Terminal Services and Remote

CHAPTER 7: Managed Control HMI

CHAPTER 8: Remote Desktop Using InTouch

CHAPTER 9: Multi Monitor Setup for InTouch....

CHAPTER 10: Configuration and Installation

Control Software Deployment Guide – B0750BA Rev Z

Migrating Configuration Data from Existing

CHAPTER 11: Backing Up and Restoring

CHAPTER 12: Support for Multiple Galaxy

Control Software Deployment Guide – B0750BA Rev Z

CHAPTER 13: Using Direct Access for

CHAPTER 14: Setting up Multiple Galaxy

CHAPTER 15: Foxboro Evo Control

CHAPTER 16: Triconex Integration ...............183

CHAPTER 17: Unity Pro Integration ..............191

Control Software Deployment Guide – B0750BA Rev Z

Importing Unity Pro Configuration Data ........................................193

CHAPTER 18: Asset Condition Monitor -

APPENDIX A: Multi Monitor Setup for InFusion

Control Software Deployment Guide – B0750BA Rev Z

Before You Begin

About This Book

Where to Get More Information

Control Software Deployment Guide – B0750BA Rev Z

Related Wonderware Documentation

Foxboro Evo Documentation

Installation and Getting Started

Control Software Deployment Guide – B0750BA Rev Z

• Sequence Block SFC Editor User’s Guide (B0750AM)

End-user Graphical User Interface Configuration and

Control Software Deployment Guide – B0750BA Rev Z

DA Server Data Access Server

Control Software Deployment Guide – B0750BA Rev Z

NAD Network Application Development. This refers to the InTouch mechanism

Control Software Deployment Guide – B0750BA Rev Z

Control Software Deployment Guide – B0750BA Rev Z

This chapter gives an overview of general concepts of a system with the

Overview of Foxboro Evo Control Software

Control Software Deployment Guide – B0750BA Rev Z

• Wonderware Historian – The data Historian based on SQL software.

Comparison between I/A Series and Foxboro Evo

Foxboro Evo Control

Control Software Deployment Guide – B0750BA Rev Z

Foxboro Evo Control Software Components*

Annunciator Messages Control Compound System

Commit SFC and

Control Software Deployment Guide – B0750BA Rev Z

FOUNDATION fieldbus Objects

Control Software Deployment Guide – B0750BA Rev Z

I/A Series Browser

Control Software Deployment Guide – B0750BA Rev Z