Ias 2 0 Revc Gold Manual

W O N D E R W A R E
T R A I N I N G
Training Manual
Revision C
June 2005
Part Number 05-2056
Industrial
Application Server
2.0 Course
INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

2004 by Invensys Systems, Inc. All rights reserved. No part of this document may be reproduced, stored in
or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording or otherwise), or for any purpose, without the express written permission of Invensys
Systems, Inc. Except where noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places and events depicted herein are fictitious and no association with any real
company, organization, product, domain name, e-mail address, logo, person, place or event is intended or
should be inferred.
Invensys and the author(s) assume no responsibility for errors or omissions and no liability is assumed for
damages resulting from the use of the information contained herein. Use of the Invensys software described
in this document is subject to the terms of the applicable Wonderware Corporation or Invensys Systems, Inc.,
license. These terms include provisions that limit your rights such as use restrictions, disclaimers of
warranties and limitations of Wonderware and Invensys liability. A copy of the applicable license will be
displayed upon initial installation of the software. If a copy of the license is not displayed or you require an
additional copy of the license, you may obtain one from Invensys' Wonderware business unit upon request by
calling 1.949.727.3200 or by sending an e-mail to support@wonderware.com.
Invensys; Wonderware; ActiveFactory; ArchestrA; DT Analyst; FactorySuite; FactorySuite A2; InBatch;
InControl; IndustrialSQL Server; InTouch; InTrack; QI Analyst; SCADAlarm; SuiteLink; SuiteVoyager;
WindowMaker; WindowViewer; WonderWorld; Every system in your plant, working in concert; the Visualize,
Analyze, Optimize symbols; SPCPro and Visualize, Analyze, Optimize are trademarks or service marks of
Invensys plc, its subsidiaries and affiliated companies. All other brands and product or service names may be
the trademarks or service marks of their respective owners.
(rev. 0105)
Table of Contents
Table of Contents
Module 1
Introduction .................................................................................1-1
Section 1 Course Introduction......................................................................... 1-3
Section 2 ArchestrA ...................................................................................... 1-13
Section 3 IAS System Requirements............................................................ 1-21
Section 4 Architectural Overview .................................................................. 1-23
Section 5 Installation and Licensing.............................................................. 1-35
Module 2
Application Planning and the Plant Model ...............................2-1

Section 1 Plant Modeling ................................................................................ 2-3
Section 2 Object Oriented vs. Tag Based Supervisory Control ...................... 2-9
Module 3
The Galaxy ...................................................................................3-1

Section 1 The Galaxy...................................................................................... 3-3
Lab 1 Creating a Galaxy........................................................................... 3-5
Section 2 Tour of the IDE.............................................................................. 3-11
Section 3 Facility Modeling ........................................................................... 3-31
Lab 2 Facility Model ............................................................................... 3-33
Section 4 Objects and Object Instances ....................................................... 3-37
Lab 3 Create and Deploy a Platform ...................................................... 3-43
Lab 4 Create and Deploy an Engine ...................................................... 3-55
Module 4
Modeling Equipment...................................................................4-1
Section 1 Application Objects ......................................................................... 4-3
Lab 5 DeviceIntegration Object ................................................................ 4-7
Lab 6 Analog Devices ............................................................................ 4-19
Lab 7 DiscreteDevices - Valve Instance................................................. 4-29
Module 5
Complex Object Modeling Extending the Objects ................5-1

Section 1 Object Relationships ....................................................................... 5-5
Lab 8 Modeling Complex Objects ............................................................ 5-9
Section 2 Object Change Control and Propagation ...................................... 5-37
Lab 9 Change Control and Propagation ................................................. 5-39
Section 3 UDAs and Scripts.......................................................................... 5-49
Lab 10 Object Reuse.............................................................................. 5-79
Lab 11 Averager ..................................................................................... 5-87
Section 4 Extensions and Output Functionality ............................................ 5-99
Lab 12 Extensions ................................................................................ 5-103
Section 5 Additional Application Objects .................................................... 5-109
Module 6
Alarming and History..................................................................6-1

Section 1 Alarming.......................................................................................... 6-3
Lab 13 Alarming ....................................................................................... 6-9
Section 2 Network Account Utility ................................................................. 6-23
Section 3 Historization .................................................................................. 6-33
Lab 14 Historization................................................................................ 6-37
Module 7
Securing the Galaxy....................................................................7-1

Section 1 Security Overview ........................................................................... 7-3
Lab 15 Application Server Security Settings .......................................... 7-13
Module 8
Galaxy Maintenance....................................................................8-1
Industrial Application Server 2.0 Course
iii
iv

Section 1 Exporting and Importing a Galaxy ................................................... 8-3
Lab 16 Exporting/Importing CSV Files.................................................... 8-13
Section 2 System Management Console (SMC) ........................................... 8-29
Module 9
DAServers and DI Objects ......................................................... 9-1

Section 1 DAServers ....................................................................................... 9-3
Section 2 DI Objects........................................................................................ 9-7
Section 3 FactorySuite Gateway ..................................................................... 9-9
Lab 17 FactorySuite Gateway................................................................ 9-15
Section 4 Intermittent Network Configuration ................................................ 9-25
Module 10
Visualization.............................................................................. 10-1
Section 1 Visualization .................................................................................. 10-3
Lab 18 Properties Visualization ............................................................ 10-13
Lab 19 Alarm Connectivity in InTouch .................................................. 10-33
Lab 20 Tank System Visualization........................................................ 10-39
Lab 21 InTouch Tag Connectivity ......................................................... 10-67
Module 11
Multi-Node Galaxies ................................................................. 11-1

Section 1 Redundancy and Redundant DI Objects ....................................... 11-3
Lab 22 Redundancy ............................................................................. 11-19
Section 2 Converting to a Multi User Galaxy............................................... 11-33
Lab 23 Convert to Network Environment ............................................. 11-37
Appendix A ArchestrA Licensing ..................................................................A-1

Appendix B FactorySuite Support Tools ......................................................B-1
Appendix C Industrial Application Server Glossary ....................................C-1
Wonderware Training
Module 1
Introduction
Section 1 Course Introduction
1-3
Section 2 ArchestrA
1-13
Section 3 IAS System Requirements
1-21
Section 4 Architectural Overview
1-23
Section 5 Installation and Licensing
1-35
1-2
Module 1 Introduction
Module Objective
z
Be introduced to the FactorySuite Industrial Application Server and understand its

architecture, environment, and requirements for installation and licensing.
Wonderware Training

Section Objective
This section will familiarize you with the objectives and agenda for the FactorySuite Industrial
Application Server course as well as the key basics of the Industrial Application Server.
Course Overview
FactorySuite Industrial Application Server is a 4-day instructor led course designed to teach the
basic functionality of the Wonderware FactorySuite Industrial Application Server. The purpose of
this course is to give students the knowledge necessary to develop applications for their specific
environment.
The following modules are included:
Module 2 Application Planning and the Plant Model
Module 3 The Galaxy
Module 4 Modeling Equipment
Module 5 Complex Object Modeling Extending the Objects
Module 6 Alarming and History
Module 7 Securing the Galaxy
Module 8 Galaxy Maintenance
Module 9 DAServers and DI Objects
Module 10 Visualization
Module 11 Multi Node Galaxies
Main Course Objective

Upon completion of this course, students should be able to:
z
Understand how to develop an application using the Industrial Application Server and
Work with objects that have been created using the Industrial Application Server Toolkit.
Prerequisites
It is expected that prior to taking this course the student will have a basic knowledge of InTouch.
1-3
1-4
Agenda
Introduction
z
What is ArchestrA?
Bootstrap
Platform
LMX, NMX
Toolkits
What is Industrial Application Server?
Engine
Objects
DI
System(Area)
Application
Analog, Discrete
Why use ArchestrA?
Global Name Space(example)
Advanced Communications Capabilities(example)
Pervasive, Flexible Security(example)
True Object Methodology
Single point of configuration(alarms,history,security)
Reuse of engineering effort
Change control/propagation
When to use?
Number of I/O
Architecture
Installation / Licensing
z
Hardware Recommendations
Software Recommendations
Licensing Scheme
FS Compatibility

Plant Modeling
z
The need for a project workflow
understanding area devices
identification of functional requirements
naming conventions
Wonderware Training

Object Oriented vs. Tag Based Supervisory Control
z
The difference between Object Oriented development process and Tag Based
development process
Types of objects
object-oriented tools in manufacturing applications
Plant Model for Developing (IAS) Course Application
Module 3 The Galaxy

Industrial Application Server IDE
z
What is a Galaxy Repository?
Selecting a GR Node
What is a Galaxy?
Selecting a Galaxy
Deleting a Galaxy
Creating a Galaxy
Instructor lead view Galaxy db after create
Single User / Multi User Environment
Lab 1 - Creating a Galaxy

Tour of the IDE
z
Tool bars
Views
Import/Export
Configure Security
Change User
Change Galaxy
Set User Preferences
Right Click Object Information
Attributes
Errors/Warnings
Cross Reference
Change Log
Facility Modeling
z
Areas as Logical Groupings of Process
Alarms
Events
Devices as Instances
Develop device list
Common Devices as Templates
Impose standards at this level
Lab 2 Facility Model
1-5
1-6
Objects and Object Instances
z
Creating an Instance (Platform Object)
Check Out/ Check In
Information / Warning Icons
Deploying / Options - User Preferences
Platform Properties
Object Viewer
Engine Properties
Area Properties
Device Integration Properties (OPC & SL Proxy)
Lab 3 Create and Deploy a Platform

Lab 4 Create and Deploy an Engine
Module 4 - Modeling Equipment

Application Objects
z
Analog Device Properties
Discrete Device Properties
Lab 5 DeviceIntegration Object

Lab 6 Analog Devices
Lab 7 Discrete Devices Valve Instance
Module 5 Complex Object Modeling - Extending the Objects

Object Relationships
z
Area (Alarm Modeling)
Host (Resource Modeling)
Containment (Process Modeling)
Templates
Extending & Enhancing Your Object Models

z
User Defined Attributes
Data Types Supported
Extensions
Input Reference
Output Reference
Alarm
Historize
Lab 8 Modeling Complex Objects

Object Change Control and Propagation
z
Template Property Locking
Propagate on check in
Wonderware Training

Lab 9 Change Control and Propagation
Object Reuse
z
Keywords for Reuse
Me
My Host
My Container
My Area
Contained Names
UDAs and Scripts

z
Script Types
Data Types Supported
Dim Types
Aliases
Property Browser
Function Browser
Type Browser
Import/Export
Lab 10 Object Reuse

Lab 11 Averager
Extensions and Output Functionality
Lab 12 Extensions
Additional Application Objects

Alarming
z
What is an Alarm/Event?
What types of things are Alarmed?
How does ArchestrA handle Alarms?
Platforms alarm to Application Server
Lab 13 Alarming
Network Account Utility
Historization
z
How does ArchestrA Historize?
Engines Historize
InSQL MDAS
InSQL node does not require any ArchestrA software
Pushed at the engines scan rate
1-7
1-8
Lab 14 Historization

Security Models
z
None
Galaxy
OS User
OS Group
Securing the IDE and SMC

z
Creating Roles Assigning Permissions
Creating Users Assigning to Roles
Securing the Objects in Runtime

z
Creating Security Groups
Assigning Roles to Group Access
Lab 15 Application Server Security Settings

Lab 16 Authentication

Exporting/Importing a Galaxy
z
As an aaPackage (Object)
As a CSV (Galaxy Dump)
Lab 17 Exporting/Importing CSV Files

Using the System Management Console (SMC)
z
Starting / Stopping Engines and Platforms
Backing up the Galaxy Database
The ArchestrA Logger
Network Account Utility
Lab 18 SMC Operation

DAServers
z
Configuration
Component Architecture
DAServer Characteristics
DI Objects
z
DI Network Objects
Wonderware Training

z
DI Device Objects
FactorySuite Gateway
z
Integration to Third Party Applications
Other Connectivity Tools
Lab 19 FactorySuite Gateway

Intermittent Network Configuration
Visualization
z
InTouch Integration
Tag Browser
Data Type Support
LMX, NMX Client abstraction layer
Lab 20 Properties Visualization

Lab 21 Alarm Connectivity in InTouch
Lab 22 Tank System Visualization
Lab 23 InTouch Tag Connectivity
Module 11 Multi-Node Galaxies

Redundancy and Redundant DI Objects
Lab 24 Redundancy
Converting to a Multi-User Galaxy
z
Export Tank Template
Undeploying all Existing Platforms
Pointing the IDE to a remote GR Node
Deploy Platforms from remote GR
Import Tanks and Deploy
Check State of Platform using SMC
Lab 25 Convert to Network Environment
1-9
1-10
FactorySuite A2 Products
The next generation of Wonderware FactorySuite product line, FactorySuite A2 products are
the first to take advantage of the power and performance of Invensys' new ArchestrA plant
automation and information software architecture. The following FactorySuite A2 products offer
increased functionality and flexibility and extensive connectivity:
z
Industrial Application Server platform for system-wide, real-time data acquisition, alarm
and event management, centralized security, data manipulation, remote deployment, and
collaborative engineering
InTouch human-machine interface (HMI) software for process visualization and control
IndustrialSQL Server plant data historian
InTrack resource and WIP tracking software
InBatch flexible batch management software
InControl real-time control software
DT Analyst equipment downtime tracking and performance management software
SuiteVoyager industrial portal software for Internet/intranet visualization and content

management
InTouch for Terminal Services software for remote hosting of InTouch applications
Data Access Servers offering a library of hundreds of I/O servers and DAServers
Wonderware Training

z
QI Analyst using real-time and historical data to monitor, analyze, and predict potentially
harmful process variations, allowing for online adjustments for improved production quality
and consistency
ActiveFactory for accelerating and improving decision-making at all levels within the
plant through a suite of advanced data analysis clients that leverage data stored in
IndustrialSQL Server
SCADAlarm event notification software for real-time alarm notification, data acquisition,
and remote control from telecommunication devices to industrial automation software
systems
This industry-leading toolset features the robust, best-of-breed software modules that help users
effectively develop and manage automation applications for continuous, discrete, process, hybrid
and batch manufacturing environments. In addition to the usual outstanding features and benefits
offered by our traditional FactorySuite modules, the FactorySuite A2 product line takes full
advantage of Invensys new, ground-breaking Architecture by ArchestrA. The FactorySuite A2
product line is yet another example of how Wonderware powers intelligent plant decisions in real
time.
Industrial Application Server Framework

ArchestrA provides an infrastructure for simplifying the development, deployment, lifecycle
maintenance, and administration of distributed automation applications.
The supervisory control and manufacturing information environment is served by a variety of
systems, including (HMI), Distributed Control Systems (DCS), Supervisory Control and Data
Acquisition systems (SCADA), Process Information Management systems (PIM), Manufacturing
Execution Systems (MES), batch and recipe management systems, and advanced control/
simulation systems.
ArchestrA leverages advanced software technologies to fill the gap between ERP systems and the
control systems. This architecture provides the following:
z
Framework: supports common services and a core set of system objects
Domain Objects: are industry-specific objects
Object Development Toolkit: allows 3rd parties to create new domain objects
customized for specific needs
The ArchestrA infrastructure, or Framework, supports core services that are required by most of
the different types of supervisory control and manufacturing information systems mentioned
above. These core services include the following:
z
Integrated development environment
Version management
License management and centralized deployment
System diagnostics and system administration
Internationalization
Data visualization and monitoring
Event based processing, scripting, and calculation capabilities
Alarm and event management, historization, and security
Data acquisition and field device integration
Inter-object communications and name service
1-11
1-12
z
Reporting and ad-hoc query capability
Support for industry standards such as OPC and SQL
The ArchestrA Framework consists of:

z
Configuration and Deployment Related Components: which include the centralized

object repository (called Galaxy Repository), integrated development environment (IDE)
and object deployment services (called Bootstrap). These components are installed just
like any other Windows application. They are required for centralized deployment of the
runtime components.
Runtime Components: which include PCs with core infrastructure (called Platforms), key
software applications (Engines) and objects (Framework Objects) that expose framework
related functionality. These components are centrally deployed and administered.
Wonderware Training
Section 2 ArchestrA
Section 2 ArchestrA
Section Objectives
z
Understand the concept of ArchestrA and how it relates to the manufacturing

environment.
Understand the benefits of migrating to an ArchestrA architectural environment.
Introduction
ArchestrA is a comprehensive plant automation and information architecture designed from the
outset to extend the life of legacy systems by leveraging the latest software technologies.
Offerings built upon this architecture empower decision-makers to achieve their business goals,
without abandoning prior investments in automation systems, production processes or intellectual
property.
ArchestrA's complete approach to industrial architecture significantly reduces a plant's total cost of
ownership through easy installation, operation, modification, maintenance and replication of
automation applications.
In the ArchestrA environment, software applications can be rapidly assembled rather than
programmed. New applications also can be created simply through the reassembly of existing
applications.
The ArchestrA vision is to provide a unified and robust architecture that is the basis for
collaborative production systems in support of industrial enterprises. Its open-development
platform and tools uniquely enable Invensys and third parties such as OEMs, machine builders
and system integrators to build domain knowledge and add significant value to the solutions they
provide. End-users and suppliers will benefit from ArchestrA's unified platform, which enables the
instant integration of application information.
ArchestrA is the comprehensive industrial automation and information architecture that
orchestrates a new way to run or expand older plants more efficiently, and an optimal way to build
new plants.
The Need for ArchestrA

Quality, responsiveness, and cost efficiency have always been necessary for any plant or factory
that wishes to surpass the competition. Today, they are vital for any plant, factory, or enterprise to
survive.
The pace of change accelerates. Product cycles become shorter and more complex. New or
enhanced products must be commercialized at breakneck speed, or risk rapid failure. Such
offerings must also be quickly customizable for use in todays global business spaces. Again, as
these markets grow ever more economically efficient, the choice for manufacturers is between
agility and finality.
Thats why today a variety of computer-based systems are used to operate plants as well as to
improve their efficiency. In most plants, multiple varieties of hardware and software systems
provide machine and process control, information management, and decision support. These
systems enable manufacturers to operate their businesses more effectively and add value to the
raw materials they process. Without these systems, many highly engineered consumer and
industrial products simply would not exist, because of the complexities involved in their
manufacture.
1-13
1-14
Unfortunately, even today, in most plants these systems operate independently. This hinders a
plant managers ability to synchronize and control production and business processes in a realtime environment. In other words, the majority of manufacturers have not successfully integrated
the functionalities of automation/business/information systems into a single, unified infrastructure.
In the past, this has been an expensive and time-consuming process. Those that have
successfully integrated have done so at great cost in terms of money and resources. Moreover,
despite the huge investments made by companies in these systems over the years, managers still
find it difficult to quantify resulting tangible benefits.
The most compelling aspect of the problem now facing manufacturers is that the underlying
technology of these systems is rapidly becoming obsolete. As general technology lifecycles
shorten, manufacturers are pressed to procure and integrate new technologies with everincreasing speed making the ultimate goal of productivity improvement even more difficult to
achieve.
In most plants today, islands of automation within business and manufacturing systems hinder
the plant managers ability to synchronize business processes in real time.
Recognizing this challenge, Invensys has developed a solution, ArchestrA automation and
information architecture (ArchestrA).
A powerful new infrastructure for industrial applications, ArchestrA promises to provide an
information and control superstructure that will increase the productivity of a plants existing
systems, while enabling the plant to easily integrate important new technologies over the longer
term. Building on ArchestrA research and technology, the recently released I/A Series A2
system (I/A Series A2) has taken the first major step toward reducing the risk of automation
obsolescence and protecting manufacturers investments far into the future.
Wonderware Training
Section 2 ArchestrA
Manufacturing Goals
For approximately a decade, manufacturers have been revising business practices, organization
charts, and systems infrastructures to become more market-driven and customer-centric. Their
overall objectives have been straightforward and consistent:
z
Become more responsive to market shifts and the increased competition brought on by
globalization
Develop greater agility and a more collaborative, data-driven environment
Synchronize the manufacturing process with planning and scheduling functions to

optimize enterprise performance
Empower operators with critical information to foster improved plant performance
Utilize existing assets more efficiently to increase production, without the need to expand
the plant or build new capacity
Ensure the greatest possible return on assets, and improve profitability, in the face of
continuing manpower reductions
To achieve these goals, managers know they can no longer simply "invest in technology" and
expect improvements to come about automatically. In fact, millions of dollars have already been
invested with only marginal returns. However, management cannot afford to stand still, because
there are significant rewards to be reaped by those who develop improved responsiveness,
greater agility, and a higher return on assets.
Compounding the problem, many of yesterdays automation and information systems are
beginning to show their age, failing to offer the agility or rapid response that todays producers
require. Acting as a massive anchor, they actually impede the organizations forward progress as
they increasingly require greater amounts of maintenance and the corresponding expansion of
infrastructure support. But the original investment in these systems was so extensive and so
visible to owners and investors that it is understandably difficult to broach the subject of
"bulldozing" and starting over with the latest generation of technology. Further, it means not only
eliminating extensive hardware infrastructure, but also destroying an asset that is even more
valuable the intellectual capital unique to the manufacturing mission.
Synchronization of Systems
Todays collaborative manufacturing environment requires that manufacturers synchronize
automation systems with business/information systems to accomplish total supply chain
management.
To facilitate this collaborative environment, many manufacturers are working toward a rational,
cost-effective solution that does not require enormous investment and allows for the preservation
of as much existing infrastructure as possible. They are preserving, to the maximum extent
feasible, existing investments in hardware and software, as well as in intellectual properties
contained in application-specific software. They are working to synchronize the various
informational elements within the manufacturing domain, namely automation systems, business
systems, and information systems, thereby fulfilling these systems original promise of improved
manufacturing efficiency. They are identifying optimal long-term strategies based on total cost of
ownership.
The pace of change has increased to a point at which it is difficult for manufacturers to execute a
new strategy before market conditions change once again. Todays manufacturer, however, must
have the ability to respond to challenges that are virtually unanticipated. Response times have
now become the cornerstones of manufacturing competitiveness, and will remain so for the
foreseeable future.
1-15
1-16
The challenge has been to develop an architectural infrastructure that optimizes quality, customer
satisfaction, and efficiency of operation, while facilitating quick response and easy reengineering.
And to identify and deploy a plant information superstructure that embraces existing systems while
providing expansion capabilities for the long term.
Such an architectural infrastructure is available through ArchestrA. This allows manufacturers to:
z
Preserve a significant portion of their existing automation and information infrastructures
Integrate and synchronize existing production systems and new applications
Move ahead into the future, confident of shorter project execution times, reduced total cost
of ownership, and a proven, long-term strategy that will remain in a leadership position for
the life of the plant.
ArchestrA Architecture
ArchestrA, developed by Invensys, is a software infrastructure designed to unify combinations of
Invensys, third-party, and customer internal applications, both current and emerging, into a
synchronized, plant-level application model, and to foster their ongoing adaptation and
improvement. It comprises a unique combination of new toolsets and new applications
infrastructure services, allowing the rapid generation of new applications, products, and services.
Because it enables easy upgrades via integration of existing systems with these new technologies,
it offers manufacturers the promise of extending the lifecycle of an entire plants information and
control system infrastructure.
ArchestrA facilitates the next logical extension of enabling software architecture designed to
accommodate emerging technologies and to ease the reuse of engineering from one project to
another. The objective of this unique technology is to dramatically reduce engineering and
maintenance time and expense when a manufacturer must modify or expand his companys
process. Incorporating ArchestrA will considerably reduce the cost and time involved in executing
strategic change.
Wonderware Training
Section 2 ArchestrA
ArchestrA enables manufacturers to synchronize the various informational elements within the
manufacturing domain and supply the information required by business systems in real time.
ArchestrA provides a number of key functions designed to free users from the complexities of
dealing with current underlying technologies. So users require only assembly skills, not
sophisticated programming knowledge, and are able to apply their time to functions in which they
have more expertise. By embedding common application services directly into a common
infrastructure, application engineers can design and reuse solutions that are instantly integrated.
The key elements of the software infrastructure are the following:
z
Common design and development environment
Deployment, scripting, and calculation services
Alarm and event subsystems with reliable delivery
Built-in distributed architecture services for scalability
Integration with various types of field devices
Inter-object communication and name service management
Version management services
Security model services
Centralized license management and deployment services
Centralized system diagnostics and administration
Internationalization of objects and application services
Graphical user interface (GUI) editing services
Automation Information Pyramid

ArchestrA supports all layers of industry standard models. It is the basis for Supervisory,
Production and Plant Intelligence solutions. In addition, it extends functionality across the
enterprise enabling true manufacturing collaboration. The Automation Information Pyramid
illustrates these points. It displays the complete effectiveness of ArchestrA across all levels of the
manufacturing environment:
1. Plant Floor Connectivity
2. Supervisory
3. Production
4. Plant Intelligence
5. Manufacturing Collaboration
The following page illustrates these segments as they relate to the Automation Information
Pyramid.
1-17
1-18
Manufacturing
Collaboration
Plant
Intelligence
Production
Supervisory
Plant Floor
Connectivity
Wonderware Training
Section 2 ArchestrA
Scalability
The Industrial Application Server provides a scalable and integrated architecture to meet the
needs of small, simple applications all the way up to highly challenging manufacturing information
management systems.
The Industrial Application Server resolves the problems associated with scaling automation
applications because there are no limitations on system size and performance issues are easily
addressed through the introduction of new nodes. New workstations and any data points defined
are automatically integrated into the initial application through the plant model. The common
distributed peer-to-peer namespace means that all information is shared between the nodes
without the user having to perform any additional engineering or configuration.
1-19
1-20
Wonderware Training

Section Objectives
z
Understand the necessary system requirements for a successful installation
System Requirements for Industrial Application Server/Galaxy Repository

To run the Application Server, the following hardware and software are recommended.
Software Requirements
FactorySuite A Development seat IDE with Galaxy Repository (Project Database)
z
Microsoft SQL Server 2000 Service Pack 4 and
Microsoft .NET Framework 1.1
Microsoft Internet Explorer 6.0 SP1 and
Microsoft Windows Server 2003 or
Microsoft Windows 2000 Server with Service Pack 4 or
Microsoft Windows 2000 Advanced Server with Service Pack 4
Important! The Microsoft SQL Server login for BUILTIN\Administrators group must be present
and enabled.
FactorySuite A Development seat IDE with no Galaxy Repository (Project Database)
z
Microsoft .NET Framework 1.1 and
Microsoft Windows 2000 Professional with Service Pack 4 or
Microsoft Windows 2000 Advanced Server with Service Pack 4 or
Microsoft Windows XP Professional with Service Pack 2
FactorySuite A Application Server Runtime

z
Hardware Requirements
z
PC with 2 gigahertz (GHz) or higher processor clock speed
1 gigabyte (GB) of RAM or higher (512 MB minimum supported; may limit performance
and some features)
8 gigabytes (GB) of available hard disk space
Super VGA (1024 768) or higher-resolution video adapter and monitor
1-21
1-22
z
CD-ROM or DVD drive
Keyboard and Microsoft Mouse or compatible pointing device
Note:
Support for Windows Server 2003
Industrial Application Server 2.0 leverages the Microsoft operating system, Windows Server 2003.
Version 2.0 of Industrial Application Server has been thoroughly tested on this new OS enabling
the user to immediately take advantage of its functionality.
Wonderware Training

Section Objectives
z
Become familiar with the architecture of ArchestrA under different configurations
Become familiar with the architecture for the Training course
Architectural Overview
Possible architecture configurations that you can create with FactorySuite A2 components include:
z
Peer-to-peer configuration
In a peer-to-peer configuration, there are several nodes sharing data and eventually
running multiple programs on each node. This configuration is intended for medium-sized
applications where the processing requirements of each software component can be
easily handled by the nodes providing the projected performance support.
Client/server configuration
In a client/server configuration, the system is fully distributed. Server components
centralize the data collection and processing and provide data to client stations. This
architecture facilitates the system maintenance, since all of the configuration data resides
in dedicated servers.
Terminal services configuration

FactorySuite A2 leverages Terminal Services technology. Terminal Services provides the
capability to run several sessions of the same InTouch application or different applications
in a Terminal Server. Since no programs are required to be loaded on the client station
accessing the application, the software and hardware requirements for the client node are
minimum.
Note: Industrial Application Server 2.0 has been thoroughly tested and is supported in Domains
implementing DHCP servers.
1-23
1-24
Configuration Components
Before you explore the different architecture topologies that are suitable in a FactorySuite A2
environment, you should understand the role of the main components in the architecture and how
they can be implemented based on requirements and functionality. The main components are:
z
Configuration Database Node
Application Object Server Node
Visualization Node
I/O Server Node
Engineering Station Node
Historian Node
Web Server Node
A Galaxy consists of the whole supervisory control application, which is a complete system
consisting of a single logical namespace and a collection of Platforms, AppEngines, and objects.
The Galaxy defines the namespace in which all components and objects reside.
The following network diagram shows a configuration containing FactorySuite A2 components.
Use this architecture to identify each component required in any of the recommended topologies.
Visualization Node
AppServer
AppServer
Visualization Node
Historian
IO/OPC /DA Server

PLC Network
Wonderware Training
Visualization Node
Engineering Station
Configuration Database
Web Server

Configuration Database Node
The configuration database node consists of the Galaxy Repository (GR). The Galaxy Repository
manages the configuration data associated with one or more Galaxies. This data is stored in
individual databases, one for each Galaxy in the system. Microsoft SQL Server 2000 is the
relational database used to store the data.
Technically, the Galaxy Repository can reside on a dedicated node, an Application Object Server
node, or an engineering station node.
ApplicationObjects, DeviceIntegration Objects (DI Objects), and System Objects are categorized
as Domain Objects. The configuration database node is accessed when an application is created/
modified as the Domain Objects are configured or edited. The Galaxy Repository is also accessed
when objects are deployed/undeployed on any Platform in the Galaxy.
In normal operating conditions, if Application Object Servers do not require access to the
configuration database node, you can combine the configuration database node and engineering
station node on a single computer. The configuration database node must be available for the
Galaxy when any of the Platforms need to access configuration data in the Galaxy Repository.
If you have large distributed applications, as a practical resource, you could install the Galaxy
Repository on a laptop computer and carry it to remote sites in order to maintain applications. To
expedite the process of deploying/undeploying objects and creating and configuring templates,
you could connect the portable configuration database node to the local node via a dedicated LAN
connection.
If the Galaxy Repository is not available on the network, existing objects cannot be deployed or
undeployed to/from any Platform in the Galaxy.
Configuration and run-time components for a configuration database node are described in the
following table:
z
z
z
Integrated Development Environment (IDE)

Galaxy Repository*
Microsoft SQL Server 2000*
Run-Time Components
z
z
Bootstrap (Base installed)

Platform (Deployed)
Application Object Server Node

The Application Object Server provides the processing resources for AppEngines, Areas,
ApplicationObjects, and DeviceIntegration (DI) Objects.
The Application Object Server node requires a Platform to be deployed. The Application Object
Server can also run other objects, such as AppEngines, Areas, DeviceIntegration Objects, and
ApplicationObjects.
Depending on the process requirements and system capabilities, the functionality of an Application
Object Server node can be combined with a visualization node. A peer-to-peer topology takes
advantage of this type of configuration to provide flexibility to the system.
1-25
1-26
Configuration and run-time components for an Application Object Server node are described in the
following table:
z
Run-Time Components
z
z
z
z
z
z

Platform (Deployed)
Application Engine (Deployed)
Areas (Deployed)
ApplicationObjects (Deployed)
DeviceIntegration Objects (Deployed)
Visualization Node
A visualization node is a computer running InTouch 9.0 SP2 or higher on top of a Platform. The
Platform provides for communication with any other Galaxy component via the Microsoft Message
Exchange (MX) protocol.
Configuration and run-time components for a visualization node are described in the following
table:
Run-Time Components
z
z
z

Platform (Deployed)
InTouch 9.0 SP2 or higher OR InTouch View 9.0 SP2 or higher (Base installed)
I/O Server Node

An I/O Server node functions as the data source for the Industrial Application Server system.
Running on this node are I/O data servers that can communicate with external devices.
Communication protocols supported by the system are DDE, SuiteLink, and OPC.
On the Industrial Application Server side, DeviceIntegration Objects manage the communication
between ApplicationObjects and the I/O data servers.
DeviceIntegration Objects require a Platform and an AppEngine to be deployed. These objects
can reside either on the I/O Server node or on any Application Object Server node in the Galaxy. If
the DeviceIntegration Objects run on the I/O Server node, then a Platform is required to
communicate with any other Platform in the Galaxy.
Configuration and run-time components for an I/O Server node are described in the following
table:
z
System Management Console (SMC)
Run-Time Components
z
z
z
z
Wonderware Training

Platform (Deployed)
Application Engine (Deployed)
IO/DA/OPC Server (Deployed)

Engineering Station Node
All of the recommended topologies include a dedicated engineering station for maintenance
purposes. The engineering station node contains an Integrated Development Environment (IDE)
and InTouch WindowMaker. (These development tools are provided with a FactorySuite A2
development package.)
The configuration database could reside on this node. Thus, you could implement any required
changes in the system from the engineering station node using the IDE, which would then access
the local configuration database. This configuration provides you flexibility in maintaining remote
sites, as you can use a laptop computer as the engineering station and configuration database
node and gain access to the Application Object Server node via a LAN connection. If you need to
deploy or undeploy large applications, network traffic in the Galaxy would not be affected.
The engineering station node also hosts the development tools to modify InTouch applications
using WindowMaker.
Configuration and run-time components for an engineering station node are described in the
following table:
z
z
z
IDE
SMC
Run-Time Components
z
InTouch WindowMaker 9.0 SP2 or higher
Historian Node
The historian node is used to run IndustrialSQL Server. IndustrialSQL Server stores all of the
historical data and also provides real-time data to clients such as ActiveFactory, SuiteVoyager, and
so on.
The historian node does not require a Platform. The Application Object Server pushes the data to
be historized to the IndustrialSQL Server using the manual data acquisition service (MDAS).
Note: MDAS uses DCOM to send data to IndustrialSQL Server. For both the MDAS and
IndustrialSQL Server computers, make sure that DCOM is enabled (not blocked) and that TCP/
UDP port 135 is accessible. The port may not be accessible if DCOM has been disabled on either
of the computers or if there is a router between the two computers that is blocking the port.
For most applications, it is recommended that you combine the historical and alarm database on
the same node sharing the data storage system. Configure the alarm system using the Alarm
Logger utility, which creates the appropriate database and tables in Microsoft SQL Server. For
requirements and recommendations for this configuration, see Alarms and Events.
Configuration and run-time components for a historian node are described in the following table:
z
Microsoft SQL Server 2000*
Run-Time Components
z
IndustrialSQL SQL Server 8.0 or higher

(Base installed)
Required component
1-27
1-28
Web Server Node
A web server consisting of SuiteVoyager Server could be included in any Galaxy. You can use the
Win-XML Exporter to convert InTouch windows to XML format, so that SuiteVoyager clients can
access real-time data from the Galaxy.
In order to provide the means for the SuiteVoyager Server to access the Galaxy, a Platform is
required to be deployed on the web server node.
Run-Time Components
z
z
z

Platform (Deployed)
SuiteVoyager 2.0 SP1 or higher (Base installed)
Peer-to-Peer Configuration
A peer-to-peer configuration combines different components on the same computer, allowing the
visualization and Application Object Server functionality to coexist in the same node (called a
workstation).
The following network diagram illustrates the software components and their distribution in the
configuration.
Workstation
Workstation
Historian
Engineering Station
Web Server
IO/DA/OPC Server
PLC Network
Client operating systems such as Windows XP Professional can manage up to 10 simultaneous

active connections with other nodes.If the system is larger than 10 nodes, Windows 2003 Server
must be used for all nodes.
Workstation
In this configuration, the visualization and Application Object Server are combined on the same
node. Both components share the Platform, which handles communication with other nodes in the
Galaxy. The Platform also allows for deployment/undeployment of ApplicationObjects.
Wonderware Training

If you are planning to combine the visualization and Application Object Server on the same node,
you should consider the amount of resources that each component would require to operate. On
the visualization side, consider the number of active tags per window, ActiveX objects displayed,
alarm displays, and history trending. The implementation of features such as these could require a
considerable amount of resources from the computer and may impact the performance of the
Application Object Server running on the same node.
I/O, OPC, and DA Servers

I/O Server applications do not require a Platform. They can reside on either a stand-alone node or
a workstation node. However, DI Objects such as the DDESuiteLinkClient object, OPCClient
object, and InTouchProxy object are required to be deployed to an AppEngine on a Platform.
These generic client objects are not required to be installed on the same node as the data
server(s) they connect to. The objects can connect to the servers locally or remotely.
The DDE SuiteLinkClient object, OPCClient object, and InTouchProxy object are DI Objects that
obtain data from any I/O data server using DDE, SuiteLink, and OPC protocols, as well as data
from InTouch legacy systems. For DAServer-specific objects (for example, ABCIP DINetwork
object, ABTCP DINetwork object, and so on), both the DAServer and corresponding DI Objects
must reside on the same computer hosted by an AppEngine.
The following diagram illustrates the combination of I/O Servers on the workstation node:
Workstation
I/O Server
Workstation
I/O Server
Historian
Engineering Station
Web Server
PLC Network
If you install I/O Servers on separate nodes without the DIObjects on the same computer, you
should use dedicated Network Interface Cards (NICs) to manage the communication between the
I/O Server node and the Application Object Server. This configuration is recommended when a
failover strategy is required at the I/O Server level. For more information, see I/O Server
Redundancy.
Client operating systems such as Windows 2000 Professional and Windows XP can manage up to
10 simultaneous active connections with other nodes. If the system is larger than 10 nodes,
Windows 2000 Server must be used for all nodes.
1-29
1-30
Historian
The IndustrialSQL Server must run on its own computer, collecting historical data from any
workstation in the Galaxy and providing it to client applications.
Engineering Station and Configuration Database

The engineering station node hosts the IDE and InTouch WindowMaker to allow for maintenance
of the Industrial Application Server and InTouch applications.
As a configuration database node, it contains the SQL Server database that stores the
configuration data for the Galaxy.
Web Server
A web server node running SuiteVoyager Server provides real-time and historical data to clients
over the web.
Client/Server Configuration
A client/server configuration includes dedicated computers running Application Object Servers,
while visualization tasks are performed on separate computers. This architecture optimizes
usability, flexibility, scalability, and system reliability.
The client components (represented by the visualization nodes) provide the means to operate the
process with applications that are mainly providing data updates to process graphics. The clients
have a very light load of data to process.
The Application Object Servers share the load of data processing, alarm management,
communication to external devices, security management, and so on.
Wonderware Training

The following network diagram illustrates a client/server configuration:
Visualization Node
AppServer
AppServer
Visualization Node
Historian
Visualization Node
Engineering Station
Web Server
IO/OPC /DA Server

PLC Network
This architecture can be scaled to include a greater number of servers, if required for increased
data processing and a higher load of I/O reads/writes. The number of clients could also be
increased if additional operator stations are needed.
Terminal Services Configuration

You can leverage Terminal Services technology in a FactorySuite A2 architecture. Terminal
Services allows for the communication of thin client computers to a Terminal Server node, where
multiple instances of InTouch applications run simultaneously.
A dedicated Terminal Server node is recommended for this configuration. This node requires the
following software components:
Run-Time Components
z
Platform (Deployed)
Terminal Services for InTouch 9.0 SP2 or higher (Base installed)
The Terminal Server node should be configured in Application Server mode for Terminal Services.
Only one Platform runs in a Terminal Server node, regardless of the number of sessions executed.
However, the number of sessions affects the size of the license for the system.
You should consider different options when using Terminal Services, such as whether to run
Terminal Services on the same node as the Application Object Server or on dedicated computers.
1-31
1-32
Training Architecture
For the purposes of this training class the architecture will initially be structured in a Standalone
configuration. Later in the class the architecture will be modified to reflect a networked
configuration to convey more complex concepts relating to connectivity, exporting objects and
templates and other multi-node environmental considerations (see the following diagrams).
Hardware and Associated Software
Application
Server
Galaxy
Repository
InTouch
Station
Contains
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Contains
Bootstrap
Contains
Bootstrap
InTouch 9.0
Present on
each machine
Standalone Configuration
PLC
Bootstrap
IDE
InTouch 9.0
Wonderware Training
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0

Networked Configuration
In the networked architecture a common Galaxy Repository will be shared between a set of PCs.
It will allow multiple users to simultaneously work on the same application. The architecture is
illustrated in the following diagram.
PLC
Galaxy 1 Node4
G1N4
Galaxy 1 Node3
G1N3
Galaxy 1 Node2
G1N2
Galaxy 1 Node1
G1N1
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Industrial Application
Server and InTouch
Application Object Server ,

Galaxy Repository, and
InTouch
Note: To better facilitate the clarity of individual work in this training environment, because of the
Global Naming Space, ALWAYS preface the object name with your FIRST and LAST initial.
(e.g., if the user is John Burns, Valve would be JBValve)
1-33
1-34
Wonderware Training

Section Objectives
z
Understand the necessary system requirements
Install the product and
Configure the Galaxy.
Installation
Industrial Application Server is the next generation architecture for Supervisory Control and
Manufacturing Information systems. It is an open and extensible system of components based on
a distributed, object-oriented design.
This section describes how to install one or more components of the Industrial Application Server
infrastructure including the main configuration tool, the Integrated Development Environment (or
IDE), and how to configure a Galaxy. Although the installation process is very straight-forward it is
beneficial in illustrating the procedure.
The Industrial Application Server installation routine includes options for installing all components
of the system or just individual ones. These include:
z
Bootstrap
IDE
Galaxy Repository
To begin the Industrial Application Server installation, the CD is inserted into the appropriate CD
drive. The Welcome dialog box will appear.
The Industrial Application Server requires Microsoft .NET Framework. If this has not been
installed on your machine you will see the following prompt for its installation:
Clicking OK will initiate the Microsoft .NET Framework installation.
Once the Microsoft .NET Framework is installed, installation of Industrial Application Server can
continue.
1-35
1-36
If the installation does not auto start, then double click on the Setup.exe file to initiate the install.
Clicking Next to continue the installation causes the Licensing Agreement dialog box to appear.
A printout of the License Agreement is available by clicking Print License. Doing so opens the
License Agreement in Notepad, from which you can print the document.
Selecting the I accept the License Agreement option and clicking Next to accept the terms of the
license agreement causes the Wonderware Industrial Application Server Setup dialog box to
appear.
Wonderware Training
Note the important information provided in the Feature Description box as you select individual
features.
Clicking the icon next to the feature
causes the following options to be presented. The
options presented for the Bootstrap feature are as follows:
The options presented for all other features are as follows:
These options are provided since not all nodes will necessarily have the IDE or the Galaxy
Repository residing locally. The Bootstrap feature, however, is required for all installations.
The default destination is the \Program Files\ArchestrA folder. Clicking the Browse button
allows you to designate a destination target for the installation other than the default location
1-37
1-38
Clicking the Disk Cost button displays the Disk Cost dialog box:
Use the Disk Cost button to determine the best location for the installation, depending on the
space on available drives.
Clicking the Reset button on the Selected Features dialog box changes all screen choices to the
default settings.
Selecting the Installation Guide button will activate the information pertaining to installation and
setup.
Clicking Next to continue initiates the dialog box for verification of the Prerequisites.
If a Prerequisite is not present the following dialog boxes will appear:
Wonderware Training
Once the prerequisites have been satisfied, the Industrial Application Server installation can
continue.
Clicking Next to continue initiates the Install.
1-39
1-40
This dialog is a progress indicator that provides visual and textual information about the file
copying and system configuration activities going on. It also provides a time estimate for finishing
this part of the installation routine.
Wonderware Training

Once the installation is complete the following dialog box appears:
This dialog alerts you that installation has successfully completed.

Observe the status of the Launch Application Server IDE checkbox. If you leave it checked (the
default setting), the IDE is launched immediately.
Clicking the View Readme button will allow you to read the product Readme file.
When the Industrial Application Server opens there will be a prompt to connect to a Galaxy. If an
attempt is made to connect with a Galaxy that was created with an earlier version of Industrial
Application Server the following prompt will appear:
Clicking Yes will allow all the data in the older Galaxy version to automatically be migrated to the
new version.
1-41
1-42
Licensing
Note: A detailed License Guide for the Industrial Application Server is provided as an Appendix to
this manual, see Appendix A, ArchestrA Licensing.
Access to the Galaxy Repository is controlled by a license. If a license-related message is
displayed when you are attempting to open the IDE, you have a problem with your license. This
message may indicate one of the following conditions:
z
No license has been installed.
Your license has expired.
You may have exceeded the licensed I/O count or number of WinPlatforms.
Use the License Utility to correct these problems. Until the problem is resolved, you cannot:
z
Open the IDE.
Connect to existing Galaxies.
Create new Galaxies.
After you have updated your license, you should be able to connect to your Galaxy and open the
IDE with no further problems.
Note: If a license expires while you are using the IDE, you are not allowed to connect to the
Galaxy the next time you open the IDE.
To check your current license, expiration date (if any) and limitations (if any), double-click the
License icon at the bottom of the IDEs Main Window to open the License Information dialog box.
Wonderware Training
The License Information dialog box is comprised of the following options:

z
Galaxy Client Access License group
Number: License number.
Vendor: Name of software vendor.
Product Text: The software name and version number.
Expiry Date: Expiration date for your license.
Notice Text: Information about the software vendor.
Platform group
Current Count: Number of deployed WinPlatforms in your Galaxy.
Max Count: Maximum number of deployed WinPlatforms allowed by your license.
Status: Relationship between the current and maximum WinPlatform count values.
IO Point group
Configured Count: Number of configured I/O points in your Galaxy.
Max Count: Maximum number of configured I/O points allowed by your license.
Status: Relationship between the configured and maximum I/O point count values.
1-43
1-44
Wonderware Training
Module 2
Application Planning and the Plant Model

Section 1 Plant Modeling
2-3
Section 2 Object Oriented vs. Tag Based Supervisory Control
2-9
2-2

Module Objective
z
Understand the concept and need of developing a Plant Model before configuring the
Industrial Application Server
Become familiar with key factors necessary for building successful applications.
Wonderware Training

Section Objectives
z
Understand the need for a project workflow, an understanding of area devices,

identification of functional requirements and naming conventions
Understand the concept of ArchestrA and how it relates to the manufacturing

environment.
Understand the benefits of migrating to an ArchestrA architectural environment.
Introduction
In order to successfully implement a project for the FactorySuite A2 environment, you should start
with careful planning to come up with a working model of your plant or plant area. A six-step
project workflow is provided that describes how to complete different tasks in a logical and
consistent order, so that you minimize the engineering effort.
The project information that you define will become your guide when actually creating your
industrial application using the ArchestrA IDE. The better your project plan, the less time it will take
to create the application, and with fewer mistakes and rework.
Suggested Project Workflow

Just as there are many different criteria for FactorySuite A2 projects, there are many different ways
to design and implement a supervisory and control system. The suggested project workflow is
designed to help you plan and implement your projects. By providing this workflow, we intend to
ease your work and facilitate the completion of the project. You may develop your own workflow
for implementing projects based on your experiences.
The following flow chart summarizes the logical steps to project completion.
Identify Field Devices and Functional Requirements
Define Naming Conventions
Define the Area Model
Plan Templates
Define the Security Model
Define the Deployment Model
2-3
2-4

Before you start this process, you should determine how you want to document the results of your
project planning. One good way is to use a spreadsheet application such as Microsoft Excel to
document the list of devices, the functionality of each device, process areas to which the devices
belong, and so on.
Identifying Field Devices and Functional Requirements

The first step in project planning is to identify the field devices that you want to include in your
application. Field devices include components such as valves, agitators, rakes, pumps,
Proportional-Integral-Derivative (PID) controllers, totalizers, and so on. Some devices are made
up of more base-level devices. For example, a motor is a device that may be part of an agitator or
a pump.
After you have identified all of your field devices, you will then need to determine the functionality
for each.
Identifying Field Devices

When identifying field devices, you should start with your piping and instrumentation diagram
(P&ID). Typically, this diagram shows all of the field devices and illustrates the flow between them.
If you have a good P&ID, the application planning process will take less time and go more
smoothly. You should verify that your P&ID is correct and up-to-date before starting the planning
process.
The following diagram shows a simple P&ID:
Wonderware Training
),&

)9
37

77

),&

)9
'5,9(

/,&

)7

&7

/7

37

)7

)9
)9
'5,9(

&7

The key for this P&ID is as follows:

FIC = Flow controller
PT = Pressure transmitter
TT = Temperature transmitter
FT = Flow transmitter
CT = Concentration transmitter
LT = Level transmitter
LIC = Level controller
FV = Flow valve
Examine each component in your P&ID and identify each basic device that is used. For example,
a simple valve can be a basic device. A motor, however, may be comprised of multiple basic
devices.
Once you have created the complete list, group the devices according to type, such as valves,
pumps, and so on. Consolidate any duplicate devices into common types so that only a list of
unique basic devices remains, and then document them in your project planning worksheet.
Each basic device is represented in the ArchestrA IDE framework as an "object." An instance of an
object must be derived from a defined template. The number of device types in your final list will
help you to determine how many object templates you will need to create for your application. You
can group multiple basic objects to create more complex objects, which is a concept known as
"containment."
Identifying Functional Requirements

For each unique device, you will need to define the functional requirements, which includes:
2-5
2-6

z
Inputs and outputs. How many inputs are required for the device? How many outputs are
required?
Scripting. What scripts will be associated with the device? For example, does the device
require any indirect calculations?
Historization. Are there process values associated with this device that you want to
historize? How often do you want to store the values? Do you want to add change limits
for historization?
Alarms and events. What values require alarms? What values do you want to be logged
as events? (ArchestrA IDE alarms and events provide similar functionality to what is
provided within InTouch.)
Security. Which users do you want to give access to the device? What type of access do
you want to give? For example, you may grant a group of operators read-only access for a
device, but allow read-write access for a supervisor. You can set up different security for
each attribute of a device.
Defining Naming Conventions

The second step in the workflow is to define the naming conventions for templates, instances, and
object attributes. Naming conventions should adhere to:
z
Conventions that you use within your company.
ArchestrA IDE naming restrictions. For example, you might have an instance tagname of:
YY123XV456
with the following attributes:
OLS, CLS, Out, Auto, Man
The following illustration shows how the naming convention in a traditional Human-Machine
Interface (HMI) is different from the naming within ArchestrA IDE:
+0,V
$UFKHVWU$
<<;9?2/6
2/6
<<;9?&/6
&/6
<<;9?2XW
<<;9
2XW
<<;9?$XWR
$XWR
<<;9?0DQ
0DQ
,QGLYLGXDO7DJV
2EMHFW
2EMHFW
$WWULEXWHV
For ArchestrA IDE, references are created using this naming convention:
<objectname>.<attributename>
For example:
YY123XV456.OLS
Wonderware Training
For more
information refer
to the InTouch to
IAS Migration
document

Defining the Area Model
The third step of the project workflow is to define the Area model. An Area is a logical grouping
within your application that represents a portion of the layout of your plant. In a typical
manufacturing plant, you would define the following Areas: Receiving Area, Process Area,
Packaging Area and Dispatch Area. You will need to define and document all of the Areas of your
plant that will be part of your application.
Each object will need to be assigned to a particular Area. When you install the Industrial
Application Server, a single placeholder is created by default, called "Unassigned." Unless you
specify otherwise, all object instances will be assigned to this placeholder location.
The following are a few tips for creating Areas:
z
If you create all of your Areas first, you can easily assign an object instance to the correct
Area if you set that particular Area as the Default Area; otherwise, you will have to move
them out of the unassigned Area later.
It is helpful to create a System Area to which you can assign instances of WinPlatform and
AppEngine objects. WinPlatform and AppEngine objects are used to support
communications for the application, and do not necessarily need to belong to a plantrelated Area or any Area for that matter.
Alarms will be grouped according to Areas.
Areas can be nested.
When building an Area hierarchy, keep in mind that the base Area that is assigned to a Platform
determines how the underlying objects will be deployed. If a plant area (physical location) is going
to contain two computers running AutomationObject Server platforms, then two logical Areas will
have to be created for the one physical plant area.
One approach for creating instances of an object is to create an instance for one Area at a time. If
you use this approach, then mark the Area as the default, so that each instance is automatically
assigned to the selected Area. Before you begin to create instances in another Area, change the
default to the new Area.
A final consideration for constructing Areas is that the various Areas equate to alarm groups. It is
at the Area level that alarm displays can easily be filtered.
Object Templates
A template is an element that contains common configuration parameters for objects that are used
multiple times within a project. Templates are instantiated to represent specific objects within the
application.
For example, you might need multiple instances of a valve within your application, so you would
create a valve template that has all of the required properties. This allows you to define once, and
reuse multiple times. If you change the template, the changes can be propagated to the instances.
You can use simple drag-and-drop within the IDE to create instances from templates.
Additional information on how to actually develop objects using templates is covered in Module 5,
Planning for Object Templates on page 5-5.
2-7
2-8
Wonderware Training

Section Objectives
z
Understand how Object Oriented relates to SCADA
Understand the difference between Object Oriented development process and Tag
Based development process
Introduction
There are several fundamental differences between Object-oriented and traditional Tag based
HMI and SCADA products. The following table illustrates the differences in how various processes
are managed in Object Oriented vs. Tag Based systems.
Process
Object Oriented
Tag Based
Structure
Hierarchical
Flat
Graphics Development
Done Last
Done Early
Background Process
Developed in Objects
Developed in Tags
Promotion of Standards
Strictly Enforced
Not Strictly Enforced
Global Application Change
Progagated from Templates
Changed in Tools like Excel
Data Represented By
Physical Devices as Objects
Data Types and communication

Bits as Tags
From the inception of PC-based HMI and Supervisory products, the development of data access,
scripting, alarming and data analysis has been based on the concept of tags. While simple and
very portable from one project to another, a tag-based environment has the downfall of a flat
namespace, with no inherent ability to link elements together into more intelligent structures, with
built in relationships and interdependencies. Global changes to a tag database are typically done
externally to the development environment, in tools like Microsoft Excel or as a text file and then
re-imported into the application. Reuse in a tag-based system is commonly instituted through
dynamic or client-server referencing, that allows a common graphic to be created, and then a
script is executed to switch the tags being viewed in run-time. Furthermore, because of the flat
structure of the application, changes need to be sought out and analyzed as to the affect on the
rest of the application.
Use of the word "Object-oriented" with SCADA

The phrase "Object-oriented SCADA" has been with us since the early 1990's. It is mostly used
today to refer to the ability to build graphics and draw pictures based on classes or a hierarchy.
This is referred to as Object Oriented Graphics. This allows you to build a symbol and replicate it
across a screen or HMI application and have visual changes made to all the similar symbols at the
same time. This is useful functionality, but SCADA applications are more than just pretty pictures.
For example, the majority of work that goes into a supervisory application is for things like:
z
Alarm Monitoring
Animation Scripts
Security Scripts
Supervisory Scripts
Historical data storage
Integration with other applications and Databases
2-9
2-10

z
Event Detection
Flow and movement calculations
Device integration
In order to fully realize the benefit of an Object-oriented architecture, a SCADA System today
needs to depict all of these things, along with the graphics as objects.
Types of objects
In object-oriented SCADA, objects contain the aspects or parameters associated with the device
they represent. For example, a valve object can contain all the events, alarms, security,
communications and scripting associated with a device. Objects don't just represent plant
equipment. They can also model common calculations, database access methods, Key
Performance Indicators (KPIs), condition monitoring events, ERP data transfer operations and
many more things that you want the plant information system to do. Because these operations are
modular, it is easy to add them to any and all parts of the application. For example, let's say that
there is a standard way your organization calculates and initiates a maintenance work order for a
pump. By encapsulating this function as an object, it is possible to use it with any pump in the
application.
Wonderware Training

Using object-oriented tools in manufacturing applications
Manufacturing applications typically have a lot of common components. These include common
types of:
z
Plant devices and equipment
Operating procedures
Process measurements
Calculations
Graphics displays
This leads to a cookie cutter approach, where typically small software programs are developed as
objects/code modules that can be stamped out and joined together to form an application. Almost
all of the automation vendors have this capability today with their software. Where an objectoriented SCADA System is different, is that after the cookies are stamped out, you can change the
stamp, and all of the cookies you already made are automatically changed.
This is possible because when a SCADA package is truly object-oriented, it has the notion of a
parent-child relationship, where parent templates are developed and then "Child Objects" are
replicated or instantiated from the parent templates. Now all of the children are tied back to the
parent, so a change in the parent can be replicated to all of the children. This is an extremely
powerful development capability in that:
z
Application creation is optimized by using parent Templates and automated child object
replication
Project change orders are easily accommodated by making changes in the parent
template and having the child objects inherit the changes via change propagation
Ongoing system changes and expansions are easier and more cost effective because of
automated object replication and change propagation
2-11
2-12

Traditional, Tag Based SCADA Development Process
From the inception of PC based HMI and SCADA software, users have built operator graphics and
linked them to tags, which represented addresses in a PLC or a control system. The concentration
was on the computer and the software application. Here is an example of how a traditional tagbased SCADA application is developed.
1. A new HMI application is created on a single computer
2. Windows or displays are created for the application
3. Graphics are created for the windows
4. Tag definitions are imported from the PLC or manually configured
5. Alarm and Event Detection Scripts are defined for each tag
6. Tags are linked to graphic elements
7. Graphics animation scripts or links are created
8. IO Tags are defined and linked to the application
9. If the application is to be deployed in a client-server environment, the application is rearchitected to centralize alarming, event detection, history archiving, graphics and IO servers.
10. Changes to the system require shutting down the application, making changes to the many
scripts and tag database references to enable the new functionality, and reloading the new
HMI application on each workstation.
Object oriented Development Process- graphics are created last

The Industrial Application Server and the ArchestrA Integrated Development Environment (IDE)
have brought a new era to SCADA Software development through the ability to create a complete
plant device model. The developer is abstracted from the complexities of the computing
environment and allowed to concentrate on "modeling" how the production facility is laid out and
the different manufacturing cells and processes that comprise plant-wide supervisory control.
Once the plant model is captured, it is easy to implement supervisory control functions. A small
investment in creating Templates yields big results in engineering productivity. The ten easy steps
to creating a supervisory application using the Industrial Application Server are:
1. A site survey is conducted to understand the layout of the manufacturing operation or process.
Piping and Instrument Diagrams (P&ID) can also be referenced to understand the specific
equipment in use.
2. A list is developed of similar pieces of equipment, like common types of motors, valves,
transmitters, control loops, drives, etc. Distinct areas of operation are also identified.
3. Templates are configured for each common device or component in the facility. For example,
there may be 100 transmitters of a particular type that can be modeled as a single device
template. This process sets up the standards for the supervisory application and for any
applications that are created in the future. These templates will be used to develop objects
which represent a specific device, such as a level transmitter LIC101. In addition, templates
contain all of the logic, input/outputs, scripting, history configuration, security and alarms and
events for the device.
4. Device templates can be contained within each other to build-up a more complicated device,
for example, a mixer may contain a level transmitter, pump, inlet / drain valves and agitator.
Wonderware Training

5. Device templates have attributes which represent real I/O available in the PLC or control
system. These attributes are then linked to the I/O through Device Integration Objects.
6. The application can then be assembled by using a simple drag and drop capability inside if the
IDE. As templates are dropped into their individual plant areas, an object instance is created
that is linked back to the template. This is the "Object-Oriented" nature of the Industrial
Application Server, which provides incredible power when it comes time to modify anything in
the system. The software does all the work as the user is simply configuring templates that
represent the equipment in the plant.
7. Objects are then assigned to security groups. This can be done on an individual basis or by
area of the plant. These security groups have common permissions. Roles are created to map
rights onto each security group. Users can be given one or more roles. This offers a great
amount of flexibility in changing user permissions and in managing the security model.
8. The model created in the IDE can now be deployed to the computers that will host the
application. Notice that absolutely no consideration needs to be given to how the supervisory
stations are going to be laid-out or which computer needs to have a specific part of the system
running on it. The Industrial Application Server is a fully distributed system, which can reside
on a single computer or on hundreds of computers. Standard system objects, such as
Platforms and Engines, represent specific computers that are used to host objects when they
are deployed.
9. Graphics are then configured using InTouch, the world's most popular HMI software
package. This can also be done using the Smart-Symbol functionality contained in InTouch 9.0
SP 2 which allows a graphic element to be created and linked to a template in the ArchestrA
IDE. That way the display graphics are also object-oriented and tightly coupled to the plant
model.
10. Once the application is developed, maintenance of the system is easy. Changes made to
Templates can be propagated to the "Child Objects" linked to the Templates. For example, if
the units associated with a level transmitter need to change from gallons to liters, this can be
done once in the template, and the changes can automatically propagate to all the operator
displays in the plant.
2-13
2-14

Plant Model for Developing (IAS) Course Application
In this course, the manufacturing environment that we will be modeling centers on a Plant with
various Tanks and assorted Tank related components. We will initially focus on one Area of the
Plant and model that Tank System in the Integrated Development Environment (IDE) of the
Industrial Application Server (IAS). Templates will then be developed which will allow for the
simple creation of multiple instances of our Tank System.
The following Figure illustrates the Tank System Model that will be created in the application
developed throughout the course of this class.
TransferPump 01_ CmdStart

TransferPump 01_ AuxC ontact
Transfer Pump
TANKXXY
Inlet Valve
XX = Student # {01,02,03}
Y = Tank # {0,1}
Valve01 _CLS
Valve01 _OLS
Valve01 _CmdOpen
TANK
Tank Level
LIT01 _PV
Outlet Valve
Valve02 _C LS
Valve02 _OLS
Valve02 _C mdOpen
Wonderware Training
Module 3
The Galaxy
Section 1 The Galaxy
Lab 1 Creating a Galaxy
3-3
3-5
Section 2 Tour of the IDE
3-11
Section 3 Facility Modeling
3-31
3-33
Section 4 Objects and Object Instances
3-37
3-43
3-55
3-2
Module 3 The Galaxy

Module Objective
z
Obtain an understanding of Galaxy and the Integrated Development Environment (IDE)
Understand Plant Modeling as it relates to Objects and Object Instances
Wonderware Training

Section Objectives
z
Obtain an understanding of what a Galaxy is and how it relates to the Galaxy Database
and the Galaxy Repository
Understand how a Galaxy is created
What is a Galaxy
Its important to understand what a Galaxy is before we create one. A Galaxy is your whole
application. The complete ArchestrA system consisting of a single logical name space and a
collection of WinPlatforms, AppEngines and objects. One or more networked PCs that constitute
an automation system. It defines the name space that all components and objects live in and
defines the common set of system level policies that all components and objects comply with.
A Galaxy Database is the relational database containing all persistent configuration information for
all objects in a Galaxy.
And a Galaxy Repository is the software sub-system consisting of one or more Galaxy Databases.
Creating a Galaxy
Each IDE session requires connection to a specified Galaxy. In other words, the IDE cannot be
started in a Galaxy-neutral state. When you attempt to start the IDE, the Connect to Galaxy dialog
box is displayed.
This dialog box is comprised of three groups of options:

z
Galaxy Repository/Galaxy connect selections: This consists of the GR Node Name and
Galaxy Name boxes.
Action buttons: Connect, New Galaxy, Delete Galaxy, About and Cancel.
Licensing information
3-3
3-4
Module 3 The Galaxy

If the Galaxy Name box is empty, you have not yet created a Galaxy on the computer shown in the
GR Node Name box. Before you can start the IDE, you must either browse for a Galaxy on
another node or create a new Galaxy.
All new Galaxies are created with no security. They also have the following characteristics: two
users (DefaultUser and Administrator, both with full access to everything), two security roles
(Default and Administrator, both with full privileges) and one security group (Default).
If you previously created one Galaxy on the GR node shown, the Galaxys name is automatically
shown. Click Connect to start the IDE and to connect to that Galaxy. If you previously created
more than one Galaxy on the GR node shown, the most recently accessed Galaxy name is shown.
Choose the desired Galaxy from the Galaxy Name list and click Connect to start the IDE and to
connect to that Galaxy.
Wonderware Training

Introduction
This lab will illustrate the steps necessary to create a Galaxy and enter the Integrated
Development Environment (IDE).
Objectives
Upon completion of this lab the student should be able to:
z
Create a Galaxy.
Re-enter the Galaxy.
Note: To better facilitate the clarity of individual work in this training environment, because of the
Global Naming Space, ALWAYS preface the object name with your FIRST and LAST initial.
(e.g., if the user is John Burns, Valve would be JBValve)
3-5
3-6
Module 3 The Galaxy

Creating a Galaxy
Once we have the Industrial Application Server IDE installed we cannot use it until we create the
Galaxy. Launch the IDE by selecting Start/Programs/Wonderware/ArchestrA IDE. When
initially launching the IDE we will be prompted for a Galaxy connection. This will display the
following Connect to Galaxy dialog box
1. Select the Galaxy Node Name or browse to it using the
icon.
Then select a Galaxy Name. Since there is no Galaxy Name available from the drop down list
then click the New Galaxy button to create one.
The New Galaxy dialog box appears:
2. Enter the Galaxy Name for the Galaxy.

This must be the
node that contains
the Galaxy
Repository (the
Host name of the
computer).
Wonderware Training

In the Galaxy Name field type in a name. For this training environment we will use XYGalaxy.
utilizing the naming convention of XY representing your first and last initials. This is the
database name so including the word Galaxy in the name will enhance reference efficiency.
3. Click Create to continue.
This will bring up a dialog box that indicates the process of creating the new Galaxy.
As soon as this process completes, the Connect To Galaxy dialog box with the Galaxy Name
displays.
3-7
3-8
Module 3 The Galaxy

4. Click Connect. This will close the Connect to Galaxy dialog box and display the IDE.
Re-entering a Galaxy
5. To re-enter the IDE after it has been configured, navigate to the IDE through the Start/
Programs/Wonderware/ArchestrA IDE
Wonderware Training

6. The Connect to Galaxy dialog box displays where you can select a particular Galaxy.
7. After an initial Galaxy has been created, additional Galaxies can be created from the IDE
menu as follows:
In the IDE, select Galaxy/Change Galaxy.
The Connect To Galaxy dialog box appears where an additional Galaxy can then be created.
3-9
3-10
Module 3 The Galaxy
Wonderware Training

Section Objectives
z
Familiarize you with the IDE environment, and
Enable you to orchestrate the operation of additional functionality.
The IDE User Interface

The Integrated Development Environment (IDE) is the integrated design and development tool
from which all ArchestrA objects are configured and deployed to target PCs. It is used to maintain
and configure the objects that comprise your application and the underlying infrastructure that
supports your application.
Using the IDE, you can import new types of objects in to the Galaxy Repository, configure new
ones, and deploy them to PCs on your network. Multiple users can work concurrently on different
sets of objects from different IDEs.
The IDE can be installed on any PC that has ArchestrAs Bootstrap software installed.
Key Functions of the IDE

The Main Window is the user interface in which you can create your application and deploy it to
your enterprise. This main window provides the key platform where a wealth of functionality
capability can be accessed and configured. Some of these key functions include the following.
z
Galaxy Configuration
Connect to an existing Galaxy on the network
Create a new Galaxy
Destroy a Galaxy
Import/Export Objects (aaPackage, .csv)
Import/Export script function libraries (.dll, .tlb, .olb, .wdf, .aaSLIB)
Security Configuration
Configure User security
Configure Object security
Object Configuration
Create new objects
Check out objects
Edit objects
Configure Historization through objects
Configure objects for Alarms and Events
Extending object functionality
Check in objects with comments
Deploy/undeploy objects
Propagate changes to runtime objects
View objects configuration errors/warnings
Upload runtime changes to Galaxy database
3-11
3-12
Module 3 The Galaxy

z
IDE Configuration
Set user preferences
Create a Tool Box
As we identify and discuss the main aspects of the IDE Main View (e.g., Menu options, Toolbars,
Template Toolbar and Application Views, etc.) we will elaborate in greater detail how these Key
Functions can be used
The IDE User Interface

Main View
The Main Window of the IDE is composed of the following components:

z
Title bar
Menu bar
Toolbar
Template Toolbox
Application Views
Object Editor Client Area
Status bar
When you first log in to the IDE, the Main Window displays the Template Toolbox and Application
Views docked on the left, the Toolbar docked at the top, and the Object Editor Client Area on the
right. Upon subsequent logins by the same user, the Main Window displays the positions for these
controls as they were at the end of the last log in session.
Wonderware Training

The Title Bar displays the name of the utility. The other elements of the Main Window are
described below.
Menu Bar
The IDE Menu Bar is a dynamic element that includes the following menus:
Galaxy, Edit, View, Object, Window, and Help. Depending on what object or Main Window
element is in focus, what condition it is in, or whether certain functions are logically permitted,
some menu commands may be deactivated. The following is a description of menu commands.
Galaxy menu Providing Galaxy or user-level global commands, the Galaxy menu includes the
following:
New For creating a new Instance, Derived Template, or Template Toolset.
Open For opening the editor of the object in focus. The editor appears in the Object
Editor Client Area of the Main Window.
Open Read-Only For opening the editor of the object in focus, but only in read-only
mode. There are several conditions that can place this restriction on opening an objects
editor. One example would be when the object is checked out to someone else.
Additionally, if you do not have configuration permissions for the object in question.
Close For terminating the object edit session in focus. This command is available only if
the editor for one or more objects is open. If the object has been modified, you are
prompted to save the new data to the Galaxy Repository. The same validation scenario
applies as described in the Save menu command.
Import For importing Automation Objects, Script Function Library, and Galaxy Loads.
3-13
3-14
Module 3 The Galaxy

z
Export For exporting Automation Objects, All Automation Objects, Script Function
Libraries, and a Galaxy Dump.
Save For saving the currently-opened objects configuration, which is persisted to the
Galaxy Repository. This command is available only if the editor for at least one object is
open and configuration data has been modified in at least one of them. Validation occurs
on the editor level; if errors or warnings are identified during validation, they are displayed
in a message box and the user is given the choice to continue saving or cancel the save.
Save All For saving ALL the currently-opened objects configuration, which is persisted
to the Galaxy Repository. This command is available only if the editor for at least one
object is open and configuration data has been modified in at least one of them. Validation
occurs on the editor level; if errors or warnings are identified during validation, they are
displayed in a message box and the user is given the choice to continue saving or cancel
the save.
Configure For configuring Security, the Time Master, or to Customize Toolsets.
Galaxy Status For viewing information relating to the Galaxy such as the total number
of instances, total number of templates and other related Galaxy information.
Properties For viewing the properties of the object in focus.
Change Galaxy For selecting a Galaxy repository that is different from the one to which
you are currently connected, this command opens the Select Galaxy dialog box.
Change User For changing the logged in user of this IDE, this command opens the IDE
Login dialog box.
Edit menu providing edit capabilities, the Edit menu includes the following commands:
Rename For renaming the object in focus.
Rename Contained Name For renaming the contained name of the object in focus.
Delete For deleting the object in focus.
Find For locating specific items of information based on a variety of configurable search
criteria.
User Information For viewing the Prompts, Initial Scan State, Scan State Defaults, and
User Defaults.
View menu similar to a standard Microsoft View menu, this menu provides commands for
controlling the Main Window display. On your initial IDE login, all four Main Window components
listed below are visible (checked) and the client language is set to the one chosen during
installation. Subsequent logins by the same user implement the previously saved IDED settings.
This menu includes the following commands:
Wonderware Training

z
Application View For bringing focus to the Application Views part of the Main Window.
Template Toolsets For bringing focus to the Template Toolbox part of the Main
Window.
Operations For displaying the progress and results of a set of Galaxy database
operations that can be done at the same time as other application-building operations.
See separate section for additional information regarding this feature.
Status Bar For toggling on/off the Status Bar of the Main Window.
Objects menu the Objects menu includes the following commands:
Check-Out For checking out an object from the Galaxy Repository so that you can
maintain sole authority to configure that object. Nobody else connected to the Galaxy can
affect the configuration of the object until you have checked it back in to the Galaxy.
Check-In For checking in to the Galaxy Repository an object which was previously
checked out. This command opens the Check-In Object dialog box.
Undo Check-Out For reversing a previous check-out without affecting the configuration
of the object in question. The result of this command is the object can be checked out by
anyone connected to the Galaxy.
Override Check Out Use this command to disable the checked out flag on the selected
object. This command typically requires special security permissions and should be used
only in those circumstances in which it is certain that object configuration is not being done
by the user who originally checked out the object. If the objects editor is currently open,
the override function fails.
Validate For checking allowable attribute value ranges, compiling its scripts, updating
and binding its references, validating its extensions, updating its status, and validating
other configuration parameters that may be unique to the object.
Note: See Validating Objects on page 3-18 for additional information regarding this feature.
z
View in Object Viewer For allowing the evaluation of attributes and conditions when the
objects are deployed. It provides a visual display of the actions being executed.
Deploy For deploying the object or objects currently in focus to the nodes their
configurations denote, this command opens the Deploy Object dialog box.
3-15
3-16
Module 3 The Galaxy

z
Undeploy For undeploying the object or objects currently in focus from the nodes that
currently host them, this command opens the Undeploy Object dialog box.
Assign To For assigning objects to a different platform.
Unassign For unassigning objects to a different platform.
Set As Default For setting a System Object, such as WinPlatform or AppEngine, as the
default for assigning appropriate objects.
Upload Runtime Changes For uploading a deployed objects configuration to the

Galaxy Repository. This function is useful when changes to certain attributes
(Writeable_UC, Writeable_UC_Lockable, Writeable_USC, Writeable_USC_Lockable) are
made in the configuration environment, but at a later time, the runtime objects
configuration is determined to be preferred. Select the desired object and click Upload.
The runtime configuration overwrites the configuration environment data in the Galaxy
Repository.
Window menu For manipulating the Object Editor Client Area of the Main Window, this menu is
available if at least one objects editor is open. This menu includes the following commands:
Cascade Standard Windows command for cascading (layering) multiple object editors.
Tile Horizontally Standard Windows command for displaying the editors horizontally.
Tile Vertically Standard Windows command for displaying the editors vertically.
Close All For closing all open object editors. If any data was changed on any editor, you
are prompted to save those changes individually for each editor.
Windows For selecting through a separate dialog box which editors to activate or how
they are to be displayed.
Help menu similar to a standard MS Help menu, the IDE Help menu includes the following
commands:
Help Topics Standard Help command, used for opening the IDEs HTML Help
documentation system.
Object Help Provides information about the object in focus.
About ArchestrA IDE Opens the About ArchestrA IDE dialog box which provides
software version and copyright information.
Wonderware Training
Operations Pane
The Operations pane displays the progress and results of a set of Galaxy database operations
that can be done at the same time as other application-building operations. Currently, validating
the configuration of objects is the only operation that uses this pane.
Important! Validation can be done on both templates and instances, but only on those that are
checked in.
Validating an object checks its configuration; that includes checking allowable attribute value
ranges, compiling its scripts, updating and binding its references, validating its extensions,
updating its status, and validating other configuration parameters that may be unique to the object.
Note: A primary use of validation is to validate objects that were configured prior to the importing
of relevant script libraries. Such objects would have a status of Bad. Validating these Bad objects
corrects references to the script libraries and updates their status to Good.
To display the Operations pane, either
z
Right-click on an object (multi-select is allowed) and click Validate on the shortcut menu.
Click Operations on the View menu.
The following pane is then displayed in the Main Window.
To hide the Operations pane, click the X close button.

During the validation of an object, its icon and name are displayed along with the status of the
operation. The status of the object (Status column) is dynamically represented by an icon: no icon
indicates Good status, an Error or Warning icon indicates either of those states. When validation is
complete, the Command Result column displays either a "Succeeded" or "Failed" message, which
may contain additional information about the validation results.
Note: You can validate all objects in the Galaxy by running the Validate operation on the Galaxy
object. In that case, Command Result messages are displayed after all objects in the Galaxy are
validated.
If multiple objects are validated, the list of objects is sorted by object name. You can click a column
heading to re-sort according to alphanumeric or icon groupings. Use the check mark column
heading to sort for objects that are checked out and, therefore, cannot be validated. The objects
icon indicates checked out status with a check mark.
You can perform any operation on an object listed in the Operations pane that is possible in the
Template Toolbox or Application Views. Right-click on the object and select commands from
the shortcut menu. You can open an object's editor from the Operations pane by double-clicking
it. To view an objects properties (particularly, the Errors/Warnings page of the Properties dialog
box), double-click its status icon. You can also copy a line of text in the Operations pane list by
clicking Copy from the shortcut menu (or Ctrl+C). The Operations pane, like the Template
3-17
3-18
Module 3 The Galaxy

Toolbox and Applications Views, is also updated as the status and conditions of objects in the
Galaxy change.
Validating Objects
Each object in a Galaxy has a set of possible configurations that authorizes its proper use in an
application. That set of configuration possibilities is validated by the object either while you are
configuring it or when you save that configuration to the Galaxy database.
Validation of an objects configuration includes checking allowable attribute value ranges,
compiling its scripts, updating and binding its references, validating its extensions, updating its
status, and validating other configuration parameters that may be unique to the object.
Typically, each option on an objects editor that requires a string or numeric input has an allowable
range of inputs. If you type an input outside the allowable range and then attempt to change editor
page, close the editor or save the objects configuration, a message is displayed about the input
error indicating the allowable range.
Some configuration settings are dependent on associations with external components, such as
script function libraries and relative references to other objects attributes. The status of these
external components can change, perhaps rendering some capability of the object inoperative.
For instance, an object may refer to a value of an attribute of another object, which is subsequently
deleted. That scenario would break the configuration of the remaining object. Objects may be
configured prior to the importing of associated script function libraries. In each case, the object
would have a status of Bad. You can verify that an objects configuration is valid and reset its
status to Good by manually validating it with the Validate command on the Object menu.
Manual Validation
To manually validate one or more objects, select the object(s) and click Validate on the shortcut
menu (by right-clicking the object) or on the Object menu. You can select objects from the
Template Toolbox, the Application Views or the Find dialog box.
Important! Manual validation can be done on both templates and instances, but only on those that
are checked in.
Using the Find dialog together with the Validate command is an especially useful tactic. For
instance, you can find objects in Error state, select them all, right-click on one of them, and click
Validate on the shortcut menu.
The Validate command opens the Operations pane in the IDE. See section on Operations Pane
for more information.
Only one validation operation can be run at a time. But you can multi-select more than one object
for each validation operation. The set of objects are validated serially.
Note: Validation operations cannot be canceled.
Continue using the IDE to perform other operations, if necessary, while validation is ongoing,
including work on objects in the validation set. If an object is not available for validation when the
command is initiated on it, validation is not be performed. Also, if validation is in process on an
object, other operations initiated by you on the object fail. Failure to perform validation on an object
is indicated in the Command Results column of the Operations pane.
To validate all objects in the Galaxy, validate the Galaxy object.
Wonderware Training
Toolbar
The IDE Toolbar consists of icons for quick access to frequently used commands. It is shown
below, and each icon, from left to right, is described afterwards. The description titles associated
with each below are based on the tool tip that appears when you hover over each Toolbar icon.
Change Galaxy For selecting a Galaxy repository that is different from the one to
which you are currently connected, this command opens the Select Galaxy dialog box.
Import Automation Object For importing a template definition file (.aapdf). This
command opens the standard Microsoft Open dialog box with the default file extension
(.aapdf). One or more files can be selected at a time. Validation is done with regard to the
selected file(s) being a valid template definition file. A progress indicator then provides a visual
view of the importing process. After the file(s) is imported, one or more new objects is added to
Galaxy Repository and the Template Toolbox displays the new object(s).
Open For opening the editor of the object in focus. The editor appears in the Object
Editor Client Area of the Main Window.
Save For saving the currently-opened objects configuration, which is persisted to the
Galaxy Repository. This command is available only if the editor for at least one object is open
and configuration data has been modified in at least one of them. Validation occurs on the
editor level; if errors or warnings are identified during validation, they are displayed in a
message box and the user is given the choice to continue saving or cancel the save.
Find For locating specific objects based on a variety of configurable search criteria.
Check-Out For checking out an object from the Galaxy Repository so that you can
maintain sole authority to configure that object. Nobody else connected to the Galaxy can
affect the configuration of the object until you have checked it back in to the Galaxy.
Check-In For checking in to the Galaxy Repository an object which was previously
checked out. This command opens the Check-In Object dialog box.
Undo Check-Out For changing an objects status from checked out to checked in.
Afterwards, any user can check out and configure the object. Undo Check Out places a
notation in the objects change log. Changes you made to the object when it was check out are
backed out. An error message is displayed when the objects configuration editor is open.
Properties For accessing the properties of the object in focus.
3-19
3-20
Module 3 The Galaxy
Deploy For deploying the object or objects currently in focus to the nodes their
configurations denote, this command opens the Deploy Object dialog box.
Undeploy For undeploying the object or objects currently in focus from the nodes
that currently host them, this command opens the Undeploy Object dialog box.
Delete For deleting the object in focus.
Customize Toolsets For maintaining the toolset categories displayed in the

Template Toolbox, this command opens the Customize Toolsets dialog box.
User Information For configuring global user preferences for the IDE. Using this
command opens the Configure User Information dialog box.
Galaxy Status For accessing the status of the current Galaxy.
Template Toolbox For toggling on/off the Template Toolbox part of the Main
Window.
Application Views For toggling on/off the Application Views part of the Main
Window.
IDE Help Standard Help command, used for opening the IDEs HTML Help
documentation system.
The availability of the previously described icons is dynamic depending on which part of the IDEs
Main Window is in focus, whether a particular action is allowed, or whether something has been
changed in the configuration environment. Depending on these conditions, some icons may be
unavailable.
Wonderware Training
Template Toolbox
This part of the Main Window hosts object template toolsets, which contain object Templates, from
which instances are created or other object templates are derived. The Template Toolbox contains
separate toolset bars for each toolset in the Galaxy Repository. Click the toolset bar to open that
toolset and display the object templates contained in the chosen toolset.
When you first log in, the default toolset with default object templates is opened. Once a user has
logged in to the Galaxy Repository, the Template Toolbox is loaded with the toolset that was
displayed during the last login session.
An example of a Template Toolbox view is as follows:
The items with $ prefixes are templates or templates which were derived from other templates.
Application Views
The Application Views pane displays the galaxy configuration based on how an object is related to
other objects:
z
Model View - This defines the Object relationship to the automation scheme layout. The
Objects are organized into Areas to represent the physical plant layout.
Deployment View - This view defines the Object instance relationship to the PC that the
Object code is running on.
Derivation View - This view displays what the derivation path is from Base Template to
Instance. All templates and instances are displayed in this view.
The Model view is the default display when the IDE is first launched. Subsequent IDE sessions
retain the users last setting.
3-21
3-22
Module 3 The Galaxy

Model View
The Model view presents objects in terms of their physical or containment relationships, and
allows you to organize them through a folder structure. This view most accurately represents an
application perspective of the processes that users are emulating: for instance, specific process
areas, tanks, valves, pumps and their relationships based on containment.
An example of a Model view is as follows:
Galaxy Name
This view is used to display the assignment of Object Instances to their area. All Object instances
belong to one and only one area.
Areas can be hierarchical. This means that an area can contain an area and the parent area
collects the statistics for all its Objects and its sub-areas.
The above diagram represents the tree view that is displayed within the model view. This
represents the area based relationships of each of the objects. The diagram is read left to right and
top to bottom, so an Area can host Application objects, DeviceIntegrationObjects,.and Objects that
contain Objects
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Area" root of the tree.
Wonderware Training

The top of the tree will be the GalaxyObject, This will be displayed using the name that was given
to the Galaxy when it was created.
To assign one object to another, drag-and-drop it. To unassign an object currently assigned to
another object, drag-and-drop it to the Unassigned Area folder.
Deployment View
The deployment view is used to display the assignment of the automation scheme to physical
machines and process engines. This view describes where the objects are running. This view
does not represent your physical plant environment.
An example of a Deployment view is as follows:
This diagram represents the tree view that is displayed within the deployment view. This
represents the topology view based on which PC and Engines the objects run on. The diagram is
read left to right and top to bottom, so a Platform can host an ApplicationEngine. Also, an
ApplicationEngine can host an Area.
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Host" root of the tree.
3-23
3-24
Module 3 The Galaxy

To assign an object to another, drag-and-drop it onto the host object. An inappropriate assignment
match is not allowed. Conversely, to unassign an object, drag-and-drop it to the Unassigned
folder.
Derivation View
The Derivation view presents objects and templates in terms of their genealogy relationships. The
derivation view is the only tree view that shows both templates and instances. The purpose of this
view is to display to the user from which templates and derived templates an instance inherits its
properties.
An example of a Derivation view is as follows:
This view will contain all templates and instances. The tree will be displayed in alphabetical order
at each level within the tree.
The base templates created within the ApplicationObject Toolkit will be on the left, as all other
templates and instances are derived from these an extra level will be added to the tree.
Wonderware Training

The items with $ prefixes are templates or templates which were derived from other templates.
Base templates are shown in the second level of the tree structure, and derived templates and
object instances are appropriately indented based on their relationship with parent objects.
Templates with no associated instances are grouped together under Unused Templates. Under
each branch of the tree, child objects are listed in alphabetical order. Default objects are displayed
in bold.
Unlike the Model and Deployment views, you cannot drag-and-drop objects from one branch to
another in the Derivation view. The parent-child relationship between a template and a
downstream object cannot be changed dynamically. You can perform other commands on objects
in this view.
Object Icons
When viewing the objects, there are several states that are reflected in the way the icons for that
particular object are represented.
For instance, notice the different types of icons in the following example:
Three Types of Status Indicators

There are three kinds of indicators that accompany object icons:
z
deployment status (for instances only)
configuration status (for templates and instances)
redundancy status (for instances only).
Deployment status indicators include:

Icon
Description
Undeployed (see AnalogDevice_001 and
DDESuiteLinkClient_001 in example above)
(no indicator)
Deployed (see AppEngine_002 in example

above)
Deployed with configuration changes (see
AppEngine_001 in example above)
Deployed with software update required (see
WinPlatform_001 in example above)
3-25
3-26
Module 3 The Galaxy

Configuration status indicators include:
Icon
Description
Configuration warning
Configuration error
(no indicator)
Configuration good
Redundancy status indicators include:

Icon
Description
AppEngine undeployed, its redundant pair not
undeployed.
AppEngine deployed, its redundant pair not
deployed.
Checking Out/Checking In Objects

Users of the IDE reserve an object for making private changes by checking it out. The user can
then modify the object and save private versions of it before releasing it to the Galaxy (check in)
for others to see and use. You can also back out changes made to the object through the undo
check out feature.
Note: All IDEs connect to a Galaxy display current status for each object in the Galaxy, and a
change history for each object can be reviewed.
If any of the objects you attempt to check out are already checked out to other people then a dialog
will appear indicating their status. Also, if some of the objects you attempt to check out are already
checked out to you, the operation is ignored.
The Galaxy marks the objects as checked out to you, making them unavailable for check out to
other users, and it updates the objects revision history. A check mark is shown next to an objects
icon in the IDE.
To check out unreserved objects
a. Select them in the Template Toolbox or Application Views.
b. On the Object menu, click Check Out.
Wonderware Training
Or, right-click on the object and select Check Out. Optionally, an object is automatically
checked out to you when you open its configuration editor. If the object is already checked out,
you can open its editor only in read-only mode.
To determine an objects status and history, open the Properties dialog box.
The user responsible for an operation at a specific date and time is listed on the Change Log
page. Comments typed by a user in the Check In dialog box (see image later) are listed under the
Comment heading.
3-27
3-28
Module 3 The Galaxy

To check an object in to the Galaxy database
a. Select it and, on the Object menu, click Check In
Or, right-click on the object and select Check In. The Check In dialog box is displayed.
Note: If the object was originally checked out to you when you opened its configuration editor,
the check in function can be combined with the save and close functions of the editor. If you
close the editor without making any changes to the objects configuration, a check in operation
effectively does an undo check out (no change log recorded).
b. Enter a comment (optional) and click OK to finish checking in the object. Click Cancel to
terminate the check in process.
The Galaxy indicates whether any of the objects you are attempting to check in are check-out to
other people. If an object you are attempting to check in already is checked in, check in is ignored.
Wonderware Training

The Check In dialog box enables you to provide comments about configuration changes made
while the object was checked out. It is comprised of the following options:
z
Comment: Use this box to enter your comments about configuration changes made to the
object.
Dont Prompt for Check-In Comments in the Future: Use this check box to turn off the
comment feature when checking in objects in the future. If you decide to reinstate this
feature, click User Information on the Edit menu and select Ask for Check In
Comments in the Configure User Information dialog box.
Undo Checkout, Override Check Out

Two other IDE commands related to the concept of check out and check in include:
z
Undo Check Out: Use this command to change an objects status from checked out to
checked in. Afterwards, any user can check out and configure the object. The check out/
check in function places a notation in the objects change log. Use Undo Check Out to
effectively check in the object without affecting the change log. Changes you made to the
object when it was checked out are backed out. This command is not allowed when the
objects configuration editor is open.
Override Check Out: Use this command to disable the checked out flag on the selected
object. This command typically requires special permission, and should be used only in
those circumstances in which it is certain that object configuration is not being done by the
user who originally checked out the object. If the objects editor is currently open, the
override function fails.
Uploading Runtime Configuration to Galaxy

Changes to certain attributes (Writeable_UC, Writeable_UC_Lockable, Writeable_USC,
Writeable_USC_Lockable) can be made in the configuration environment and then later changed
at runtime. As a result, the values of these attributes can differ between the runtime and
configuration environments.
You can upload runtime configuration changes to the Galaxy database so that the attribute values
in the database match those in the runtime. This feature provides the advantage that if the
uploaded object is ever redeployed, or undeployed and then deployed, its runtime configuration
changes are deployed with it.
3-29
3-30
Module 3 The Galaxy

To upload runtime configuration to the Galaxy
a. Select the object in the Model or Deployment View. Multi-select is allowed with Shift+Click
or Ctrl+Click. For instance, you could select an entire hierarchy from AppEngine down.
b. On the Object menu, click Upload Runtime Changes. The runtime attributes of the selected
objects are copied over those in the Galaxy database.
If you choose an object that is currently checked out to you, a warning is displayed during runtime
upload. If you choose to continue, you lose all configuration changes you made to the checked out
object. The Galaxy performs an Undo Check Out operation on it before the runtime attributes are
copied to the Galaxy database.
Note: Performing this function on objects checked out to other users is not allowed.
Objects whose configuration has been successfully uploaded have a new version number and a
change log entry for the upload operation. The runtime objects version number also has a new
version number, and that version number matches the version in the configuration database.
Object Viewer
The Object Viewer monitors the status of the objects and their attributes and can be used to
modify an attribute value for testing purposes.
To add an object to the Object Viewer Watch list, you can manually type the object and attribute
names into the Attribute Reference box in the menu bar and select Go. When prompted to enter
the Attribute Type, press the OK key.
You can save a list of items being monitored. Once you have a list of attributes in the Watch
Window, you can select all or some of them and save them to an XML file. Right-click on the
Watch window to save the selection or load an existing one. You can also add a second Watch
window that shows as a separate tab in the bottom of the Viewer.
Refer to the Platform and Engine documentation for information about attributes that may indicate
system health. These attributes provide alarm and statistics on how much load a platform or
engine may have when executing application objects or communicating with I/O servers and other
platforms.
Wonderware Training

Section Objectives
z
Understand the importance of having a model of the plant facility.
Understand the concept of how to utilize ArchestrA Industrial Application Server to model
a specific facility.
Modeling of the Facility

With the ArchestrA Industrial Application Server it is possible to create a working model of the
plant manufacturing environment which will utilize the product. Having this model will enable you
to implement a structured naming convention that will facilitate the coordination of all the
processes and areas. It will also provide the ability to create objects representing your actual plant,
configure them to your own specifications and create templates from them which will enable you to
propagate one area to another.
The ArchestrA plant application model allows you to organize a distributed computing application
by:
Plant
Section
Area
Production
Line
Manufacturing
Cell
Once a plant application model has been developed, applications can be easily extended or
replicated based on the structure you have provided. With this Facility Model you can:
z
Rapidly create application standards.
Deploy applications across multiple plants or projects.
This provides universal application development capabilities. Additionally, it provides the ability to
build industrial applications that ensure consistent engineering quality and operational best
practices.
3-31
3-32
Module 3 The Galaxy
Wonderware Training

Introduction
When you begin to consider an industrial automation job, the first thing you are presented with is
the physical layout of the plant. This is the stage where the plant tour occurs and a list of process
facilities identifies who is responsible for what and how alarms, events and data is transferred
throughout the plant. Industrial Application Server facilitates this stage with the Area object and the
Model View environment.
This lab will illustrate the steps necessary to model your facility by creating a Plant area with
additional areas called Intake, Discharge, Production, Line1 and Line2. Since we are modeling our
plant the views will be solely from the Model View.
Objectives
z
Create instances of Areas.
Rename the Areas and organize them in a way that models the facility.
Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.(e.g., if
the user is John Burns, Valve would be JBValve) This will eliminate problems when we deploy our
objects in a common galaxy later in the course.
3-33
3-34
Module 3 The Galaxy

Tasks
Create Area Instance
1. Select the Model View pane.
2. Drag and drop the object $Area from the Template Toolbox to the Application View to create
an instance of an Area.
Notice we are looking at

the Model View.
Once the instance has been created it will display as follows:
Wonderware Training
3. Create five (5) more instances of an Area so that there are a total of six (6) Areas.
3-35
3-36
Module 3 The Galaxy

4. Rename the Areas as
z
Plant
Intake
Production
Discharge
Line1
Line2
Remember to use the naming convention discussed earlier.
5. At this point we will organize the Areas in a way that more accurately reflects the model of our
facility.Drag and drop each of the Areas so that hierarchy appears in the following order:
Plant
Discharge
Intake
Production
Line1
Line2
6. Now add an additional Area, rename it XYSystem (where X and Y are your first and last initial
respectively). We will place the XYSystem area at the same level as the Plant Area.
Wonderware Training

Section Objectives
z
Understand the terminology associated with the various objects in the IDE.
Understand the various types of objects utilized in the IDE.
Become familiar with when and how they are used.
Understand how to create and configure instances of objects.
Terminology
This section contains a description of key terms to facilitate the ease of reference to the various
aspects of ArchestrA and AppServer in particular. These are categorized by Product Names and
Component Names.
Product Names
ArchestrAObject Toolkit (AppObject Toolkit) a programmers tool used to create new
ApplicationObjects Templates, including their configuration and run-time implementations. In
addition, it is the toolkit for Device Integration Solutions primarily for use with the Application
Server system. This toolkit includes the Data Access Server and the ApplicationObject Toolkit,
enabling the user to create the:
1. DINetwork Object
2. DIDevice Object
Application Server (AppServer) This is the product name given to the new Wonderware
FactorySuite A2 Application Server, which will run the objects as a blind node, allowing a product
to be loaded on top of existing systems to extend value. This product has an execution engine
(app eng) which hosts the application objects performing the functionality, and then stores this into
a history storage system, which is also included in the product.
ArchestrA Data Access Server Toolkit (DAS Toolkit) This is the toolkit for building Data
Access Servers, which are the next generation of I/O servers, and are the I/O server executable.
These are OPC servers, and this toolkit is to be a product which enables Wonderware and third
parties to develop powerful OPC servers which could go to third party clients and Application
Server clients.
Data Access Server (DAServer) Refers to the Server executable that interfaces to the device
serving data to the DINetwork Object and DIDevice Object, via standard client protocols OPC, or
to any third party client. These replace our current I/O Servers.
Components of a DAS Toolkit:

z
Client Plug-ins: These are the components which are added to a DAS server to enable
communication with clients. Examples are: OPC 2.03, DDE/Suitelink, etc.
DAS Engine: This is the .DLL which contains all the common logic to drive data access
(this used to be called Core toolkit).
Device Protocol: This is custom code set up by the user to define the communication
with a particular device.
DAS Control Client: This is the MMC snap-in supplied with the DAServer that provides
the necessary UI for activation and configuration.
3-37
3-38
Module 3 The Galaxy
DAS Diagnostic: This is part of the DAS Control Client MMC snap-in-that provides a
set of diagnostic information for DAServers within the system
DAS Configuration: This is part of the DAS Control Client MMC snap-in which
enables configuration of the DAServer either locally or remotely.
DAS Activation: This is part of the DAS Control Client MMC snap-in which enables
the user to start and stop the DAServer.
DAS AppWizard: This is the C++ Wizard that generates the framework of the DAServer
Generic State Engines: These are engines which enable the device protocol developer
to build the particular functions:
Device Engine
Serial Engine
TCP/IP Engine
Component Names
ArchestrA AutomationObject Toolkit This is the toolkit for developing core ApplicationObjects,
in a C++ environment, which will be imported into the Galaxy via the IDE.
Area AutomationObject the AutomationObject that represents an Area of a plant within an
Application Server Galaxy. The area object acts as an alarm concentrator and is used to put other
AutomationObjects into the context of the actual physical automation layout.
ApplicationEngine (AppEngine) a real-time Engine that hosts and executes
AutomationObjects.
ApplicationObject An AutomationObject that represents some element of a user application.
This may include things such as (but not limited to) an automation process component (e.g.
thermocouple, pump, motor, valve, reactor, tank, etc.) or associated application component (e.g.
function block, PID loop, Sequential Function Chart, Ladder Logic program, batch phase, SPC
data sheet, etc.).
AutomationObject A type of Object that represents permanent things such as hardware,
software or Engines as objects with a user-defined, unique name within the Galaxy. It provides a
standard way to create, name, download, execute or monitor the represented component.
ContainedName This is the final portion of the HierarchicalName that defines the name of the
object within that containment level, i.e. HierarchicalName = Line1.Tank1.InletValve, TagName =
V1101 ContainedName = InletValve
Device Integration Objects (DIObject) AutomationObjects that represent the communication
with external devices, which all run on the application engine local. The objects for example are:
z
DINetwork Object Refers to the object that represents the network interface port to the
device via the Data Access Server, providing diagnostics, and configuration for that
specific card.
DIDevice Object Refers to the object that represents the actual external device (e.g.
PLC, RTU) which is associated to the DINetwork Object. Providing the ability to diagnose,
browse data registers, and DAGroups for that device.
Framework An infrastructure consisting of a common set of services, components and

interfaces for creating and deploying Automation objects that collect, store, visualize, control,
track, report and analyze plant floor processes and information.
Galaxy complete Application Server system consisting of a single logical name space (defined
by the Galaxy Repository) and a collection of Platforms, Engines and Objects that are included
within it. One or more networked PCs that constitute an automation system. It defines the name
Wonderware Training

space that all components and objects live in and comply with a common set of system level
policies. This is the whole application.
GalaxyDatabase the relational database containing all persistent configuration information for
all Templates and Objects in an Application Server Galaxy.
GalaxyRepository the software sub-system consisting of the Galaxy Repository Engine,
Package Server, Repository Interface, and the Galaxy Database.
HierarchicalName This is the name that is created by the system that positions the object within
any containment i.e. HierarchicalName = Line1.Tank1.InletValve, TagName = V1101
Integrated Development Environment (IDE) The IDE is an Integrated Development
Environment consisting of various configuration editors that are used to configure the total system,
aimed for the application engineer, and general use.
Objects AutomationObjects (all types), AutomationObject, UserProfiles, Displays, Symbols,
DisplaySets, ActivityObjects are collectively referred to as Objects. Common characteristic of all
Objects is that they are stored as separate components in the GalaxyRepository.
z
ObjectTemplate a specific state of an Object in which the Object is a generic template

from which instances can be generated.
ObjectInstance a specific state of an Object in when the Object has been substantiated
to the actual unique instance of the object that will run in the system.
Platform Object a representation of the physical hardware that the Application Server software
is running on. Platform Objects host Engine Objects (see WinPlatform).
QuickScript .NET this is the name of the scripting language component that is an enhanced
version of InTouch QuickScript with new language features and integration with Microsoft .NET.
System Management Console (SMC) This is the central runtime system administration /
management user interface, where all required runtime administration functions like new users,
redeployment, license management will occur.
TagName This is the unique name given to a Object.
i.e. HierarchicalName = Line1.Tank1.InletValve, TagName = V1101
WinPlatform a single computer in an Application Server galaxy consisting of Network Message
Exchange, a set of basic services, the operating system and the physical hardware; hosts
Application Server Engines and is a type of Platform Object.
Objects
Some of the primary objects that are integrally a part of the Integrated Development Environment
(IDE) in AppServer are the:
z
WinPlatform Object
AppEngine Object
Area Object
AnalogDevice Object
DiscreteDevice Object
FieldReference Object
Switch Object
UserDefined Object
3-39
3-40
Module 3 The Galaxy

WinPlatform Object
The WinPlatform platform object is a key base object. The key functionality of this object includes:
z
Calculating various statistics related to the node its deployed to. These statistics are
published in attributes.
Monitoring various statistics related to the node its deployed to. These monitored
attributes can be alarmed as well has historized.
Starting and stopping engines, based on the engines startup type, which are deployed to
it.
Monitoring the running state of engines deployed to it. If the platform detects an engine
has failed it can (optionally based on the value of the engines restart attribute) restart the
engine.
There is a special instance of the platform object called the galaxy platform. This platform
instance:
z
Exists on the galaxy node.
Is used by message exchange to bind unresolved attribute references
AppEngine Object
The AppEngine Object must have a Platform on which to run. The key functionality of this object
includes:
z
hosting application objects, device integration objects and areas
containing the logic to setup and initialize objects, when theyre deployed.
containing the logic to remove objects from the engine, when theyre undeployed.
determines the scan time within which all objects within that particular engine will execute.
In general the AppEngine contains no added value other then to support the creation, deletion,
startup, and shutdown of objects.
Area Object
The Area Object plays a key role in alarm and event distribution. All AutomationObjects belong to
an Area. Areas can contain sub-Areas. Areas provide a key organizational role in grouping alarm
information and assigning it to those who use alarm/event clients to monitor their areas of
responsibility.
Wonderware Training

This object is very simple; it only allows the value of three attributes to be historized:
z
Active alarm counter
Unacknowledged alarm counter
Disabled (or silenced) alarm counter
Creating and Deleting Instances

ApplicationObject instances are created from the templates provided by the Template Toolbox.
A default name is given to the new instance. The newly created Object instance is put into focus
and set to rename mode.
This view also allows the Object instance to be edited.
Object instances can be deleted from this view if the Object does not have any other Objects
assigned to it.
By default the first instance of the Platform object will be configured with the name of the Galaxy
Repository node name. This platform can then be renamed.
There are two ways to create an instance of a template. This is indicated as follows:
Creating an Instance - 1
Drag and drop the template object from the Template Toolbox to the Application View. To delete
an instance of the Platform object highlight it and click on the Delete icon in the menu icon bar
, or, right click on it and select Delete.
Notice we are looking at

the Deployment View.
3-41
3-42
Module 3 The Galaxy

It can now be renamed using the naming convention as designated by your instructor.
Creating an Instance - 2
Highlight the object in the Template Toolbox for which you desire an instance. Then from the
Galaxy menu, select Galaxy/New/Instance or use the short cut which is Ctrl+N.
Wonderware Training

Introduction
At this point in the modeling process, you need to think about the physical architecture as well as
alarm/event reporting. A platform object represents a physical entity and we will have to go into
Deployment View when we are ready to allocate this physical piece of equipment. However we
always start in Model View as we are organizing our objects in alarm groups and associating
process entities as they are associated in the process environment.
This lab will illustrate the steps necessary to create a Platform instance from the Template
Toolbox, configure the objects and deploy them.
Objectives
z
Create an instance of the Platform.
Configure the instance of the objects using the object editor.
Deploy the instances.
Save and close the editor.
3-43
3-44
Module 3 The Galaxy

Tasks
Create Instance of the Platform
1. Select the Model View pane.
2. Drag and drop the object $WinPlatform from the Template Toolbox to the Application View to
create an instance of a Platform.
Notice we are
looking at the
Model View
Wonderware Training

3. Rename the object as XYPlatform. Remember to use the naming convention discussed
earlier.
Note: Remember to ALWAYS preface the object name with your FIRST and LAST
initial.(e.g., if the user is John Burns, Valve would be JBValve) This will eliminate problems
when we deploy our objects in a common galaxy later in the course.
3-45
3-46
Module 3 The Galaxy
At this point we will work with XYPlatform and configure it.

4. Double-click on the XYPlatform to open the Editor.
There is nothing to configure at this point. The Network Address is to be the name of the
computer where we want to deploy the platform. This is the first Platform created so it will pick
up the Node Name by default. Any subsequent platforms that are created will need to have the
Network Address configured.
Accept the default values for the other parameters
Wonderware Training

5. To properly close an editor when no changes were made, or when the changes made are to
be discarded, it is better to use the X Close button (the lower one) than the Save and Close
the editor button.
6. In the Model View, assign the Platform to the System Area.
Deploying the Object

7. Go to the Deployment View. Right-click on the Platform object and select Deploy.
3-47
3-48
Module 3 The Galaxy

8. Verify the Initial Scan state is set to OnScan and click OK.
9. Click Close to close the dialog box once deployment is complete.
The Application Views will now display the object in its deployed state.
Wonderware Training

Using the Object Viewer - Platform
10. Open the Object Viewer by right-clicking on the Platform and selecting View in Object
Viewer.
Or
Select Object/View in Object Viewer from the Object menu.
3-49
3-50
Module 3 The Galaxy

Upon opening the Object Viewer tool we can see the three panes comprising the layout.
Deployed Objects section
Objects deployed on the Platform.
Attributes section
Individual attributes of the object.
Attribute Monitoring section Location

for monitoring attribute activity.
11. Right-click in the Attribute Monitoring section and select Rename Tab.
Wonderware Training

12. In the Rename Tab dialog box type in Platform1 Statistics and click OK. (Leading initials are
not needed here.)
13. Right-click on the attribute Area in the Attribute section of the Object Viewer and select Add
to Watch.
3-51
3-52
Module 3 The Galaxy

14. Right-click on the following additional attributes in the Attribute section and select Add to
Watch.
z
CPULoad
DiskSpaceFree (enter a -1 as an array index to get all disks on the system)
RamAvailableAvg
15. Select File/Save Watch List from the File menu.

Note: It is necessary to click the Attribute Monitoring section for this to be available.
16. Select Program Files/ArchestrA/Framework/Bin and click Save to save the file as
XYWatchWindows01 where XY are the initials of your first and last name.
Note: Your instructor may have you save this in a different location.
Wonderware Training
3-53
3-54
Module 3 The Galaxy
Wonderware Training

Introduction
An Engine object is not a physical entity. Rather it represents a logic engine that hosts your
process devices. It is important to start with this object in Model View as it represents the base
object on which all the process devices will be placed. When you have modeled all the process
devices that the engine will host, you can then go into deployment view to assign the engine to a
platform.
This lab will illustrate the steps necessary to create an Engine instance from the Template
Toolbox, configure the objects and deploy them.
Objectives
z
Create an instance of an Engine.
Assign the instance of the Engine to the System area in Model View and to the Platform
in the Deployment View.
Deploy the instances.
3-55
3-56
Module 3 The Galaxy

Tasks
Create an Instance of an Engine
1. In the Model View, create an instance of AppEngine by dragging and dropping an
AppEngine from the Template Toolset to the Application Views area.
2. Rename the Engine using the agreed upon naming conventions.
Wonderware Training

3. In the Model View, reassign the Engine to the XYSystem Area.
4. In the Deployment View, reassign the Engine to the Platform.
5. In the Deployment View, reassign the Plant and all the areas to the Engine since all Areas
must run on an Engine.
6. Double click on the Engine to view its editor.
3-57
3-58
Module 3 The Galaxy
On the General tab, notice the Scan period. This is indicating how often the Engine will try to
execute all objects underneath it. This can be quite important depending on the size of your
application
You can now close the editor.
Now that an Engine has been created we are ready to deploy the object.
Deploying the Object

7. Right-click on the Engine object and select Deploy.
Wonderware Training

8. Verify that OnScan and Cascade Deploy are checked and click OK.
The Application Views will now display the objects in their deployed state.
3-59
3-60
Module 3 The Galaxy
Using the Object Viewer Engine Statistics

10. Open the Object Viewer for the Engine again by right-clicking on the Engine and selecting
View in Object Viewer.
Wonderware Training

Or
11. If you previously closed the Object Viewer, then from the Menu bar select File/Load Watch
List and select the Watch List saved from the previous lab, XYWatchWindows01.
12. Right-click in the Attribute Monitoring section and select Add Watch Window.
13. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab
dialog box enter Engine1 Statistics and click OK.
3-61
3-62
Module 3 The Galaxy
14. Right-click on the following attributes in the Attribute section and select Add to Watch.
z
Area
Host
ScanState
ScanStateCmd
15. Select File/Save Watch List from the File menu and click Save.
Note: Your instructor may have you save this in a different location.
Wonderware Training
Module 4
Modeling Equipment
Section 1 Application Objects
4-3
4-7
4-19
Lab 7 DiscreteDevices - Valve Instance
4-29
4-2
Wonderware Training

Section Objectives
z
Be familiar with Automation Objects that represent some element of your application.
Understand their hosting and containment relationships.
Introduction
AnalogDevice Object
This object can act as either an Analog Input (with optional Output) or as an AnalogRegulator that
provides an external representation of a PID controller that exists elsewhere (typically a PLC or
DCS).
The AnalogDevice can be configured to have a personality of one of the two basic types:
z
Analog a basic Analog Input or Analog Output
AnalogRegulator an analog controller that represents an external PID controller
When configured as Analog, this Template is very similar in functionality to the Analog Tag within
InTouch today. Just as the InTouch Analog can be configured for Read or ReadWrite, the
Archestra AnalogDevice configured as type Analog can be configured as an analog input (with no
output capability) or as an analog output (with output capability). The Analog supports the basic
alarming capabilities of level alarms, ROC alarms and deviation alarms from a SP target value. In
addition, the Analog in ArchestrA provides additional functionality such as PV override enable, PV
mode (auto, manual), bad PV alarming, and separate output reference capability.
When configured as an AnalogRegulator, this Template provides both PV and SP monitoring of an
external PID controller. It provides SP output capability with an optional separate feedback
address for the SP. Other controller-oriented features include controller mode (manual vs
cascade). All the alarm capabilities of the more basic AnalogDevice object are included, with the
difference that the SP value for deviation alarms is based on the SP value read from the controller.
Some of the common features of the AnalogDevice regardless of type (Analog or
AnalogRegulator) are:
z
Supports optional scaling of input and output, both linear and square root conversions.
Supports HiHi, Hi, Lo, and LoLo level alarms on PV with both value and time
deadbanding.
Supports Rate of Change (ROC) alarming on PV for both positive-slope and negativeslope ROC.
PV Override when true, allows the PV to be written by a user if the PV mode is set to
Manual.
Adds SP read and write capability with optional separate read-back address. For data
integrity, the value of SP always represents the value read from the external controller, not
the requested SP that is output to the external controller.
Supports minor and major deviation alarming when PV deviates from SP.
Controller Mode When in Cascade, the SP can only be written by other objects. When in
Manual, a user can write the SP. When None, anything can write to it.
Control Tracking optional capability to read a Boolean control track flag from an external
device or object. When tracking is on, the SP is pure read-only and cannot be changed.
4-3
4-4

DiscreteDevice Object
A Discrete Device is a general purpose Object that is used to represent a large class of physical
equipment common in manufacturing such as pumps, valves, motors, and conveyors. These
devices have two or more physical states (e.g. Open, Closed, Moving), and are optionally
controlled using a combination of discrete outputs. Their actual state is monitored via a
combination of discrete inputs.
The meaning of the states depends on the kind of Discrete Device. In the case of a pump, the
states might be configured as Off and On, while for a valve they might be configured as Open,
Closed, or Moving. Note that a control valve has a continuous position represented by 0 to
100% and is not typically represented with a Discrete Device, since its state is represented by a
continuous signal rather than discrete signal.
When a Discrete Device is commanded to a new state, it sets an appropriate combination of
discrete outputs for that state. When its monitored discrete inputs change, the Discrete Device
determines the new actual state of the equipment and sets the PV (process variable)
appropriately.
Through the use of the Discrete Device the operator is guaranteed that a value displayed on the
screen is a good and reliable value. This object will automatically display the state as Bad if the
quality of any of the inputs is bad or the inputs are in an invalid combination determined at
configuration time by the application developer.
Some of the features of the Discrete Device object are as follows:
z
Input and Output states of the DiscreteDevice object are totally independent of each other
and can be configured as required by the users application.
Input and Output can be linked by alarms, which allow the object to detect
CommandTimeout and UncommandedChange alarms, when devices unexpectedly
change, or fail to change when commanded.
Supports devices with two to three commandable states (Passive, Active1, and
Active2) plus two additional states Fault and InTransition which cannot be commanded.
All those states with the exception of InTransition and 'Passive' can trigger a state alarm.
Supports the three input modes Auto, Manual, and Simulate.
Supports the two control modes Manual and Cascade.
CtrlTrack allows a PLC to notify the Discrete Device that the PLC is in control of the state
of the actual physical device, and is no longer accepting commands. If configured this
way, the Command attribute of the DiscreteDevice object just tracks PV (i.e., the state
indicated by its inputs).
Device Integration Objects

A DeviceIntegration object (DIObjects) is an AutomationObject that represents the communication
with external devices. DIObjects run on an AppEngine, and include DINetwork Objects and
DIDevice Objects. A DIDevice Object is a representation of an actual external device (for example,
a PLC or RTU) that is associated with a DINetwork Object. A DINetwork Object is a representation
of a physical connection to a DIDevice Object via the Data Access Server.
Wonderware Training

Hosting and Containment Relationships
Host relationships are displayed in Deployment View.
Galaxy
Plant
Engine
Area
Application Objects
DI Objects
Containment relationships are displayed in Model View.
Areas
Areas
Application Objects
Application Objects
4-5
4-6
Wonderware Training

Introduction
This lab will illustrate the steps necessary to create a DeviceIntegration Object instance and
configure its connectivity. From the IDE, the Template Toolbox, the Application View and the
object editor will be used to create and configure the required DeviceIntegration Object
Objectives
z
Create an instance of the DeviceIntegration Object.
Configure the instance of the object using the object editor.
Note: FOR THIS LAB ONLY!!! This time we will NOT preface the object name with your FIRST
and LAST initial. Again, this is for THIS LAB ONLY!
4-7
4-8

Tasks
Create Instance of DeviceIntegration Object
In order for application objects to communicate with external devices such as PLCs,
DeviceIntegration objects need to be properly configured. To accomplish the communication of our
Application Objects we use the $DDESuiteLinkClient object.
There needs to be an instance created of the object $DDESuiteLinkClient. This object will be
assigned to our System Area and renamed InControl.
Note: For this object DO NOT preface it with your initials. When we deploy our objects in a
common galaxy later in the course there will be only one instance of a PLC on a given Galaxy and
all references need to be to the object without any initials.
1. In the Model View, create an instance of the DDESuiteLinkClient object.
2. Rename the object InControl.
Wonderware Training

3. Double-click on the DDESuiteLinkClient object to open the DDESuiteLinkClient editor.
4. With the General tab selected, configure as follows:

Server Node:
<ask your instructor>
Server Name:
RTEngine
Communication Protocol:
SuiteLink
4-9
4-10

5. Select the Topic tab.
6. At the Available Topics section, click on the
Wonderware Training
icon and add a topic called Tagname.

7. We are now going to import a set of attributes from a csv. file. Your instructor will advise you as
to the location of the file. At that point you will want to copy the file to your hard drive for easier
access.
At the Associated Attributes for Tagname section, click on the
Tagname.ItemList icon
. The Open dialog box will appear.
Select the IAS InControl Address List.csv file and click Open.
A list of attribute names and InControl addresses will be loaded into the DDESuiteLinkClient
object.
4-11
4-12
8. Save and close the editor.
Wonderware Training

9. The Check In dialog box appears.
10. Enter Initial configuration and setup in the Comment field and click OK.
4-13
4-14
11. In the Model View, assign InControl to the XYSystem Area.
12. In the Deployment View, assign InControl to the XYAppEngine.
13. Deploy InControl.
Wonderware Training
14. Verify the Initial Scan State is set to OnScan and click OK.
4-15
4-16

Upon completion of the deployment the object will appear as follows:
15. Right-click on InControl and select View in Object Viewer.
Wonderware Training

dialog box enter InControl and click OK.
18. In Object Viewer add the following attributes to the Watch List to verify the correct values:
z
ServerNode
ServerName
CommunicationProtocol
ScanGroupList (enter a -1 as an array index to get all Lists on the system)
ConnectionStatus
4-17
4-18
Wonderware Training

Introduction
At this stage of the automation project, you have a device list and will begin to model the process
devices. Model View is the most important at this stage as it will allow you to describe the
relationship between complex objects like tanks and valves.
This lab will illustrate the steps necessary to create an Application Object instance from a
AnalogDevice template and connect to InControl. From the IDE the Template Toolbox, the
Application View and the object editor will be used to create and configure the required
AnalogDevice.
Objectives
z
Create an instance of the AnalogDevice.
Configure the instance of the object using the object editor.
Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.e.g., if
4-19
4-20

Tasks
Create and Configure an Analog Device Instance
1. In the Model View, create an instance of AnalogDevice by dragging it from the Template
Toolbox to the Application Views pane, and rename it XYLIT.
2. Assign the AnalogDevice object to Line1.
3. In the Deployment View, verify the AnalogDevice object will deploy on the Engine as
assigned to Line1.
Wonderware Training
4. Double click on the AnalogDevice object to open the AnalogDevice editor.
4-21
4-22

5. Select the I/O tab.
6. Click the ellipsis button
Wonderware Training
to open the Attribute Browser dialog box.

7. From the left pane select the InControl object.
From the right pane select Tagname.Txxy_LT_PV where xx is your Student number and y is
the Tank System number (0 or 1 only). Then click OK.
The PV input source should now contain InControl.Tagname.Txxy_LT_PV.
9. The Check In dialog box will appear. Enter Initial configuration and setup in the Comment
field. Then click OK.
4-23
4-24
10. Right-click on the Analog Object and deploy it.
Wonderware Training

11. Select OnScan then click OK.
4-25
4-26

13. Open the Object Viewer by right-clicking on the Analog Device and selecting View in Object
Viewer.
Or
Wonderware Training

dialog box enter LIT and click OK.
16. In Object Viewer add the following attributes to the Watch List to verify the correct values:
z
PV
4-27
4-28
Wonderware Training

Introduction
This lab will illustrate the steps necessary to create an Application Object instance from a
DiscreteDevice template and connect to InControl. From the IDE the Template Toolbox, the
Application View and the object editor will be used to create and configure the required
DiscreteDevice.
Objectives
z
Create a new instance of the Application objects from the Template Toolbox.
Configure the instance for proper I/O.
Use the Object Viewer to verify the configuration of objects.
4-29
4-30

Tasks
Create Valve
1. Create an instance of the DiscreteDevice object by dragging it from the Template Toolbox to
the Application Views section.
2. Rename the object XYInletValve.
Wonderware Training

3. In the Model View, assign XYInletValve to XYLine1.
4. Double-click on the XYInletValve instance to open its editor.
5. On the General tab, enable XYInletValve for Inputs and Outputs. Check the box for Enable
inputs and Enable outputs.
4-31
4-32
6. Select the States tab.
Wonderware Training

7. Configure the States as follows
Check the Enable transition state box.
Configure the State names as:
Passive state:
Closed
First Active state:
Opened
Transition state:
Traveling
Fault state:
Fault
8. Select the Inputs tab.
4-33
4-34

9. Configure the Inputs as follows
Number of Inputs:2
Combinations
Input 2
Input Name: CLS
Input Source Reference: InControl.Tagname.Txxy_IV_CLS
Where XX = student # {01, 02, 03}
Y = Tank # {0, 1}
Input 1
Input Name: OLS
Input Source Reference: InControl.Tagname.Txxy_IV_OLS
Y = Tank # {0, 1}
Input to PV Map
0 0
Traveling
0 1
Opened
1 0
Closed
1 1
Fault
Wonderware Training
4-35
4-36

10. Select the Outputs tab.
Configure the Outputs as follows

Number of Outputs:
leave as 1
Commandable States
Output1
Output Name: CmdOpen
Output Destination Reference: InControl.Tagname.Txxy_IV_CmdOpen
WhereXX = student # {01, 02, 03}
Y = Tank # {0, 1}
Opened check box
Wonderware Training
checked
11. Save and Close the editor.
12. The Check In dialog box will appear. Enter Initial configuration and setup in the Comment
field. Then click OK.
4-37
4-38
Wonderware Training

13. Right-click on XYInletValve and select Deploy.
4-39
4-40

14. Verify OnScan is select then click OK.
Note: Now that the Initial Scan state of On Scan has been circled to point out its location a
few times, it is expected that in subsequent Deployments that you not need the circle to
remind of its location.
Wonderware Training

16. Open the Object Viewer by right-clicking on the Valve and selecting View in Object Viewer.
4-41
4-42

Or
dialog box enter InletValve and click OK.
19. Verify XYInletValve is selected and view the attributes associated with this object.
Add the following attributes to the Watch List and verify their values:
z
CLS.Value
OLS.Value
PV
Cmd
Wonderware Training

20. Double-click the Cmd attribute to open its editor.
21. Change the state of the Valve and click Apply, then OK.
Notice the other changes as a result of this modification.

Note: the PV.CLS.Value and PV.OLS.Value attributes holds the actual values coming from the
field and are being mapped to the PV attribute.
4-43
4-44
Wonderware Training
Module 5
Complex Object Modeling Extending the Objects

Section 1 Object Relationships
Section 2 Object Change Control and Propagation
Section 3 UDAs and Scripts
5-5
5-9
5-37
5-39
5-49
Lab 10 Object Reuse
5-79
Lab 11 Averager
5-87
Section 4 Extensions and Output Functionality

Lab 12 Extensions
Section 5 Additional Application Objects
5-99
5-103
5-109
5-2
Wonderware Training
5-3
Module Objectives
z
Be able to comprehend how templates can be derived and understand the effect of
locking the attributes of those templates.
5-4
Wonderware Training

Section Objectives
This section will familiarize you with how to derive a template and lock its attributes.
Planning for Object Templates

One of the major benefits of Industrial Application Server is that it allows you to re-use existing
engineering. Working with templates is the best way to illustrate such capability.
A template is an entity that represents the common functional requirements of a field device
(valves, pumps), a group of field devices (skids, stations), or a user function (algorithms). These
requirements reflect information such as number of Inputs and Outputs, alarm conditions, history
needs, and security. One object template performs the equivalent functions of multiple InTouch
tags and scripts.
A template is created either from a base template or from another derived template. Base
templates are the objects provided with the Industrial Application Server. Base templates cannot
be modified.
Note: You should avoid creating instances directly from base templates, since you will not be able
to take advantage of advanced configuration and maintenance capabilities.
The fourth step in the workflow is to determine the templates that you will need. A template is an
element that contains common configuration parameters for objects that are used multiple times
within a project. Templates are instantiated to represent specific objects within the application.
Both the templates and the instances created from them are called ApplicationObjects.
For example, you might need multiple instances of a valve within your application, so you would
create a valve template that has all of the required properties. This allows you to define once, and
reuse multiple times. If you change the template, the changes can be propagated to the instances.
You can use simple drag-and-drop within the IDE to create instances from templates.
5-5
5-6

The Industrial Application Server is shipped with a number of pre-defined templates to help you
create your application quickly and easily. Review these templates and determine if any of their
functionality match the requirements of the devices on your list. If not, you can create (derive) new
templates from the supplied UserDefined templates.
For your project planning, document which existing template can be used for which objects, and
what templates you will need to create yourself.
A child template that you derive from a parent template can be highly customized. You can
implement user-defined attributes (UDAs), scripting, and alarm and history extensions.
Note: You can use the Galaxy Dump and Load Utility to create a .CSV file, which you can then
modify using a text editor and load back into the galaxy repository. This allows you to make bulk
edits to the configuration quickly and easily.
Deriving a Template
Templates are either derived from Base Objects, existing templates or created within the
ObjectToolkit and imported.
Base templates cannot have their attributes configured. However, a template can be derived from
one of the base templates. That derived template can then be configured and customized for
attributes unique to the object it is modeling. Once that derived template is configured, instances
of it can be created. Each instance will have all the attributes of the derived template.
Upon derivation the new template is created within the default toolset. The new template is created
and placed into rename mode. The new template will inherit all attributes and associations of the
original template that were locked. If the default toolset does not exist then the system will create it
when the derived template is created. Creating a derived template is available from the Template
Toolbox and the Derivation view as well as by using keyboard shortcut keys.
When creating an instance of an object that object instance will need to be configured
independently. When deriving a template an instance of the template is created that takes on all of
the attributes of the template from which it was created. This propagation of objects of a like kind
can have a tremendous impact on the ability to create multiple instances of template derived
objects containing fully replicated attributes.
Wonderware Training
Leveraging of Template Instances

To derive a Template from another one, do the following:
1. Select the Template in the IDE the new Template is to be derived from.
2. Right-click the selected Template and click Derived Template on the Create submenu of the
context menu. The new Template is created, placed in the same toolset as the original
Template, and set in rename mode.
3. Rename the derived Template.
Note: The new Template is created in the Galaxy in a checked in state. It can be viewed in the
Template Toolbox or in the Derivation View of the Application Views pane.
Template Containment
Template containment allows more advanced structures to be modeled as a single object. For
example, you might derive from the UserDefined template a new template called "Tank" and use it
to contain ApplicationObjects that represent aspects of the tank, such as pumps, valves, and
levels. You could derive two DiscreteDevice template instances called "Inlet" and "Outlet" and
configure them as valves, derive an AnalogDevice template instance called "Level," and then
contain them within the Tank template. The containment hierarchy would be as follows:
5-7
5-8
Wonderware Training

Introduction
This is the point in the automation project that you begin to develop tools to save you time. You
have noted that the device list has many duplicates and you can use this to your advantage by
building all those common properties into a template device then using it as a cookie cutter to
quickly build all the similar objects.
This lab will illustrate the steps necessary to create new toolsets and derive templates. An
instance of a newly created template will then be created and deployed. The Object Viewer will
be used to monitor the activity once the instance has been deployed.
We will derive a TankSystem template from a set of new templates which we will create. Initially
we will create a Valve from a Discrete Device template, a Pump from a Discrete Device
template and a LevelMeter from an Analog Device template. Then we will derive our InletValve
and OutletValve template from our Valve template, a TransferPump template from our Pump
template and an LIT template from our LevelMeter template. These objects will be used to model
our TankSystem from which we will then create an instance of the template and configure it with
the desired IO and monitor the results in the Object Viewer.
For this lab we will use a simple Tank System as shown in the following diagram. We will build our
base templates first (e.g., Valve), then build our specialized templates (e.g., InletValve,
OutletValve).
TransferPump 01_ CmdStart

TransferPump 01_ AuxContact
Transfer Pump
TANKXXY
Inlet Valve
XX = Student # {01,02,03}
Y = Tank # {0,1}
Valve01 _CLS
Valve01 _OLS
Valve01 _CmdOpen
TANK
Tank Level
LIT01 _PV
Outlet Valve
Valve02 _C LS
Valve02 _OLS
Valve02 _C mdOpen
5-9
5-10

Objectives
z
Create a new Toolset.
Derive a TankSystem Template, an InletValve Template, an OutletValve Template, a

TransferPump Template and an LIT Template
Configure the Templates
Create instances of the Templates.
Use the Object Viewer to verify the configuration of objects.
the user is John Burns, Valve would be JBValve) This will eliminate problems when we deploy
our objects in a common galaxy later in the course.
STOP!
Youve read the Note above about prefacing your object names with your initials when you began
every other Lab. For this lab it is ABSOLUTELY IMPERATIVE that you adhere to this naming
convention. Later in this course when we migrate to a multi-user galaxy each Tank that is built
from this Lab must have a unique name. Therefore, please remember to preface the Tank you are
building in this Lab with your initials.
Wonderware Training

Tasks
Create New Toolset
1. Select Galaxy/New/Template Toolset to create a new Toolset in the IDE on the menu bar
or
Right-click on the Template Toolbox Group heading and select New Toolset.
This will display the New Toolset dialog box.
2. Enter XYToolset in the Toolset Name field where X is your First initial and Y is your Last initial.
Click OK.
The new Toolset object is now displayed in the Template Toolbox.
5-11
5-12
Create a Valve Template

Instead of creating an instance of a template we now are going to derive a template from a
$DiscreteDevice object.
3. Right click on $DiscreteDevice in the Template Toolbox and select New/Derived Template.
Wonderware Training
4. Rename the object to XYValve (where XY are your initials) and move it to your Toolset.
Note: Theres no need to type the $ character at the beginning of the name. It will be added
automatically by the IDE.
5-13
5-14

5. Double-click on the Valve template to open its editor.
6. On the General tab, check the box for Enable inputs and Enable outputs to enable the
Valve to Inputs and Outputs.
Wonderware Training

7. Select the States tab. Configure the States as follows
Check the Enable transition state box.
The State names as:
Passive state:
Closed
First Active state:
Opened
Transition state:
Traveling
Fault state:
Fault
5-15
5-16

8. Select the Inputs tab. Configure the Inputs as follows
Number of Inputs:2
Combinations
Input 2
CLS
Input 1
OLS
Input to PV Map
0 0
Traveling
0 1
Opened
1 0
Closed
1 1
Fault
Wonderware Training

9. Select the Outputs tab. Configure the Outputs as follows
Number of Outputs:
leave as 1
Commandable States
Output1
Opened check box
CmdOpen
checked

At the Check In dialog box, enter Initial configuration and setup in the Comment field and
click OK.
5-17
5-18

Create the Pump Template
11. Right click the $DiscreteDevice template in the Template Toolbox and select New/Derived
Template.
12. Rename the new template XYPump (where XY are your initials) and move it to your Toolset.
13. Double-click on the Pump template to open its editor. On the General tab, check the Enable
inputs box and the Enable outputs box
Wonderware Training
14. Select the States tab. Configure the States as follows

Configure the State names as:
Passive state:
Stopped
First active state:
Running
Fault state:
Fault
5-19
5-20

15. Select the Inputs tab. Configure the Inputs as follows
Number of Inputs:
leave as 1
Combinations
Input1
AuxContact
Stopped
Running
Wonderware Training

16. Select the Outputs tab. Configure the Outputs as follows
Number of Outputs:
Commandable States
Output1
Running check box
CmdStart
checked

click OK.
5-21
5-22

Create a LevelMeter Template
18. Right click on the $AnalogDevice template in the Template Toolbox and select New/Derived
Template.
19. Rename the new template XYLevelMeter (where XY are your initials) and move it to your
Toolset.
Wonderware Training
Note: No specific configuration is necessary at this point for the LevelMeter template.
Subsequent labs will use this template to customize other parameters for the Level Meter.
5-23
5-24

Build Containment to Represent the Tank Systems
Now we will make a containment assignment by assigning several of our templates to a
TankSystem. Derived templates from Valve, Pump and Level Meter are created to build the
TankSystem even when theres no customization on the new objects. Valve, Pump and Level
Meter are left as general templates to implement other valves, pumps and level meters in the
application.
Note: As a general rule and a good practice, never use empty objects in your model. Our
TankSystem will be extended later.
20. Right click on the $UserDefined template in the Template Toolbox and select New/Derived
Template.
Rename the new template XYTankSystem (where XY are your initials) and move it to your
Toolset.
21. Right click on the $XYValve template in the Template Toolbox and select New/Derived
Template.
Name your new template $XYInletValve.
Move $XYInletValve into $XYTankSystem. $XYInletValve is now contained in
$XYTankSystem.
Wonderware Training

22. Right click on the $XYValve template in the Template Toolbox and select New/Derived
Template.
Name your new template $XYOutletValve and move it into $XYTankSystem
23. Right click on the $XYPump template in the Template Toolbox and select New/Derived
Template.
Name your new template $XYTransferPump and move it into $XYTankSystem
24. Right click on the $XYLevelMeter template in the Template Toolbox and select New/Derived
Template.
Name your new template $XYLIT and move it into $XYTankSystem
5-25
5-26

Create and Configure a TankSystem Instance
25. Create an instance of the $XYTankSystem object by dragging it from the Template Toolbox
to the Application Views pane, and leave the default name XYTankSystem_001. Verify that
you are in the Deployment View of the Application Views.
Note: Notice that all of the contained objects have a name in square brackets following the
object name.
26. Assign XYTankSystem_001 to the XYLine1 Area.
Wonderware Training

Configure the InletValve
27. Double-click on the XYInletValve_001 to open its editor. Notice that all the configuration
made at the $XYValve template is present in the derived instance.
Select the Inputs tab. Configure the Input Source Reference as follows
Input Source References
Input 2 CLS
Input Source Reference
InControl.Tagname.TXXY_IV_CLS
Input 1 OLS
Input Source Reference
InControl.Tagname.TXXY_IV_OLS

Y = Tank # {0, 1}
5-27
5-28

28. Select the Outputs tab. Configure the Output Destination Reference as follows
Output Destination References
CmdOpen
InControl.Tagname.TXXY_IV_CmdOpen
Y = Tank # {0, 1}
Opened check box
Wonderware Training
checked

click OK.
Now you can see as represented by the icon for XYInletValve that the reference has been
resolved.
Configure the OutletValve

30. Double-click on the XYOutletValve_001 to open its editor. Select the Inputs tab. Configure
the Input Source Reference as follows
Input 2 CLS
InControl.Tagname.TXXY_OV_CLS
Input 1 OLS
InControl.Tagname.TXXY_OV_OLS
Y = Tank # {0, 1}
5-29
5-30
Wonderware Training

Output Destination References
CmdOpen
InControl.Tagname.TXXY_OV_CmdOpen
Y = Tank # {0, 1}
Opened check box
checked

click OK.
5-31
5-32

Configure the TransferPump
33. Double-click on the XYTransferPump_001 to open its editor. Select the Inputs tab.
Configure the Input Source Reference as follows
AuxContact
InControl.Tagname.TXXY_TP_AuxContact
Y = Tank # {0, 1}
Output Source References
CmdStart
InControl.Tagname.TXXY_TP_CmdStart
Y = Tank # {0, 1}
Wonderware Training

click OK.
Configure the LIT Object

36. Double-click on the XYLIT_001 to open its editor. Select the I/O tab.
Configure the PV input source as InControl.Tagname.TXXY_LT_PV

click OK.
Now all the references have been resolved as indicated by the icons represented for each of
the objects.
5-33
5-34

Deploy and Test the TankSystem Object
38. Right-click on your XYTankSystem_001 instance and select Deploy.
Verify that Cascade Deploy is checked and the Initial Scan state is set to On Scan. Then
click OK.
39. Right-click on the XYTankSystem_001 and select View in Object Viewer to view the object
attributes in Object Viewer.
dialog box enter Tank and click OK.
Wonderware Training

42. Add the following attributes to the Watch List to test the object.
For XYInletValve_001 add:
z
Cmd
PV
For XYOutletValve_001 add:

z
Cmd
PV
For XYTransferPump_001 add:

z
Cmd
PV
For XYLIT_001 add:

z
PV
44. Experiment with the objects double clicking the Cmd attributes to command the InletValve,
OutletValve and TransferPump. Note the changes in the other attributes as a result of these
operations.
5-35
5-36
Wonderware Training

Section Objectives
z
Familiarize you with the concept of attribute locking, and
Enable you to understand how locking attributes can propagate to previously derived
instances.
Locking an attribute in a Template indicates that its value is to be logically shared with all derived
objects (Templates or instances). In other words, when the value changes in the template, that
change is propagated to all the derived children of the object. When an attribute is locked in the
Template, the value can be changed in that Template but not in any of the derived children.
Based on this concept, an attribute can have one of three logical lock types:
z
Unlocked: Both Templates and instances can have these. Attribute is read-write. The
object has its own copy of the attribute value and is not shared by derived objects.
Locked: Only Templates can have these. Attribute value is read-write. Derived objects
dont have a unique copy of the attribute value, but instead share the locked one (it is
Locked In Parent see next item). By changing the value of a locked attribute, the logical
value of that attribute is updated in all derived objects.
Locked In Parent: Both Templates and instances can have these. Attribute is read-only.
The object does not have a unique copy of the attribute value, but references the one in
the ancestor in which the attribute is Locked.
Locking an Attribute
5-37
5-38

To lock a Template attribute, do the following:
1. Select the desired Template in the IDE and launch its editor.
2. Enter a value in an attribute field in the objects editor.
3. Select the locking mechanism for that attribute. Some editors may have lock icons associated
with certain edit fields, but this possibility is within the scope of the developer of the objects
editor.
4. Save and close the object editor.
The locked attribute in any derived templates and instances created from this template are locked
and unavailable. To test this, you can derive a new template or create an instance from the original
template, and then check the new objects editor. The locked attribute is unavailable for editing.
Unlocking an Attribute
To unlock a Template attribute, do the following:
1. Select the desired Template in the IDE and launch its editor.
2. Select the locking mechanism for the locked attribute in the objects editor. Some editors may
have lock icons associated with certain edit fields, but this possibility is within the scope of the
developer of the objects editor.
3. Save and close the object editor.
The previously locked attribute in any instances created from this template are now unlocked. The
previously locked attribute in any templates derived from this template are now Locked (in me).
The previously locked attribute in any instances of derived templates remain in Locked in Parent.
Wonderware Training

Introduction
This lab will illustrate how simply by locking certain attributes, we can propagate that change to the
objects that were derived from it.
Objectives
z
Modify template attributes by locking them for change propagation.
Monitor the changes that are propagated to the object instances that were derived from
the template object.
5-39
5-40

Tasks
Lock the Valve
1. Double-click the $XYValve template to open the DiscreteDevice editor.
On the General tab lock:
z
Enable inputs
Enable output
2. On the States tab lock:

z
Enable second active state
Enable transition state
State names
Wonderware Training

3. On the Inputs tab lock:
z
Number of Inputs
Input Name
Input to PV Map
5-41
5-42

4. On the Outputs tab lock:
z
Number of outputs
Output Name
Closed
Opened
Wonderware Training

click OK.
Notice that the instances that were created from this template have icons now indicating
configuration has changed and the object needs to be redeployed. We will deal with this later.
5-43
5-44

Lock the Pump
6. Double-click the $XYPump template to open the DiscreteDevice editor.
z
Enable inputs
Enable output
7. On the States tab lock:

z
Enable second active state
Enable transition state
State names
Wonderware Training

8. On the Inputs tab lock:
z
Number of Inputs
Input Name
Input to PV Map
9. On the Outputs tab lock:

z
Number of outputs
Output Name
Stopped
Running
5-45
5-46

At the Check In dialog box, enter Initial lock configuration in the Comment field and click
OK.
Lock the LevelMeter

11. Double-click the $XYLevelMeter template to open the AnalogDevice editor.
z
Type
Enable analog output
Enable PV override
Enable I/O scaling

At the Check In dialog box, enter Initial lock configuration in the Comment field and click
OK.
Wonderware Training

Check and re-deploy the existing instance
As we pointed out earlier, notice that the derived instances have a re-deploy status icon.
13. Open the editor for any of the instances and check that you can't modify the locked attributes.
14. Close the editor.

15. Re-deploy XYTankSystem_001. Verify that the Cascade Deploy is checked and the Initial
Scan state is set to On Scan.
5-47
5-48
All instance references have now been reconciled with the changes we made in our template
from which those objects were derived.
Wonderware Training

Section Objective
This section will familiarize you with an understanding of the scripting environment and the
various scripting configuration attributes of the ApplicationObject.
User Defined Attributes (UDAs)

UDAs (User Defined Attributes) are part of the ApplicationObject script environment. They allow
users to not only add logic to an existing ApplicationObject but also to expose new behavior via
added (user defined) attributes. More specifically, they allow users to:
z
Add a new attribute to an object.
Configure its data type.
Specify the attribute category.
Set initial values and locks on the new attribute.
Set whether the new attribute is an array and how many elements comprise it.
Set alarms and historization for the new attribute (done on the Extensions page).
Define security and references to other objects (done on the Extensions page).
Note: Note After you add an attribute to an instance, it appears in the Attribute Browser list for use
with the scripting and attribute extension functions.
Put to the extreme, scripts and UDAs can be used to create a completely new type of
ApplicationObject starting from an empty container object that has no behavior / logic itself.
5-49
5-50

The UDAs page is comprised of three main functional areas and a set of function buttons. These
are described below.
When using UDAs in scripting, note the following:

z
When using Calculated and Calculated Retentive UDAs as counters, they must be
manually initialized. For instance, if you use me.UDA=me.UDA+1 as a counter in a
script, you must also initialize the UDA with something like me.UDA=1 or
me.UDA=<some attribute value>.
Calculated UDAs can be initialized in OnScan and Execute scripts (that is, scripts
with those types of Execution Type triggers), but not Startup scripts.
Calculated Retentive UDAs must be initialized in Startup scripts, and can be

initialized in OnScan and Execute scripts. The main purpose of a Calculated
Retentive UDA is to retain the attribute's current value after a computer reboot,
redundancy-related failover, or similar occurrence in which valid checkpoint data is
present. Therefore, your Startup script should contain a statement testing the Boolean
value of the attribute, StartingFromCheckpoint, on the object's AppEngine. If the value
is TRUE, you should not initialize the UDA; if the value is FALSE, you should initialize
the UDA.
Wonderware Training

The ApplicationObject Script
An ApplicationObject script is developed for the purpose of adding behavior to a specific
ApplicationObject. It will execute only when a deployed object containing the script is on scan.
The script isnt directly callable from other scripts (although changing the value of an object
attribute may allow the scripts execution trigger conditions to command script execution). A script
doesnt have the concept of returning a specific value upon execution completion.
An ApplicationObject script is added to an ApplicationObject (template or instance) using the IDE.
The script related information is edited via the script editor. The editor exposes five script types:
If the user selects an Execute type script, the script editor exposes one edit field for an expression
and another edit field for the script code.
The script expression acts as a filter for the invocation of Execute script execution. The expression
is evaluated every time the object that the script is attached to is executed. Dependent on the
evaluation the actual script is triggered or not.
This model is fine for simple scripts that just do some simple calculations. However, as soon as it is
necessary to instantiate external objects and keep them alive across multiple executions of the
script, the simple model falls apart. In order to support those more complex scenarios the script
writer can fill in script code for the Startup() and Shutdown() methods. External objects would be
instantiated in the Startup() method and destroyed in the Shutdown() method. If finer granularity is
needed the OnScan() and OffScan() methods can be used respectively. OnScan() and OffScan()
are invoked whenever the scan state of the object changes to OnScan and OffScan, respectively.
In order to support the just described scenarios the script offers a way to mimic static variables
(e.g., variables holding an instance of an object alive across different execution cycles). This is
accomplished by using a Dim statement in the upper Declarations section of the script editor.
Variables so dimensioned stay alive for the lifetime of the object.
In contrast, Variables dimensioned in the script section are destroyed between calls to the Objects
script. In either case, dimensioned variables are only accessible from within the script. Other
scripts cannot access those variables. Also, there is no means to expose those variables as
attributes of the associated object (e.g., for debugging purposes). To expose these member
variables, they can be set to a UDA.
Due to this tight link between scripts and UDAs, a script has more open access to UDAs (of the
object that the script is attached to) than to any other attribute on the object. It could be said that
UDAs are owned by a script
A script can also leverage UDAs to persist values across different script runs. Therefore, UDAs
allow users that do not want to get exposed to the complexity of script member variables to still
mimic static variables for data types that fit into Application Server attributes.
5-51
5-52

Script Development Environment
Attribute Browser
From within the Script Editor the user can leverage the Attribute-Picker tool to browse through the
attribute namespace of the hosting object and other objects to pick a certain attribute to be
included in the script code. The tool does not distinguish between attributes of on-engine and offengine objects.
Script Function Browser
Like the InTouch script editor, the name of the selected script function and its calling syntax will be
added to the script text when the user picks it in the script function browser. In addition to being
able to insert the function call, the user can also enter a type declaration statement for object
names. In addition, the browser provides the user the ability to distinguish between properties and
methods.
Browsing for COM Objects
Similar to browsing for script functions, the user can also browse for COM objects that have been
imported using the IDE.
Language Syntax Validation
Script language syntax validation is performed by selecting the red check mark above the script
window.
This operation will identify and inform/warn the script developer of any syntax errors in the script. A
script with syntax errors can be saved. However, an object leveraging such a script cannot be
deployed.
Support Script Code Comments
The user can insert comments to document the script code (compare with InTouch QuickScript
comments {your comment here}).
Specifying Attributes within a Script

The following sections describe how internal attributes (attributes of the object that the script is
attached to) as well as external attributes (attributes on other objects) can be referenced from
within a script.
References to both internal as well as external attributes have in common that typically the part
specifying the property is omitted meaning that the value property is meant. In this case only the
value property and the associated quality can be accessed via this attribute reference.
Specifying Internal Attributes

For internal attributes the syntax: me. + <fully qualified local part of the attribute reference> needs
to be specified.
Example:
If me.PV==Open Then
{Do something}
Endif;
Script Examples
The following script examples may be used for reference.
Wonderware Training
Note: Many additional script examples may be located in the IDE Help files under Enhancing an
Objects Functionality/QuickScript .NET Scripting Language/Sample Scripts.
Load an XML Document from Disk and Do Look-ups on It
dim doc as System.Xml.XmlDocument;
dim node as System.Xml.XmlNode;
doc = new System.Xml.XmlDocument;
doc.Load("c:\catalog.xml");
' find the title of the book whose isbn is 044023722X
node = doc.SelectSingleNode("/catalog/book[@isbn='044023722X']/title");
LogMessage(node.InnerText);
' find all titles written by Grisham
for each node in doc.SelectNodes("/catalog/book[author/lastName='Grisham']/
title")
LogMessage(node.InnerText);
next;
Query a SQL Server Database

dim connection as System.Data.SqlClient.SqlConnection;
dim command as System.Data.SqlClient.SqlCommand;
dim reader as System.Data.SqlClient.SqlDataReader;
connection = new
System.Data.SqlClient.SqlConnection("server=(local);uid=sa;database=northwin
d");
connection.Open();
command = new System.Data.SqlClient.SqlCommand("select * from customers",
connection);
reader = command.ExecuteReader();
while reader.Read()
LogMessage(reader("CompanyName"));
endwhile;
reader.Close();
connection.Close();
Create a Look-up Table, Then Do a Look-up on It

dim zipcodes as System.Collections.Hashtable;
zipcodes = new System.Collections.Hashtable;
zipcodes["Irvine"] = 92618;
zipcodes["Mission Viejo"] = 92692;
LogMessage(zipcodes["Irvine"]);
Use DDE to Access an Excel Spreadsheet

WWPoke("excel", "sheet1", "r1c1", "Hello");
WRequest("excel", "sheet1", "r1c1", me.Greeting);
' Note: use "" to embed double quotes in strings
WWExecute("excel", "sheet1",
"[SELECT(""R1C1"")][FONT.PROPERTIES(,""Bold"")]");
Specifying External Attributes

The script developer can specify external attributes in two distinct ways:
5-53
5-54

Inline Specification
Specifying external attributes inline in the script code is equivalent to how internal attributes are
used. The only difference is that in the case of external attributes the fully qualified name
including the global part (i.e. the object name) is required. Relative (e.g., MyContainer.PV) and
hierarchical names (e.g., Tank1.Inlet.Cmd) are also supported in addition to the native name
(e.g., Valve101.PV).
There are cases when the attribute name cannot be specified within the script code without
clashing with the existing script syntax. This case often applies when attributes of a Device object
referring to a data point in an actual physical device need to be referenced. Those attributes
typically use a native item syntax which often makes use of special characters (!, :, ;, etc.) that can
collide with the syntax rules of the scripting language.
To account for those cases QuickScript .NET supports the specification of an attribute reference in
the form:
Attribute(<attribute name>)
The following script snippet demonstrates its usage:
If Attribute(PLC5.Fast.N10:5) == True Then
{Do something}
Endif;
While inline specification of external attributes is very convenient (you just type in the name or pick
the right name using the attribute browser), it imposes restrictions when used in scripts attached to
templates.
Consider the following script snippet:
Valve101.ControlMode=Auto;
Valve101.Cmd=Open;
Valve101.ControlMode=Cascade;
If this script is attached to a template and the script code (script text) is locked in the template, then
any instance of this template can only meaningfully work if there is a Valve101 obviously a bad
design of the script.
The script environment offers two solutions for this problem:
1. Usage of relative names in the script code (e.g., MyContainer.ControlMode=Auto). While this
approach works perfectly in scripts which are locked in a template, it severely constrains the
number of attributes that can be accessed this way.
2. Using aliases in the script code that link to a reference table. This option is discussed in more
detail in the next section.
Inline Attributes Shown with Unique TypeFace

Inline attributes, as interpreted by the script validator, will be shown with a unique Bold typeface so
that the script developer is aware of all references in the script. This will reduce programming
errors and typographical errors that are not intended to be interpreted as attributes but will be if no
other syntax match is found.
Alias Pointing to an Alias Table

Accessing external attributes via an alias into an external attribute reference table is the most
versatile approach when using script code in templates. However, it forces the user to deal with an
indirection.
Wonderware Training

First the user has to specify an alias for an external reference (e.g., PVofInletValve) in the Alias
Reference table (see below). Then the alias can be used directly in the script code:
If PVofInletValve==Open Then
{Do something}
Endif;
This script can be locked in the template without locking down which attribute on what object is
actually used in an instance derived from this template.
The actual mapping to an attribute is done via the Alias Reference table exposed by the script
editor. The table exposes the following fields:
Alias
Reference
PVofInletValve
Valve101.PV
The Alias field is filled in automatically as the script text is parsed.

Note: Aliases do not need to specify the default property Value. Correspondingly the specified
reference does not need to include the property field.
Accessing Properties Other than Value

So far we mainly focused on the typical case when access to the Value property of an attribute is
needed; i.e., the property part of a reference can be omitted. In the rare case when the script
developer needs to access properties other than the value property, a dedicated reference is
needed for every property.
Example: Lets assume we need to read the Value property and the UpperBoundDimension1
property of the external attribute Valve101.PV. Lets further assume that we want to use inline
references. The corresponding code snippet is:
A = Valve101.PV; {reads the Value property}
B = Valve101.PV;.UpperBoundDimension1
{reads the UpperBoundDimension1 property}
The two references Valve101.PV and Valve101.PV.UpperBoundDimension1 are treated

as two completely different references.
Note: Even though the two references Valve101.PV and Valve101.PV.Value (explicitly
specifying the Value property) refer to the same property, they too are treated as two separate
references. Therefore the user should avoid mixing both ways of referring to the Value property in
a given script.
Accessing Array References

Arrays can be accessed either by referencing an individual element of an array or by referencing
the entire array. The individual element is specified by specifying the element within the square
brackets as follows:
Tag.ArrayAttribute[3]
To get an entire array, either of the following syntaxes works:
Tag.ArrayAttribute[-1]
Or
5-55
5-56

Tag.ArrayAttribute
Script Execution Configuration

Each script editor enables configuration of a scripts execution settings. These settings include,
where applicable, execution trigger conditions, execution mode, and execution ordering.
Execution Trigger Conditions

Each script will have a set of execution trigger conditions associated with it. The script type will
determine a set of valid condition types.
Triggers for ApplicationObject Type Scripts

These scripts are constrained to the discrete intervals provided by the Application Engine scan
period. In effect, all event style trigger conditions specified for these scripts are logical AND with
the scan periods. In other words, the script cannot trigger any faster than the scan period of the
Application Engine.
Script Trigger - Periodically

The script will be executed based on a time interval specified by the user. Although this cannot
be determined at configuration time, at run-time, when going on-scan, the execution period will
be rounded up to the nearest multiple of the Application Engine scan period.
A time interval of zero means that the script is executed during every scan.
Note: There is no condition (or expression) specified for periodic script execution. It is
executed at the interval specified, unconditionally.
Script Trigger - While True

While a user configured expression evaluates TRUE.
A time interval is also specified. If non-zero, then at the time interval specified, the configured
expression is evaluated to determine if the script is to be executed. A time interval of zero
renders the time interval unused and causes the expression to be evaluated at the AppEngine
scan period.
Script Trigger - On True

On FALSE to TRUE transition of a user configured expression.
Script Trigger - On False

On TRUE to FALSE transition of a user configured expression.
Script Trigger - On Data Change

The script is triggered whenever the value of a user configured expression changes. The
expression evaluates to a single (not an array) analog type (integer, real, or double). Also, with
OnDataChange the Deadband is now available.
Wonderware Training

Script Trigger While False
While a user configured expression evaluates FALSE.
A time interval is also specified. If non-zero, then at the time interval specified, the configured
expression is evaluated to determine if the script is to be executed. A time interval of zero
renders the time interval unused and causes the expression to be evaluated at the AppEngine
scan period.
Execution Mode
OnExecute() mode scripts can be configured to execute in one of two execution modes,
synchronous or asynchronous. All other script types are always synchronous and cannot be
configured otherwise.
Synchronous Execution
The synchronous mode is the default choice and represents serial script execution by the
ApplicationEngine in the course of calling the Execute method of all ApplicationObjects that are
on-scan in the ApplicationEngine. For satisfactory determinism, this mode requires that all scripts
execute deterministically and quickly enough to prevent an ApplicationEngine over-scan condition.
Asynchronous Execution
The asynchronous mode is used for the class of scripts that perform operations that dont meet the
above speed and determinism criteria. These scripts will be executed on a worker pool of
separate, lower priority threads than the Application Engines primary thread. No support will be
provided to establish prioritization of execution among Asynchronous mode scripts; they will all
receive the same priority.
An asynchronous script running in a separate thread can access ArchestrA attributes via normal
get/set calls. The call is marshaled over to the main engine thread and processed. The calling
thread waits for call return until main thread can process get/set request. This is OK since
asynchronous thread is usually slower and background in nature.
Asynchronous Scripts Only Apply to Execute()

Only script code written for the Execute() method of an object can be declared asynchronous.
Asynchronous Script Trigger Condition Evaluation

If an asynchronous script is currently executing, then the condition for next execution is not
evaluated and it is not executed again. Condition evaluation is always done in main thread of
engine. Therefore, only one copy of a given asynchronous script in an object can be executing at
one time.
Asynchronous Script Execution Ordering with an Object

Specification of execution order for asynchronous scripts within an object is allowed. However, this
ordering just impacts condition evaluation, not execution ordering since asynchronous scripts are
run in separate threads from each other.
Asynchronous Script Worker Threads

The hosting engine creates a pool of worker threads at startup time. These threads are used for
processing asynchronous scripts simultaneously when they are due and their trigger condition is
5-57
5-58

true. Only one script can execute on one thread at a time. If an asynchronous script comes due
and no worker thread is available, it is immediately queued for execution and awaits a free worker
thread. As soon as the worker thread is free from its previous script, it executes the newly queue
script.
A default number of worker threads is to be provided. This is a configurable attribute of the
Engine.
Taking an Object w/ Asynchronous Scripts OffScan

If an object is taken OffScan, either directly, or indirectly because its Engine is taken OffScan, all
in-progress asynchronous scripts for that object are immediately terminated.
Asynchronous Scripts Diagnostics and Attributes

Asynchronous scripts require some additional attributes within the script to provide the following
behavior:
z
Kill attribute - terminates the asynchronous script when written to.
Shutdown attribute simply a Boolean flag that requests the asynchronous script to shut
down on its own. A well-written script will check this command before and after timeconsuming operations.
Running indicator attribute indicates whether the asynchronous script is currently

executing.
Elapsed time attribute indicates the amount of time the asynchronous script has been
executing (if RunningFlag is true).
Asychronous scripts also have the following diagnostic attribute within the engine:
Count of asynchronous scripts running indicates the number of asynchronous scripts

currently executing.
Count of asynchronous scripts waiting indicates the number of asynchronous scripts

currently queued to execute.
Watchdog Timeout
The execution time of both synchronous as well as asynchronous mode scripts is monitored
against a timeout period. All synchronous scripts on an AppEngine share the same timeout period
which is exposed as a configurable attribute of the AppEngine.
In the case of asynchronous scripts a timeout period that is shared for all asynchronous scripts
does not make sense since the needed execution time can vary by orders of magnitude between
different asynchronous scripts. In order to account for this, the timeout period can be separately
configured for each asynchronous script. It is exposed as an attribute of the script.
Attribute Access Support

In order to understand the philosophy of attribute access from within a script it is important to look
at the context that an ApplicationObject Script runs in: All objects running on an AppEngine can be
thought of as a big PLC program. At the beginning of a new scan cycle of the AppEngine all
external input values (values coming from other engines) are read in one block. Then all objects
including any associated scripts are executed. Outputs to objects on other engines are queued up
and are written out once at the end of the AppEngines scan cycle.
Following this philosophy scripts need to have direct read / write access to all attributes exposed
by objects on the same AppEngine that the script is running on. Lets use the following script
snippet to further clarify the behavior:
Wonderware Training

PID.Mode=Auto
PID.SetPoint=50
PID.Mode=Cascade
This script will work independent on whether the PID object resides on the same AppEngine that
the script is executing on (on-engine) or not (off-engine). Each set operation is immediately
executed. If the PID object is on-engine then the set operation changes the value of the
corresponding attribute right away. If the PID object is off-engine then all set operations are
queued up in exactly the order they were issued and are executed at the end of the scan cycle of
the AppEngine (asynchronous set).
Get operations work accordingly. Lets consider the following script code snippet:
{For this example we assume that PID.SetPoint==30 at the start of the script}
If PID.SetPoint==30 then
PID.Mode=Auto
PID.SetPoint=50
PID.Mode=Cascade
Endif;
If PID.SetPoint==50 then
{Do something else}
Endif;
Granted that the PID object exists and its SetPoint can be set to 50 then the second if statement
will always evaluate to true if the PID object is on-engine. However, in the off-engine case both if
statements will never evaluate to true in the same execution cycle of the script.
In other words, when a script performs an attribute set (write) operation followed, at a later point in
the script, by a read of the same attribute, the value written will not be read back if the attribute is
off-engine, rather the attribute value existing when the script commenced execution is returned
instead. In this case, the value written to the attribute will not be returned by a get (read) operation
until succeeding execution scans of the script.
Notes:
z
As described above a script performing read / write operations on the same attribute will
behave differently depending on whether the attribute is on-engine or off-engine. If
necessary, the script developer can avoid this situation by using a local script variable to
manage the attributes value in the course of the scripts execution. At the end of the
script, the value of the local variable is then written to the attribute.
Scripts attached to an ApplicationObject are part of the supervisory control logic. I.e., read
and write operations performed by the script are treated as SupervisoryGets / Sets.
On-Engine Attribute Access

Accesses to attributes of other AutomationObjects in the same engine will be performed in a
blocking (synchronous) fashion and any access errors will be immediately reflected in either the
quality value for a read, or the WriteStatus field for a write, before the next script statement is
executed. The script developer can check the appropriate indicator to determine that an access
operation succeeded before proceeding in the scripts execution.
Off-Engine Attribute Access

When a script accesses an off-engine AutomationObject attribute, the Local Message Exchange/
Network Message Exchange (LMX/NMX) sub-system is the provider of the attribute data. In this
case, LMX/NMX establishes a subscription for the attributes value and maintains the most
recently published value in an on-engine read-only cache. When a script reads an off-engine
5-59
5-60

AutomationObject attribute, the LMX caches most recently published value is provided to the
script. This value will not change during the execution scan of the script.
When a script performs a write to an off-engine AutomationObject attribute, LMX/NMX performs
the operation asynchronously to the scripts operation. If a script reads the same attribute that it
wrote to at a previous point in the script, the script will not see the value previously written until a
succeeding script execution scan cycle. Any errors encountered by LMX/NMX during the
asynchronous write operation are not available to the script during the same execution scan but
will be reported in the attributes WriteStatus field upon status receipt from LMX/NMX. Until this
status is received from LMX/NMX, the WriteStatus field will report a pending status.
Access to Hosting Objects Attributes

Access to attributes of the ApplicationObject that hosts the script is a special case of the on-engine
scenario. The scripting environment distinguishes between two categories of attributes of the
hosting object: Regular attributes (i.e. non UDAs) and UDAs (UDA = User Defined Attribute).
Accessing Regular Attributes (non-UDAs)

In order to maintain the integrity of an object, access to regular attributes from within a script is
limited to whatever access other AutomationObjects have. This constitutes what the object has
been designed for and it must be absolutely avoided that a script could interfere and potentially
break the objects logic.
I.e., access to regular attributes is treated in the same way as access to attributes of other objects
from within the script.
Accessing UDAs
The precautions taken for regular attributes do not apply for UDAs. UDAs are added to an object
for the main purpose of having one or more scripts on this object drive them.
As a result script access to UDAs is treated exactly like the internal runtime access of a primitive to
its attributes. In particular, a script can set the quality property of a UDA on the hosting object.
However, the quality of a UDA is defaulted to GOOD.
On the other hand propagation of quality in calculations is handled in the following manner: In the
expression a = b + c, if b is bad (or initializing), the value of a is not updated and its quality is set to
BAD or (initializing). If the quality of b is uncertain then the calculation is performed, the value of a
is updated and as quality is set to uncertain.
Prevent Accessing Attributes during OnStartup(), OnShutdown()

It is NOT possible for a script to get (read) and set (write) attributes within the
AutomationObject to which the script is attached. This is explicitly prevented and the
script will not validate successfully if the user attempts to place references of any sort in
the OnStartup() or OnShutdown() methods.
Supported Data Types

For referenced attributes, all Application Server attribute types are supported. The attributes are
exposed as objects that expose a value, a quality field, and a WriteStatus field. Therefore, strictly
speaking, Application Server attributes do not constitute a data type. Instead the data type of the
value of attributes is of interest.
Wonderware Training

Data Quality Handling
Two approaches to handling data quality during script execution are employed in the Application
Server script environment. The first approach, Data Quality Controlled Execution (DQCE), is used
by all script expressions and permits expression evaluation only when attributes being read by the
expression have acceptable qualities. The other approach, Data Quality Propagation (DQP), is
used by the script body and propagates the quality of attributes read by the script through the
scripts data as execution occurs.
Quality Handling in Script Expressions

Script expressions are one liners and as such it does not make sense to only execute the part of
an expression that deals with attributes of acceptable quality. I.e., the expression is either
evaluated as a whole or not at all.
If any of the input variables to the expression change to an initializing or bad quality state, the
result value reported will have a quality of initializing or bad (if there exists at least one input with
initializing and another input with bad quality, bad will have precedence over initializing quality and
be reported as the expression results quality). The result value itself is set to the default value for
the given data type (e.g., a result value of type float is set to NaN not a number) when the quality
turns unacceptable.
If the script expression is used as the trigger for the execution of a script and the quality of at least
one referenced attribute is unacceptable (i.e., initializing or bad), then the script is not triggered at
all.
Data Quality Propagation (DQP)

DQP seeks to streamline the script development task when writing scripts that robustly handle
data quality. One of the main differences between DQCE and DQP is that in the latter case the
execution of the script still happens even though some of the referenced attributes might expose
unacceptable quality. In typical cases portions of a given complex script are not affected by the
bad quality of a given attribute and therefore will be executed. As a result the script developer
needs the ability to evaluate the quality of attributes within the script and to react accordingly (e.g.,
by branching into a code segment that causes the system to go into a fail safe mode.)
When using the Application Server scripting language, the script developer should understand the
following rules and behavior:
Only Referenced Attributes Expose Quality

Only referenced attributes expose quality. Local variables do not have a quality assigned. I.e.,
when assigning the value of an attribute to a local variable the quality information is lost.
Example: The following code snippet assumes that A and B are local variables of appropriate data
type.
A = Valve101.PV
{The value of A is now the value of Valve101.PV.Value. The actual name of the
Value property is spelled out for clarity purposes. The variable A just holds
the value, not the quality.}
B = Valve101.PV.Quality
{Another variable can be used to hold the quality information but no local
variable is able to hold the value and the quality information.}
5-61
5-62

Attributes of Bad Quality are set to Default Value
For all attribute references used by a script, the script environment controls the reading of the
actual referenced property values and the associated quality. If the quality is bad then the value is
set to the default value based on the given data type. Particularly, the value of a variable of type
float is set to NaN (Not a Number). The rest of the scripting environment (including Script
Functions) must be capable of dealing with NaN (e.g., NaN + 4 = NaN, NaN * 5 = NaN, etc.).
Script Functions do not Leverage Quality Information

For Script Functions the in and out parameters as well as a potential return value have no
associated quality information. E.g., a Script Function for calculating the square root of a float
value might have a signature like this:
float Sqrt(float InValue)
If an attribute reference is passed in as the InValue then the quality information is stripped off and
only the value of the referenced property (typically the Value property) is passed in.
Note: A function is invoked independent on whether the quality of the referenced attribute is
acceptable or not. It is the responsibility of the script developer to ensure that the method is
invoked appropriately.
Quality Check From Within a Script

The script developer has the ability to control the execution of script blocks by evaluating the
quality of a set of leveraged attributes. It is possible to either test each attributes quality
individually
If (Valve101.PV.Quality == 192) Or
Valve101.PV.Quality == 0) Then
Or to use the quality check functions as follows:

If IsGood(Valve101.PV) Or
IsBad(Valve101.PV)) Then
Positive Script Logic

Script languages adhering to DQP encourage users to apply positive logic in the script. I.e., any
expression that is used in a control statement (examples are: IF, REPEAT, WHILE) to produce a
Boolean result will equate to a false value if the expression leverages at least one attribute that
has bad or initializing quality. I.e., condition statements are automatically evaluated as False if at
least one attribute with unacceptable quality is used in the condition statement.
Example:
If (Valve101.PV == Closed) And
(Valve102.PV == Closed) Then
Set Valve103.Cmd = Open
Else
Set Valve103.Cmd = Close
{This should be the fail safe mode}
Endif;
If the quality of Valve101.PV and Valve102.PV is acceptable then the if and else branches are
executed purely based on the value of those two attributes.
However, if at least one of the PV values has an unacceptable quality (bad or initializing) then
automatically the else branch is executed. I.e., if statements should be written in a way that the
else branch always constitutes the fail safe mode.
Wonderware Training

Adhering to this standard allows script writers to take quality into account without ever explicitly
evaluating the quality of referenced attributes.
Condition statements are the only instance where a DQP enabled script language takes quality
implicitly into account. In all other cases the script execution system ignores the quality if the script
developer does not choose to test the quality explicitly. This also means that the assignment
PID1.SP = PID2.SP
is executed independent on whether the quality associated with PID2.SP is Bad or

Initializing. That might be surprising at first. However, it leads to a more consistent behavior of the
script environment. Consider the following very similar script lines:
PID1.SP = PID2.SP + 10
PID3.SP = Sqrt(Tank101.Level)
PID4.SP = PID2.SP + A
{A is a local variable}
As soon as the right side is not just a single attribute reference but involves additional statements,
the script execution system has to ignore the quality. From a users perspective is it easier if all the
listed cases are treated equally; i.e., the quality is ignored in all cases.
Numerical Comparisons and NaNs (>, <=, >, >=)

If either double or float operand is IEEE representation of not-a-number NaN in a numerical
comparison, then the result is false. This follows the IEEE 754 standard. Also, positive zero and
negative zero are considered equal.
Script Execution Error Handling

When the script execution engine experiences a script execution error the scripts current
execution scan is aborted. Script execution will be reattempted on the next engine scan after the
script has encountered an execution error. The script properties will indicate the cause of the error
in a dedicated attribute and enter an active alarm state (Script Error alarm). The alarm condition
will remain until the script subsequently completes a successful execution cycle.
Notes:
z
When a script execution abort occurs, the script just stops. Sometimes it might be
necessary to set the quality of some UDAs that are controlled by the aborted script to bad.
The user can accomplish this by exercising a second script that monitors the abortion of
the first script.
Failed writes constitute a normal behavior that does not constitute an alarm.
Example: A script constantly tunes the parameters of a PID loop which is typically in
control mode. However, every time when a shift changes, the PID object is set to manual
mode for a short period of time. Now the writes fail but the script just keeps going and
eventually a script run will again successfully be able to set the PID parameters.
Of course it is also possible to check the WriteStatus from within the script and react accordingly.
Alarm Type Errors

Watchdog Timeout Error
To prevent the possibility that a script can cause an overrun of the ApplicationEngine scan cycle
(e.g., by running in an infinite loop), a script is aborted after the timeout period for the script has
elapsed. The script execution infrastructure will clean up after the aborted script as best as
possible. E.g., the script infrastructure must attempt to release external objects or data base
5-63
5-64

connections that were created by the script. However, it can never be guaranteed that an aborted
script has no negative side effects. E.g., the script could have started to manipulate data base
entries and could leave some table entries in an inconsistent state.
All synchronous mode scripts will be subject to the same timeout period, which is exposed as an
attribute on the AppEngine.
The script developer will be required to configure the timeout period for each Asynchronous mode
script in order to provide flexibility in accommodating the potentially time consuming operations
that these scripts are intended for.
Overflow Error
A script experiences an overflow condition. Overflow conditions not only apply to analog data
types (integer float) but also other data types (e.g., string length overflow).
Division by Zero
The division by zero error is raised only for integer operations. In the case of float values the
scripting is able to deal with + and - and also NaN (Not a Number).
Net Call Execution Errors

If a script encounters an exception during call of a .Net function call, the error will be caught and an
error message (in red) will be logged to the logger. In addition, the execution alarm Boolean
condition is raised in this case.
Pre-Installed Binary Libraries

As part of the scripting environment a single binary library is shipped. This library provides
functionality to support both generic scripting tasks and tasks requiring access to specialized
portions of Application Server
z
Math functions: Includes functions like Abs, Sin, Sqrt, etc.
String functions: StringLen, etc.
System functions: LogMessage, etc.
Importing Additional Binary Libraries

Script Library Packages can be added to the system and made available to the user like preinstalled script libraries.
Note: Script libraries developed with the InTouch 32-bit Extensibility toolkit can be imported and
converted to Script function Libraries.
Exporting Binary Libraries

Once imported, script functions exposed in the imported libraries can be used in any scripts. When
objects using those scripts are exported from the Galaxy (say Galaxy A) and imported into another
Galaxy (Galaxy B) the libraries once imported into Galaxy A are not automatically exported with
the object. I.e., in order to run the exported object in Galaxy B, the script libraries that the object
depends upon need to be manually copied to Galaxy B.
Wonderware Training

Script Locking
Locking Scripts in Templates
From an implementation point of view it is much easier to lock both the expression controlling the
execution of an ApplicationObject script and the actual script at the same time; i.e., treat both as
one entity. This allows the system to compile both the expression and the script into only one dll
which makes deployment easier and decreases the overhead carried in each dll.
Typically an expression uses attribute references. If the user wants to lock the expression and the
associated script expression in a template then it is crucial that aliases are used in both the
expression and the script. This allows the user to specify the attributes that the aliases point to on
a per instance basis while the code is locked.
Rules on Locking of Scripts:
z
Script text can be locked/unlocked in a Template.
When a Script is locked in a Template, the Alias names are automatically locked also. The
Alias References are never locked. Locking of Aliases is not specified separately (it is
only done when the script itself is locked/unlocked).
The Script expression, trigger type and trigger period are group locked and can be locked
separately from the script text.
When a Script is added to a Template, all properties of the Script are editable.
When a Script is added to an Instance, all properties of the Script are editable except for
the Lock property (since lock is never editable in an Instance).
For a Script added in an Instance, all properties of the Aliases can be edited except the
Lock (since locks are never editable for Instances).
Support for .NET Constructs

QuickScript .NET is built on top of .NET and supports the following .NET constructions in its
syntax:
z
Declaring variables of .Net types.
Calling public constructors (with and without parameters) of .Net types.
Calling public instance methods (with and without parameters) of .Net types.
Calling public static methods (with and without parameters) of .Net types.
Calling public indexers (with one or more parameters) of .Net types.
Using .Net enumerations.
Language Definition
QSII Case Sensitivity
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the
case is preserved throughout editor sessions.
QSII Comments
Both single line and multi-line comments are supported. Single line comments start at a in a
source code line that has no matching ending in the line. Multi-line comments start with a { and
end with a } and can span multiple lines as the name suggests.
Examples:
5-65
5-66

Dim A; This is a single line comment
Dim B; {This is an example of a multiline comment}
QSII White Space

Spaces and indentation can be used as desired to improve readability, except that at least one
space must appear between adjacent identifiers, and spaces and line breaks cannot appear within
identifiers and numbers. Individual statements are distinguished by a semicolon that marks the
end of a statement.
QSII Operations that Require 1 Operand
Operation
Description
Complement
Negation
NOT
Logical NOT
QSII Operations that Require 2 Operands

Operation
Description
Multiplication
Division
Addition and Concatenation
Subtraction
Assignment
MOD
Modulo
SHL
Left Shift
SHR
Right Shift
&
Bitwise AND
Exclusive OR
Inclusive OR
**
Power
<
Less than
>
Greater than
<=
Less than or Equal to
>=
Greater than or Equal to
==
Equivalency ("is equivalent to")
<>
Not Equal to
AND
Logical AND
OR
Logical OR
QSII Precedence of Operators

The following list shows the order of precedence for evaluation of operators. The first operator in
the list is evaluated first, the second operator is evaluated second, and so on. Operators in the
same line in the list have equivalent precedence. Operators are listed from highest precedence to
lowest precedence.
Precedence
Operator
1 (highest)
(, )
Wonderware Training

Precedence
Operator
- (negation), NOT, ~
**
* , /, MOD
+, -
SHL, SHR
<, >, <=, > =
==, <>
&
10
11
12
13
AND
14 (lowest)
OR
QSII Variables
Variables must be declared before any other code. Local variables or attributes can be used
interchangeably within the same script. However, local variables go out of scope at the end of the
script function they are used in. However, variables declared in the general section of the script
exist and keep their value throughout the lifetime of the object that the script is associated with.
Thus this kind of variable turns into a member variable of the script class. Other scripts attached
to the same object cannot access this variable.
Variables can be used on both the left and right hand side of statements and expressions.
QSII Syntax for Variable Declaration

Each variable must be declared within the script by a separate DIM statement followed by a
semicolon The DIM statement syntax is as follows:
DIM <variable_name> [ ( <upper_bound> [, <upper_bound >[, < upper_bound >]] )
] [ AS <data_type> ];
where
variable_name ::= <letter> { <letter> | <digit> | <special_character> }
letter ::= A-Z | a-z
digit ::= 0-9
special_character ::= _
upper_bound ::= 1-2,147,483,647
data_type ::= Boolean | Discrete | Integer | Float | Real | Double | String |
Message | Time | Object
The variable name is limited to 255 Unicode characters. Note that, in contrast to attribute names,
variable names must not contain dots. Variable names and the data type identifiers are not case
sensitive. If there is a naming conflict between a declared variable and another named entity in the
script (attribute name, alias, name of an object leveraged by the script), the variable name takes
precedence over the other named entities.
For example, lets assume that your script accesses the hosting objects PV attribute in the script
text and you declare DIM PV AS Integer;. Within the declaring script, expressions using PV in a
5-67
5-68

statement will refer to the value associated with the local variable PV rather than the attribute
PV.
Note: The naming convention for QuickScript.NET variables is more restrictive than in
QuickScript. In QuickScript additional special characters are allowed:
Quickscript_special_character :- _!@-?#$%\&
In contrast to QuickScript arrays with up to three dimensions are supported. Only the upper bound
of each dimension can be specified and is fixed after the declaration; i.e., a statement analogous
to VBs ReDim statement is not supported. The lower index of each array dimension is always 1.
The data type declaration (AS <data_type>) is optional. If omitted, the data type of the variable is
Integer (as in QuickScript).
The following table shows how the QuickScript .NET data types map to C++ data types. The
default value column defines which value the variable takes on when it is defined (before another
value is assigned).
Data Type
(as specified in
AS <data_type>)
Default
Value
Corresponding
C++ data type
Boolean, Discrete
False
VARIANT_BOOL
Discrete and Boolean are synonymous.

Discrete is still supported for migration
from InTouch.
True=1, False=0
Integer
long (4 bytes)
Signed
2147483648 to 2147483647
Float, Real
NaN
float (4 bytes)
Float and Real are synonymous. Real is

still supported for migration from InTouch.
For range information please refer to
Appendix
Double
NaN
Double (8 bytes)
For range information please refer to

Appendix
String, Message
(empty
string)
BSTR
Maximum length defined by BSTR

(2147483647)
Time
Based on .NETs
System.DateTime
(8 bytes)
Resolution is 100 nanoseconds, used to

reflect an absolute date / time the content
reflects the number of 100-nanosecond
intervals since 00:00 January 1, 0001.
ElapsedTime
Based on .NETs
System.TimeSpan
structure (8 bytes)
100 nanosecond ticks represents a time

span.
Object
Nothing
IDispatch pointer
Leveraged for accessing OLE

Automation servers.
Comment
Mapping of Application Server Attribute Data Types to QuickScript .NET

Data Types
Application Server data types are mapped to QuickScript .NET variable data types according to
the following table.
Wonderware Training
Application Server Data Type
QuickScript
.NET Data
Type
Comments
MxBoolean
Boolean or
Discrete
True=1, False=0
MxInteger
Integer
MxFloat
Float or Real
MxDouble
Double
MxString
String or
Message
In Application Server, there is no fixed upper limit

on string length.
MxInternationalizedString
String or
Message
These strings are read-only at runtime. If script

tries to write at runtime the write will fail at
runtime with appropriate status.
MxTime
Time
The filetime content of MxTime is mapped to

Time.DateTime of the QuickScript .NET data
type. The Application Server internal
representation is based on 1601, whereas the
Script internal representation is based on 0001
(consistent with .Net system).
The time zone offset of MxTime is mapped to
Time.TimeZoneOffset.
Time.DateTime is a .Net DateTime.
Time.TimeZoneOffset is an integer.
MxElapsedTime
ElapsedTime
Same definition
MxReferenceType
String
Only the string content of the attribute is used.

The potentially pre-bound IDs are thrown away.
MxStatusType
Integer
One of the integer values listed in section. Note,

that only the status category is exposed. The
status detail is not accessible form within a script.
MxDataTypeEnum
Integer
One of the integer values listed in section.
MxSecurityClassificationEnum
Integer
One of the integer values listed in section.
MxDataQualityType
Integer
One of the integer values listed in the OPC Spec.

Data Access Custom Interface Standard. The
user can also write this (but only my attributes,
not external attributes). For example, to set the
quality of MyAttr to Good
Object.MyAttr.Quality=192. Note that access to
Quality is purely an OPC quality operation.
To access Application Servers 4 basic quality
states (Good, Bad, Uncertain, Initializing), the
user can use functions IsGood(), IsBad(),
IsUncertain(), IsInitializing(). This will allow tests
like
if (IsGood(Obj.Attr.Qstring)
Additionally, the user can set the quality using
functions SetGood(), SetBad(), SetUncertain(),
SetInitializing(); for example:
SetBad(TIC101.PV).
5-69
5-70
Application Server Data Type
QuickScript
.NET Data
Type
Comments
MxQualifiedEnum
Integer or
String
Attributes of type mxQualifiedEnum can be read /

set as an integer or a string.
Example:
Dim intV1_PV as Integer;
Dim strV1_PV as String;
intV1_PV = Valve101.PV;
{ Now intV1_PV holds the ordinal value of the
qualified enumeration }
strV1_PV = Valve101.PV;
{ Now strV1_PV holds the string value of the
qualified enumeration }
MxQualifiedStruct
N/A
The data type MxQualifiedStruct is not directly

mapped to a QuickScript .NET variable data
type. Instead, functions are provided that allow
the script developer to map parts of the qualified
struct to native script data types.
Example (the actual name and signature might
change):
ToInteger(<QualifiedStruct>, StartByte)
which expects an attribute of data type
mxQualifiedStruct and a number of the first byte
that makes up a 4 byte integer. It returns a
regular integer.
QSII Numbers and String

This section describes the allowed format for specifying integer and float numbers as well as
strings in the script text.
Integers in decimal format

Integers constants in decimal defined as
IntegerConst ::=
[sign] <non-zero_digit> <digit>*
|
sign ::= + | non-zero_digit ::= 1-9

digit ::= 0-9
I.e., an integer constant is a zero or consists of an optional sign followed by one or more digits.
Leading zeros are not allowed.
Integer constants outside the range 2147483648 to 2147483647 cause an overflow error.
Integers in hexadecimal format

Prepending either 0x or 0X causes a literal integer constant to be interpreted as being in
hexadecimal notation. In this case the sign is not supported.
Wonderware Training

IntegerHexConst ::=
<0><x | X> <hexdigit>*
hexdigit ::= 0-9, A-F, a-f
When entering a hexadecimal number, only 8 hexdigits (32-bits) are allowed.
Floats
Float constants are applicable as values for variables of type float / real or double. I.e., float
constants do not take the number of bytes into account. It is up the validation step of the script
(lexer / parser) to detect an overflow when too big a float constant is assigned to either a variable
of type float / real or double.
FloatConst ::=
[<sign>] <digit>* .<digit>+ [<exponent>]
|
[<sign>] <digit>+ [.<digit>* [<exponent>]]
sign ::= + | digit ::= 0 - 9

exponent ::= exponent_character [sign] <digits>+
exponent_character ::= e | E
Sign is either plus (+) or minus (); and digits are one or more decimal digits. If no digits appear
before the radix character (.), at least one must appear after the radix character. The decimal digits
can be followed by an exponent, which consists of an introductory letter (e or E) and an optionally
signed integer. If neither an exponent part nor a radix character appears, a radix character is
assumed to follow the last digit in the string.
Please note that the allowed range depends on the data type (4 byte float / real versus 8 byte
double) of the variable that the value is assigned to.
String Literals
String literals need to be surrounded by double quotes. They are referred to as quoted strings.
Within the quoted string the character \ can be used as an escape character. The following
escape characters are supported:
Escape Sequence
Description
\n
New line
\r
Carriage return
\t
Horizontal tab
\'
Single quotation mark. Single quotes can

also directly be used in a string without
using the escape sequence.
\"
Double quotation mark
\\
Backslash
\uxxxx
Represents single Unicode character

formed by the hexadecimal number xxxx.
E.g. \u0066 is the letter f. 4 digits are
required.
5-71
5-72

Escape Sequence
Description
\Uxxxxxxxx
Represents single Unicode character

formed by the hexadecimal number
xxxxxxxx. E.g. \u00000066 is the letter f.
8 digits are required.
QSII Control Structures

IF THEN ELSEIF ELSE ENDIF
The IF-THEN-ELSE-ENDIF statement is used to conditionally execute various instructions based
on the state of an expression. The syntax is as follows:
IF <boolean_expression> THEN
[statements]
[ { ELSEIF
[statements] } ]
[ ELSE
[statements] ]
ENDIF;
Where
z
boolean_expression is an expression that can be evaluated as a Boolean. Dependent on

the data type returned by the expression the expression is evaluated to constitute a True
or False state according to the following table:
Data Type
Mapping
Boolean, Discrete
Directly used (no mapping needed)
Integer
Value = 0 evaluated as False

Value != 0 evaluated as True
Float, Real

Double

String, Message
Cannot be mapped. Using an expression

that results in a string type as the
boolean_expression results in a script
validation error.
Time

that results in a time type as the
validation error.
Object

that results in an object type as the
validation error.
The first block of statements is executed if boolean_expression evaluates to True. Optionally a

second block of statements can be defined after the keyword ELSE. This block is executed if the
boolean_expression evaluates to False. In order to facilitate deciding between multiple
Wonderware Training

alternatives an optional ELSEIF clause can be used as often as needed. The ELSEIF clause
allows for easy mimicking of switch statements offered by some other programming languages.
Example:
If value = 0 Then
Message = Value is zero;
ElseIf value > 0 Then
Message = Value is positive;
ElseIf value < 0 then
Message = Value is negative;
Else
{Default. Should never occur in this example}
EndIf
For consistency with InTouch Scripting, the following syntax is also supported:
IF <boolean_expression> THEN
[statements]
[ { ELSE IF
[statements] } ]
[
ELSE
[statements] ]
ENDIF;
ENDIF;
This approach basically nests a brand new IF compound statement within a previous one and
requires an additional ENDIF.
FOR TO STEP NEXT Loop

A FOR-NEXT loop is used to perform a function (or set of functions) within a script several times
during a single execution of a script. The general format of the FOR-NEXT loop is as follows:
FOR <analog_var> = <start_expression> TO <end_expression> [STEP
<change_expression>]
[statements]
[EXIT FOR;]
[statements]
NEXT;
Where:
z
analog_var is a variable of type Integer, Float, Real, or Double.
start_expression is a valid expression, to initialize analog_var to a value for execution of

the loop.
end_expression is a valid expression. If analog_var is greater than end_expression,

execution of the script jumps to the statement immediately following the NEXT statement.
(This holds true if loop is incrementing up, otherwise, if loop is decrementing, loop
termination will occur if analog_var is less than end_expression.)
5-73
5-74

z
change_expression is an expression, to define the increment or decrement value of

analog_var after execution of the NEXT statement. The change_expression can be either
positive or negative. If change_expression is positive, start_expression must be less than
or equal to end_expression or the statements in the loop will not execute. If
change_expression is negative, start_expression must be greater than or equal to
end_expression for the body of the loop to be executed. If STEP is not set, then
change_expression defaults to 1.
It is possible to exit the loop from within the body of the loop via the EXIT FOR statement.
The FOR loop is executed as follows:
1. analog_var is set equal to start_expression.
2. The system tests to see if analog_var is greater than end_expression. If so, the loop exists. (If
change_expression is negative, the system tests to see if analog_var is less than
end_expression.)
3. The statements in the body of the loop are executed. Here the loop can potentially be exited
via the EXIT FOR statement.
4. analog_var is incremented by 1 - or by change_expression if it is specified.
5. Steps 2 through 4 are repeated
Note: FOR-NEXT loops may be nested. The number of levels of nesting possible depends on the
memory and resource availability.
FOR EACH IN NEXT

The FOR EACH loop can only be used with collections exposed by OLE Automation servers .A
FOR-NEXT loop is used to perform a function (or set of functions) within a script several times
during a single execution of a script. The general format of the FOR-NEXT loop is as follows:
FOR EACH <object_variable> IN <collection_object >
[statements]
[EXIT FOR;]
[statements]
NEXT;
Where:
z
object_variable is a variable of type <some COM interface>
collection_object is a variable holding a collection object.
As in the case of the FOR TO loop it is again possible to exit the execution of the loop via the
statement EXIT FOR; from within the loop.
Note: Collection are frequently leveraged by VB and VBA / JScript. Microsofts office suite is built
around the concept of collections. Furthermore Microsoft started to expose more and more of the
Windows system via collections.
Example:
Dim fso As IFileSystem;
Dim folder As IFolder;
Dim fileCollection As IFileCollection;
Wonderware Training

Dim file As IFile;
Dim fileName as String;
fso = new FileSystemObject;
folder = fso.GetFolder(C:\Temp);
fileCollection = folder.Files;
For Each file In fileCollection
fileName = file.name;
Next;
FOR EACH will allow for looping through arrays. (Omitted for this slice)
While Loop
A WHILE loop is used to perform a function (or set of functions) within a script several times during
a single execution of a script while a condition is true. The general format of the WHILE loop is as
follows:
WHILE <boolean_expression>
[statements]
[EXIT WHILE;]
[statements]
ENDWHILE;
Where:
z
boolean_expression is an expression that can be evaluated as a Boolean as defined

above in the description of IFTHEN statements.
It is possible to exit the loop from within the body of the loop via the EXIT WHILE statement.
The WHILE loop is executed as follows:
1. The system tests to see if boolean_expression is true. If not, the loop exists.
2. The statements in the body of the loop are executed. Here the loop can potentially be exited
via the EXIT WHILE statement.
3. Steps 1 through 2 are repeated
Note: WHILE loops may be nested. The number of levels of nesting possible depends on the
memory and resource availability.
Support for Script Functions

In order to follow the naming syntax of InTouch QuickScript, binary shared functions are referred to
as script functions. Functions written in QuickScript are named QuickFunctions.
Accessing Script Functions

Script functions can be directly accessed from within the script code. The syntax is exactly like in
QuickScript.
Example:
PumpState = StringRight("The Pump is On", 2);
Where StringRight is a binary script function as described in the Scripting DFS. After the executing
the script snippet PumpState holds the value On.
5-75
5-76

Any of the script functions provided by The Application Server can be invoked this way.
Syntax:
ScriptFunction ::= <FunctionName> ( {<Paramater>} { , <Paramater>} );
OLE Automation Support

Over the last couple of years Microsoft used many different terms when talking about OLE
Automation. In order to reduce confusion the following part attempts to establish the terms used
throughout this document:
ActiveX Server:
Other names for ActiveX Server are COM Server, ActiveX component, ActiveX EXE, ActiveX DLL.
Support for OLE Automation Compatible ActiveX Servers

Support for COM Servers:
z
Support for Get/Set Property
Support for method invocation on COM server
Creating objects outside of the context of scripts does not work. In many cases an object can only
be created in a programmatic manner based on another already created object.
VBS example:
Dim xlApp
Dim xlBook
Dim xlSheet
' Assign object references to the variables. Use
' Add methods to create new workbook and worksheet
' objects. Note that xlBook and xlSheet can only be
' created after the objects xlApp and xlBook got
' created.
Set xlApp = WScript.CreateObject("Excel.Application")
Set xlBook = xlApp.Workbooks.Add
Set xlSheet = xlBook.Worksheets.Add
Once created, the methods exposed by a COM object can be accessed as if they would be script
functions.
There are at least two different approaches:
Allow Creation of COM Servers from within a Script

Scripts can create COM servers using one of two techniques. The New technique is the
preferred technique since it allows early-binding of methods which offers the advantage of early
validation of method calling syntax and better runtime performance.
1. New keyword this keyword instructs the script to create a new .Net object. ActiveX
components that have been imported into the Galaxy Repository explicitly end up with .Net
wrappers that allow them to be created using this technique. In the example below, earlybound methods on
Dim app as Excel.Application;
App = new Excel.Application;
Wonderware Training

2. CreateObject method this method instructs the script to specifically create a named COM
object that is installed on the system upon which the script is to be deployed. These are latebound objects. Late-bound methods on app can be called after the object is created.
dim app as object;
app = CreateObject("Excel.Application");
5-77
5-78
Wonderware Training
Lab 10 Object Reuse
Lab 10 Object Reuse

Introduction
In a previous lab we created a $TankSystem template that contained other templates. It was
useful as a cookie cutter for the many TankSystems we have in our facility, but every time we want
to model another tanksystem we must fill in the IO reference information for the valves, pump and
level transmitter instances. As it turns out, our facility has a well-defined naming convention that
identifies how to access our device IO. We can use this convention along with some scripting in
our templates in such a way that our devices will address themselves when they are deployed. All
we need to do is name the TankSystem instance appropriately.
In order to accomplish this task, we will need some relative keywords in our scripting language that
refer to contained and container objects. These words include Me, MyContainer, MyEngine, and
MyPlatform. These keywords allow you to work your way up the container hierarchy. To move
down to the contained objects you can use the contained name.
Objectives
z
Add scripts to existing templates and note changes that are propagated to existing
instances of the template.
Create a new instance of a template and note the differences between that instance and
the previously generated instance.
5-79
5-80

Tasks
Modifying Tank Template Objects
1. Double click $XYTankSystem to open the editor and select the UDAs tab.
2. Click on the plus icon

to add a UDA named IOSet with a Data type of Boolean and a
Category of User Writeable.
Wonderware Training
Lab 10 Object Reuse

3. Select the Scripts tab.
4. Click on the plus icon
to add a Script named AssignIO.
5-81
5-82

5. Add the following:
Select an Execution Type of Execute
For the Expression enter
Me.IOSet == 0
For the Trigger Type select WhileTrue

Add the following script to the Script area.
IF Me.AssignIO.ExecutionCNT >= 2 THEN

Dim Datasource as string;
datasource = "InControl.Tagname.T" + StringRight(me.tagname,3);
me.DLInletValve.CLS.Inputsource = datasource + "_IV_CLS";
me.DLInletValve.OLS.Inputsource = datasource + "_IV_OLS";
me.DLInletValve.CMDOpen.OutputDest = datasource + "_IV_CMDOpen";
me.DLOutletValve.CLS.Inputsource = datasource + "_OV_CLS";
me.DLOutletValve.OLS.Inputsource = datasource + "_OV_OLS";
me.DLOutletValve.CMDOpen.OutputDest = datasource + "_OV_CMDOpen";
me.DLTransferPump.AuxContact.Inputsource = datasource + "_TP_AuxContact";
me.DLTransferPump.CMDStart.OutputDest = datasource + "_TP_CMDStart";
me.DLLIT.PV.Input.InputSource = datasource + "_LT_PV";
Me.IOSET = true;
ENDIF;
Wonderware Training
Lab 10 Object Reuse
5-83
5-84

6. Lock the following attributes
z
Aliases
Declarations
Scripts
Basics

The Check In dialog box will appear. Enter Added AssignIO script for automatic
configuration in the Comment field. Then click OK.
8. In the Deployment View, create an instance of the $XYTankSystem object and name the
instance XYTankSystem_xxy where xx is your student number and y is the Tank System
number (0 or 1 only).
Note: When the TankSystem instance is renamed, a dialog box with a warning is displayed.
Click OK.
Note: When creating an instance of this template, the instance will display a warning icon
on the new instance. This is OK. This can be cleared by adjusting the IO references from
---.--- to --- as a place holder for the actual reference to be applied later. If you have a warning
icon with this template object, please notify your instructor.
Wonderware Training
Lab 10 Object Reuse
9. Assign XYTankSystem_xxy to the XYLine1 Area.
5-85
5-86

10. Notice that XYTankSystem_001 needs to be re-deployed because it now includes the new
script. Doing so will override (on runtime) the reference configuration hardcoded into the
contained objects.
Deploy (cascade) the new Tank System instance and re-deploy (cascade) the
XYTankSystem_001 and verify this with Object Viewer.
11. View the object in Object Viewer and verify that the configuration attributes for the new
objects have the right reference.
Wonderware Training
Lab 11 Averager
Lab 11 Averager
Introduction
The QuickScript.Net scripting environment supported in Industrial Application Server is an
extremely powerful extensibility tool.
One of the features of IAS is the ability to extend an objects set of attributes (Namespace) by
adding custom User Defined Attributes (UDAs). The scripting engine allows the customization
of any object by internally calculating the data that a UDA is going to handle. Using this technique
and internal reserved keywords of the scripting engine, it is possible to create objects that add new
information to existing objects by just creating a containment relationship.
We will create an Averager object based on a new derived template that will calculate the Average
of the PV attribute of any analog object in the Galaxy. The average will be calculated on a set of
no more than 100 samples. These sample sizes can be configured by the application developer
when the instance is created.
Objectives
z
Create an instance of a UserDefined object.
Configure UDAs and scripts.
Monitor the new values using the Object Viewer.
5-87
5-88

Tasks
Create the Averager Template
1. Right-click the $UserDefined object in the Template Toolbox and select New/Derived
Template.
Name your new template XYAverager.
2. Assign $XYAverager to your Template Toolset.
3. Double-click on the $XYAverager template object to open its editor and select the UDA tab.
Click on the Plus icon
and add a UDA called Avg. Configure it as follows:
Data Type:
Double
Category:
Calculated
This is an array:
Unchecked
Wonderware Training
Lab 11 Averager
4. Create another UDA and name the UDA QueueSize. Configure it as follows:
Data Type:
Integer
Category:
User writable
This is an array:
Unchecked
Value:
50
5-89
5-90
5. Click the Scripts tab. Click on the Plus icon

Name:
Calculate
Execution Type:
Execute
Trigger Type:
Periodic
Trigger Period:
00:00:00.0000000
6. Click the Plus to expand the Declarations section.
Wonderware Training
and add the following script:
Lab 11 Averager
7. Add the following code in the Declarations section of the editor:
Dim valueQueue[100] As Double; 'Circular queue to hold the values for the
average.
Dim queueLength
As Integer; 'Holds the current length of the queue.
Dim nextElement
As Integer; 'Holds the next element for the circular
queue.
In the body of the script, type the following script:

'NOTE:
'
'
'
The queueLength variable allows the object to know how

many values are stored in the queue.
This allows an accurate average when the object has not
stored all the values in the queue.
'Get next element for the queue and add the next value to the queue.
nextElement = (nextElement Mod Me.QueueSize) + 1;
valueQueue(nextElement) = MyContainer.PV;
'Verifies the queue is not filled up.
If queueLength < Me.QueueSize Then
queueLength = queueLength + 1;
Else
queueLength = Me.QueueSize;
EndIf;
'Calulates the average with the values stored in the queue.
Dim queueSum As Double;
Dim i As Integer;
queueSum = 0.0;
For i = 1 To queueLength
queueSum = queueSum + valueQueue[i];
Next;
Me.Avg = queueSum / queueLength;
5-91
5-92
Wonderware Training
Lab 11 Averager
8. Lock the following sections
z
Aliases
Declarations
Scripts
Basics
5-93
5-94

9. Create another script and name the script CheckQueueSize. Configure it as follows.
Execution Type:
Execute
Expression:
Me.QueueSize
Trigger Type:
DataChange
In the body of the script, type the following script.

'Validate QueueSize everytime it changes
'so it's always within the valid range.
If Me.QueueSize < 1 Then
Me.QueueSize = 1;
ElseIf Me.QueueSize > 100 Then
Me.QueueSize = 100;
EndIf;
Wonderware Training
Lab 11 Averager
10. Lock the following sections
z
Aliases
Declarations
Scripts
Basics

The Check In dialog box will appear. Enter Added scripts for Average calculation and data
validation in the Comment field. Then click OK.
5-95
5-96

Create and Test an Averager Instance
12. In the Deployment View, create an instance of the $XYAverager object and rename it
XYAverager1.
Note: When the Averager instance is renamed, a dialog box with a warning is displayed.
Click Yes.
13. Assign XYAverager1 to the XYLIT object.
Wonderware Training
Lab 11 Averager
14. Right-click the XYAverager1 object and select Deploy the object On Scan.
15. Right-click the XYAverager1 object and select View in Object Viewer.
dialog box enter Averager and click OK.
18. Add the attributes Avg and QueueSize to the Watch Window to monitor the value.
19. Change the value of QueueSize to see how it reacts.

5-97
5-98
Wonderware Training

Section Objective
This section will familiarize you with an understanding of the Extensions environment and the
OUtput Functionality for ApplicationObjects.
Extensions
The Extensions page is comprised of five main functional areas. These are described below.
The main functional areas of the Extensions page include:

z
Extendable Attributes List: Lists all attributes currently associated with the object. The
list can include those added through the UDA object extension function. Select the Show
Extension Attributes check box to include attributes added on the UDA page.
InputOutput Extension Group: Use to configure an attribute so that its value is both read
from an external-reference source and written to an external-reference destination (the
source and destination may or may not be the same). The extension reads the Source
attribute's value and quality, and updates the extended attribute's value and quality every
scan. Changes read from the source are not written back to the Destination attribute.
Input Extension Group: Use to configure an attribute to be a reference source for

another object. In other words, the extended attribute acquires the update value of the
Source attribute.
5-99
5-100

z
Output Extension Group: Use to configure an attribute to be writeable to an external

object's attribute. In other words, when the value or quality (from Bad or Initializing to
Good or Uncertain) of the extended attribute is modified, the value of the Destination
attribute is updated.
Alarm Extension Group: Use to create an alarm condition when a Boolean attribute's
value is set to TRUE.
History Extension Group: Use to historize the value of an attribute that does not already
have history capabilities.
To create and associate an extension with an object

1. On the Extensions page of the object's editor, select an attribute in the Extendable Attributes
List. The four extension groups dynamically change according to allowed extension rules for
the selected attribute type.
2. Select the check box of the kind of extension you want to apply to the selected attribute. The
associated parameters for each kind of extension are then made available.
3. For InputOutput Extension, enter a Source attribute by either typing in the reference string or
clicking the attribute browser button at right. Use the Attribute Browser dialog box to search
for the desired reference string in an object. Then if Destination is different from Source, click
Output Destination Differs from Input Source, and enter a Destination attribute by either
typing in the reference string or clicking the attribute browser button. An X is placed in the
InputOutput column of the selected attribute.
Caution! If you clear the Output Destination Differs from Input Source check box, the
content of the Destination box automatically becomes "---". In the run-time environment, "---"
is interpreted as the same reference as the Source value entered during configuration time. In
the run-time, you can change the Source reference. Therefore, during configuration, do not
lock the Destination parameter if you clear the Output Destination Differs from Input
Source check box.
4. For Input Extension, enter a Source attribute by either typing in the reference string or
for the desired reference string in an object. An X is placed in the Input column of the selected
attribute.
5. For Output Extension, enter a Destination attribute by either typing in the reference string or
for the desired reference string in an object. Select the Output Every Scan check box if you
want the extended attribute to write to the Destination attribute every scan period of the
object (otherwise, the write executes only when the value is modified or when quality changes
from Bad or Initializing to Good or Uncertain). An X is placed in the Output column of the
selected attribute.
6. For Alarm Extension, select a Category from the list: Discrete, Value LoLo, Value Lo,
Value Hi, Value HiHi, DeviationMinor, DeviationMajor, ROC Lo, ROC Hi, SPC, Process,
System, Batch or Software. Type a Priority level for the alarm (default is 500). Also, choose
between Use Object Description for Alarm Message or typing in another alarm message in
the Message box. An X is placed in the Alarm column of the selected attribute.
7. For History Extension, enter values for the remaining parameters: Force Storage Period,
Engineering Units, Value Deadband, Trend High and Trend Low, if available (depends on
the data type of the selected attribute). An X is placed in the History column of the selected
attribute.
8. Lock the value if desired. The lock symbol is available only when you are extending a
template. Otherwise, it indicates the lock condition of the value in the parent object.
Wonderware Training

9. Set the security classification for the attribute if available. See "Security Icons" in "Working
with Object Editors" for more information.
10. Save and close the object editor to include the new attribute extensions in the configured
object.
Output Functionality
The following information applies to the functionality of InputOutput and Output extensions as well
as the output function of the Field Reference, Switch and Analog Device objects.
If a single set request is made to a destination attribute during a single scan cycle, that value is
sent to the destination. During a single scan cycle, though, more than one set request to the same
destination is possible. In that case, folding occurs and the last value is sent to the destination.
The following occurs during a single scan cycle: Only the last value requested during a scan cycle
will be sent to its destination when the object executes. Its status is marked as Pending as it waits
for write confirmation from the destination object. All other set requests during that scan cycle are
marked as successfully completed.
If one or more new sets are requested during the next scan cycle, then the second scan cycle's
value is determined in the same way as described above. It is then sent to the destination when
the object executes again and the value sent to the destination during the previous scan cycle is
marked with successful completion status even if write confirmation had not been received.
In other words, within a single scan cycle, data is folded and only the last set requested is sent to
the destination. For instance, an {11,24,35,35,22,36,40} sequence of set requests will result in a
value of 40 being sent to the destination object. All other values result in successful completion
status.
The exception to the above-described functionality is for Boolean data types used in User sets
(sets from InTouch or FactorySuite Gateway). This functionality accounts for an unknown user
input rate (for instance, repeated button pushes) with a consistent object scan rate for outputs, and
therefore creates reproducible results. In this case, a combination of folding as described above
plus maintenance of a queue of one element deep in order to better meet the expectation of users.
To begin with, the first value set after the object is deployed (the default True or False) is always
written to its destination.
Subsequently, the following occurs during a single scan cycle: A two-tiered caching scheme of a
Value to be Sent and a Next Value to be Sent is implemented. The Value to be Sent is based on
data change as compared to the last value sent to the destination object. The Next Value to be
Sent is based on data change as compared to the Value to be Sent value. When the first data
change occurs, the new value is cached in the Value to be Sent queue. Folding occurs if the same
value is requested again. If another value change occurs, this second value is cached in the Next
Value to be Sent queue. Again, folding occurs if the same value is requested again.
The Value to be Sent value is sent during the next scan cycle, and the Next Value to be Sent value
is sent during the following scan cycle.
5-101
5-102

In other words, for Boolean data types and User sets, the following examples apply:
Previous Scan Cycle
Value Sent
Scan Cycle Set

Requests
Value to be Sent
Next Value to be Sent
1,0,0,1,1
none
1,0,0,1,1
1,1,0,0
1,1,0,0
none
Note: In the case of Boolean data types used in Supervisory sets (sets between
ApplicationObjects and ArchestrA) or a mixture of Supervisory and User sets during a single scan
cycle, the behavior is the same as the other data types.
Important! When the same attribute is extended with an Input extension and an Output extension,
writes to the Output extension's Destination occur every scan regardless of whether the extended
attribute has changed. This behavior occurs even when the Output Every Scan check box is
cleared, increasing the potential for additional network traffic. The behavior described in this note
does not apply to an InputOutput extension.
Wonderware Training
Lab 12 Extensions
Lab 12 Extensions
Introduction
Extensions allow you to add historization and alarming to certain parameters on your objects and
UDAs. They also enable you to place input and output references on these extendable types. By
extending a UDA in this manner, it can be used in scripting to promote the name of an object to a
reference to the object. The difference is when you have the name of an object all you have is a
string, however a reference to the object can be used to get properties and control the state of the
object. The power of IO references combined with UDAs is explored in this lab.
Objectives
z
Configure an objects extensions to allow communication to other objects about certain

parameters.
View those changes in the Object Viewer and change their state.
5-103
5-104

Tasks
Extensions Configuration
1. Double click on your XYTankSystem_001 instance to open its editor.
Select the UDAs tab.
Create a UDA named TankAlarm and configure it as:
Data type
Boolean
Category
Object writeable
Wonderware Training
Lab 12 Extensions
2. Select the Extensions tab.
5-105
5-106

3. Select TankAlarm and configure it as follows:
Input extension
Source
Alarm extension
checked
InControl.Tagname.TXXY_ALARM01
checked and locked
Category
Process
Priority
500
Alarm message attribute
me.Tagname
4. Save and close the editor and check in the object.

5. Right click on the TankSystem_001 object and select View in Object Viewer.
Optional: Modify the auto-config script to include Tank Alarm.
dialog box enter Extensions and click OK.
Wonderware Training
Lab 12 Extensions
8. Add the following attributes to the Watch Window:
z
TankAlarm
TankAlarm.InAlarm
TankAlarm.Acked
TankAlarm.TimeAlarmOn
TankAlarm.TimeAlarmOff
DLPlant.InAlarm (Note that this attribute is from the Plant area, not the
XYTankSystem object.)
5-107
5-108
Wonderware Training

Section Objectives
z
Be familiar with Additional Automation Objects that represent some element of your
application.
Understand their hosting and containment relationships.
Introduction
FieldReference Object
This Object is the generic object for accessing data from an external device. This object can act as
both the field input and a field output.
The FieldReference Object can be configured into three basic access modes:
z
ReadOnly Input object
ReadWrite Output object with scanned Feedback
WriteOnly Output
This object is very simple; it only allows the value to be historized.
Switch Object
This Object is the object for accessing data from a simple discrete (0/1) device. This object can act
as both a discrete input and a discrete output.
The Switch Object can be configured into three basic access modes:
z
ReadOnly Input object
ReadWrite Output object with scanned Feedback
WriteOnly Output
The PV value can be historized, logged as an event, and alarmed when abnormal.
UserDefined Object
The UserDefined object is an empty object that you can use to create customized objects. You can
use the UserDefined object in the following ways:
z
As a "container" for other objects. An object relationship in which one object is comprised
of other objects is called containment. Containment allows you to group various objects
together to make complex objects. For detailed information on object containment, see the
Integrated Development Environment (IDE) documentation.
To use the UserDefined object as a container object, you simply create an instance of the object,
and add ApplicationObjects to it while in the Model View. The only indication of this containment
structure is in the tree structure in the Template Toolbox or Model View. The UserDefined object
editor does not provide any indication of this containment relationship. To edit the configuration of
any contained objects, you must open the individual editors of those objects.
Note: A UserDefined object can only contain ApplicationObjects.
5-109
5-110

z
As a base object to extend through user-defined attributes (UDAs), scripting, and attribute
extensions. For detailed information how to customize an object using these features, see
the common editor documentation.
For example, you might create a UserDefined object called "Tank" and use it to contain
ApplicationObjects that represent aspects of the tank, such as pumps, valves, and levels. You
could create two DiscreteDevice object instances called "Inlet" and "Outlet" and configure them as
valves, and create an AnalogDevice object instance called "Level" and configure an alarm to be
triggered when it overflows. The containment hierarchy would be as follows:
--Tank
--V101 (Inlet)
--V102 (Outlet)
--LT103 (Level)
The Tank object derived from the UserDefined object can be customized to raise an alarm when
both the Inlet and Outlet valves are open. For example, you could add a Boolean UDA called
"StateAlarm," extend it with an alarm extension, and add the following script:
if me.inlet == "Open" and me.outlet == "Open" then
me.statealarm = true;
else
me.statealarm = false;
endif;
You would now have a UserDefined object that forms the complex Tank object, which uses
containment and has been extended to raise a specific process alarm.
Wonderware Training
Module 6
Alarming and History

Section 1 Alarming
6-3
Lab 13 Alarming
6-9
Section 2 Network Account Utility
6-23
Section 3 Historization
6-33
6-37
6-2

Module Objective
z
Obtain an overview and understanding of how the Industrial Application Server integrates
with InTouch and InSQL.
Wonderware Training
Section 1 Alarming
Section 1 Alarming
Section Objectives
z
Familiarize you with the concept of alarms and events, and
Enable you to understand how ArchestrA handles alarms and events.
What is an Alarm/Event
The alarm and event capabilities in the system provide for users to automate the detection,
notification, historization and viewing of either application (process) alarms and events or system/
software alarms events. Alarms and events are things that occur in the runtime system. Events
and alarms are different and the system distinguishes between the two. An event is simply an
occurrence of a condition at a certain point in time. The system can detect events, store them
historically and report them to various clients. Alarms, on the other hand, represent the
occurrence of a condition that is considered abnormal (generally bad) in nature and requiring
immediate attention from a user. Alarms are a special type of event that indicate something
abnormal has happened. The system handles the real-time reporting of alarms in a special
manner and provides special clients for their viewing.
Examples of alarms include:
z
A process measurement has exceeded a predefined limit, such as a high temperature

alarm.
A process device is not in the desired state, such as a pump that should be running has
stopped.
The system hardware is not operating within desired limits, for example the CPU utilization
on a Platform exceeds a certain percentage for an extended time.
Examples of events include:

z
A plant process has started; for example, a new batch or campaign starts.
The operator has changed a plant operator parameter; for example, a setpoint on a
temperature controller.
The system engineer has changed the runtime system configuration; for example,
deployment of a new AutomationObject.
The system engineer has started or stopped a system component; for example, stopping
an engine.
A platform has come back online after it had a failure or shutdown.
A user has logged into the system.
Detection of a severe software problem; such as a failed Application Object component.
The following items are not considered alarms or events:

z
Configuration actions within the Galaxy Repository; for example import or check-out.
Installation of Bootstrap on a PC.
A message sent to the system logger (SMCLogger). Note, sometimes certain software
events may log a message in addition to generating an event, but this is ancillary. Logger
messages are not events.
Viewing a window in the View Engine.
6-3
6-4

How does ArchestrA handle alarms?
The Platform as an Alarm Provider
A Platform can act as a single Alarm Provider that provides alarms to the InTouch Distributed
Alarm subsystem. A boolean checkbox is provided in the Platform AutomationObject indicating
whether it subscribed to Areas or not for alarm and event reporting. The Platform, when deployed,
only initiates subscription to those Areas that are only deployed to that Platform.
The platform is responsible for routing all alarms and events for all Areas subscribed to by that
Platform to InTouchs distributed alarming infrastructure. The Platform acts as a router between all
Alarm/Event Notification Distributors that are running in the subscribed Areas throughout the
Galaxy (inside every Area, Platform, Engine, DI Device, etc.) and the distributed alarming
infrastructure. The Platform also routes alarm acknowledgements, enables and disables received
from distributed alarming back to the appropriate AutomationObject. Alarm acknowledgements,
enables, and disables carry along the User information for security purposes. An alarm generated
by App Server contains fields that are generated by the alarm functions inside the
AutomationObject. Those fields are mapped to fields in InTouch as follows:
Alarms:
ArchestrA field
InTouch Dist Alarms Mapping
Type = alarm state change
N/a
Timestamp of alarm event
Time
Tagname
Name
Common message text string.
Comment
Area
Alarm group
Common name for alarm primitive

(e.g. PV.HiAlarm)
Alarm Type (string)
New alarm state (ack, rtn, etc.)
State
Priority = 1-999
Priority
Value (mxValue)
Value
Limit (mxValue)
Limit
Value MxReference
N/a
Limit MxReference
N/a
Units MxReference
N/a
Category
Class
Category
SubClass
InTouch as an Alarm Consumer

The InTouch Alarm Client can be configured to subscribe to alarms and events generated by
Alarm Providers. The Alarm Provider is specified by providing the node name and provider name
of the provider. For ArchestrA, only one provider exists per Platform (node). In addition, the
InTouch Alarm client can be configured to subscribe to only selected Alarm Areas for the provider
based on its query filters. Alarm Group names in InTouch map to Areas names and pseudo-Area
names (Platforms, Engines, etc.) in ArchestrA.
Alarm Acknowledgement from Distributed Alarming

The InTouch Alarm Client can acknowledge unacknowledged alarms that are reported by the
Platform. The Platform receives the acknowledge request and forwards it to the target
Wonderware Training
Section 1 Alarming
AutomationObjects acknowledge attribute for the alarm. Security is used as part of this set (it is a
UserSetAttribute). An optional comment can be entered when the acknowledge is requested.
An acknowledge of an alarm is reported as an alarm state change back to the distributed alarming.
The optional operator comment is included in the event message sent back.
Distributed Alarming has no support for passing a rejected acknowledge failure feedback.
Therefore, if an acknowledge is requested from a client but does not succeed, the only feedback
on the InTouch client will be no change in acknowledge status on the client.
Alarm Enable/Disable
The InTouch Alarm Client can enable/disable alarming on any AutomationObject. The platform
receives the enable request and forwards it to the target AutomationObjects AlarmMode attribute.
Security is used as part of this set (it is a UserSetAttribute).
How does ArchestrA handle Events?

A Platform is an Event Provider that provides events to the InTouch Distributed Alarm subsystem.
This provider routes all events that are generated by AutomationObjects hosted by that Platform to
Application Server. The provider does not need to deal with subscriptions to Areas. The provider
acts as a router between the NotificationDistributor (inside every Area, Platform, Engine, etc) and
the InTouch Distributed Alarm subsystem.
Several types of events can be generated by AutomationObjects The following tables define how
the fields in those events are mapped to fields in the Distributed Alarm subsystem.
System Events:
ArchestrA field
Distributed Alarm subsystem

Mapping
Type (or Category) = System
Type = SYS
Timestamp
Time
Tagname
Name
Tag description
Comment
Area
Alarm group
System event description

(started, stopped)
Event Type if string, or use

Comment field
N/a
State = none (preferred) or

UNACK_RTN
N/a
Priority = 1
N/A
Provider = Galaxy
N/A
Event Class = EVENT
Security Audit (includes User Data Change) Events:

ArchestrA field

Mapping
Type = Operator Change
Type = OPR
Timestamp
Time
Tag.primitive.attribute
Name
Tag description
Comment
Area
Alarm group
View engine name
6-5
6-6

Security Audit (includes User Data Change) Events: (continued)
ArchestrA field
Operator 1 name

Mapping
RequestingEngineName +
Operator name
Operator 2 name
N/a
Old value
Limit
New value
value
N/a

UNACK_RTN
N/a
Priority = 999
N/A
Provider = Galaxy
N/A
Event Class = EVENT
Application Data Change Events:

ArchestrA field

Mapping
Type = Data Change
Type = LGC
Timestamp
Time
Tag.primitive.attribute
Name? Or name+comment?
Tag description
Comment
Area
Alarm group
View engine name
Platform (the PCs node name)
Old value
Limit
New value
Value
N/a

UNACK_RTN
N/a
Priority = 999
N/A
Provider = Galaxy
Displaying alarms/events in InTouch

The Current Alarm Display is an ActiveX Control delivered with InTouch. The primary purpose of
the control is to allow an InTouch Operator to view and acknowledge active alarms at runtime that
are generated by alarm providers. Alarm providers can include local providers and providers on
the network. Application Server (ArchestrA) is a key alarm provider. Key functions include:
z
Configuration at design time for subscription to specific alarm providers on the network for
alarm reports. One or more Application Server platforms can be an alarm providers (and
can be local or remote).
Configuration at design time for subscription to specific alarm groups (or areas) in a
provider. Groups (or areas) can be hierarchical, meaning sub-groups are automatically
subscribed to.
Display of key alarm information.
Acknowledgment of selected alarms with a comment.
Suppression of alarms (local filter only).
Wonderware Training
Section 1 Alarming
Event History Display in InTouch
The InTouch AlarmDBView ActiveX is used to display historical alarm and event information that
has been logged by the InTouch Alarm Logger. The InTouch Alarm Logger can be configured to
log alarms from any provider, including Application Server.
6-7
6-8
Wonderware Training
Lab 13 Alarming
Lab 13 Alarming
Introduction
A platform object can be configured to be an alarm provider to the InTouch Distributed Alarming
infrastructure. The Alarm Logger database will log these alarms, and InTouch 9.0 supports two
new alarm ActiveX controls to display them. These controls can be used to view streaming alarms
as they occur or historical alarms and events recorded in the distributed alarm database.
In this lab we will configure your Platform to be an Alarm Provider to InTouchs Alarm Logger
database. We will configure the Platform and our Sinewave object in the IDE. Then we will
configure the Alarm DB Logger Manager and start the logger. Finally, we will configure the
Alarm Summary (AlarmViewCtrl) and the Alarm/Event History (AlmDbViewCtrl) controls to
accept alarms from your Platform.
Objectives
z
Configure Platforms to be Alarm Providers
Configure and start the Alarm Logger database
Configure the Summary and History controls to accept alarms.
6-9
6-10

Tasks
Configure the Platform
1. Double-click on your Platform to open the Platform editor.
2. Check the InTouch alarm provider box and verify the Alarm areas list box is blank.
The Alarm areas field is used to specify a

space-separated list of areas to subscribe to.
It is used to filter alarms on the network. For
example, "Area1 Area2 Area3". If blank, the
platform will subscribe to all areas in the
Galaxy and act as an InTouch alarm provide
for the whole Galaxy.
3. Close and Save the editor.
Wonderware Training
Lab 13 Alarming
Configure the AnalogDevice Object
4. Double-click on the XYLIT object.
5. Select the Alarm tab.
6-11
6-12

6. Configure the Alarms tab as follows:
Check the box for Detect PV level(limit) alarms
Check the box for Level alarms Hi
Set the Limit to 80.0
8. Redeploy the Platform.
Wonderware Training
Lab 13 Alarming
9. Right click on XYLIT and select View in Object Viewer.
10. Add the following XYLIT attributes to the Watch Window.

z
PV
Hi.Limit
Hi.InAlarm
Hi.TimeAlarmOff
Hi.TimeAlarmOn
6-13
6-14

Configure the Logger Database
11. Select Start/Programs/Wonderware/InTouch/Alarm DB Logger Manager to launch the
Logger Database
12. Click the Settings button to configure the database.
Wonderware Training
Lab 13 Alarming
13. Configure as follows then click the Create button:
Server Name local
User Name sa
Logging Mode Consolidated
Password
[Check with your instructor for the correct password.]
The Success dialog box will display indicating the tables were created.
Click OK to continue.
6-15
6-16

14. Back at the Alarm DB Logger Manager Configuration dialog box click Test Connection to
test the database connection.
15. Click OK if connection succeeded, then click Next to continue.
Wonderware Training
Lab 13 Alarming
16. At the Query Selection dialog box configure the Alarm Query as follows then click Next to
continue.
Alarm Query
\\<Provider Node>\Galaxy!<Area>
Where <Provider Node> is the platforms node name, Galaxy is a fixed keyword and <Area> is
the area of interest.
6-17
6-18

17. At the Advanced Setting dialog box, accept the default settings and click Finish.
18. Click Start to start the database logger then minimize it, but DO NOT close it.
Wonderware Training
Lab 13 Alarming
View Alarm History and Event History
19. Select Start/Programs/Microsoft SQL Server/Enterprise Manager to launch the SQL
Server Enterprise Manager.
20. In the left pane under Console Root expand Microsoft SQL Servers.
6-19
6-20

21. In the left pane, highlight Microsoft SQL Servers/(local)/Databases/WWALMDB/Views.
In the right pane, right click on v_AlarmEventHistory and select Open View/Return all rows.
Wonderware Training
Lab 13 Alarming
Here you can investigate the details of the alarming history with time and date stamp, values,
etc.
6-21
6-22
Wonderware Training

Section Objectives
This section will discuss the role of changing the network account and how to use the Change
Network Account Utility to accomplish that task. After discussing this section the student will be
able to:
z
Understand the role of the Change Network Account Utility, and;
Have an understanding of how it can be configured.
Change Network Account Utility

The Change Network Account utility is a tool you can use to manage credentials for node-tonode communications between ArchestrA components.
During the initial installation of an ArchestrA component, you are prompted either to create a new
user account or to use an already existing account, and provide a user name and password for
that account. The same account must be used on each computer that requires communication
with others in the ArchestrA environment. Use the Change Network Account utility to change this
data, if necessary, on any computer after installation of an ArchestrA component.
WARNING! If you change user account data with this utility, you could adversely affect
communications between the computer and others with installed ArchestrA components (including
existing FactorySuite products that are ArchestrA enabled). All ArchestrA nodes that require
communication with others must use the same account, user name, and password. Use this utility
only to standardize user account data on all computers requiring communication. Do not delete
this account with operating system account management tools. If you do, the IDE will stop
functioning properly. If you delete the ArchestrA user account on an IDE node, you must recreate
it with the Change Network Account utility.
Node-to-Node Communications
All computers that have installed ArchestrA-enabled software must be able to communicate with
each other. This communication is enabled through an ArchestrA-specific user account set up
during the initial installation of an ArchestrA component on each computer.
Subsequent installations of ArchestrA components do not prompt for user account
information. They automatically use the account set up during the installation of the initial
component.
The user account described in this document only enables node-to-node communications
between ArchestrA components. It is not associated with ArchestrA security, which provides user
authentication for individual access points to the infrastructure.
Note: You must have Administrator privileges on the computer to make changes with the Change
Network Account utility.
To recreate an ArchestrA user account

1. Start the Change Network Account utility by selecting Start/Programs/Wonderware/
Common/Change Network Account.
6-23
6-24
The Change Network Account dialog box appears.
The data shown in this dialog box are those settings entered during the initial installation of an
ArchestrA component on the computer. The password options are shown blank for security
reasons.
Wonderware Training

The Change Network Account utility allows you to change the current data shown in the
dialog box, including:
z
Changing the password of the current account.
Creating a new local user account.
Using an existing local machine or network domain account.
2. In a single-node ArchestrA system, create any account.

3. In a multi-node ArchestrA system, recreate the same user account with the same user name
and password that was created on all other computers that have installed ArchestrA-enabled
software.
4. Once you have configured the account, click OK.
Note: After you recreate the user account in the Change Network Account dialog box, the
Microsoft Windows security component on your computer may take several minutes to update
this information on the ArchestrA Galaxy node. Until that occurs, your IDE may not function
properly. Rebooting the Galaxy node causes this update to occur immediately.
When you use the Change Network Account utility to create or use an account that is different
from the one originally set up during installation, the old account is maintained (not deleted).
6-25
6-26

WARNING! After you change any data shown in the Change Network Account dialog box,
ensure that all other computers that have installed ArchestrA-enabled software use the same type
of user account with the same user name and password.
Error Messages
When using the Change Network Account utility, you may encounter the following error messages.
Error Message
Action Required
Administrative privileges are

required to run this utility.
You must have Administrator privileges on the computer to run this

utility. Click OK, login as a user with Administrator rights, and start the
Change Network Account utility again.
The Password was not correctly

confirmed. Please ensure that the
Password and Confirmation
match exactly.
You mistyped either the password or confirmation password in the

dialog box. These two passwords must match to ensure the accuracy
of user account data. Click OK, retype both password and confirmation
password text, and then click OK again.
Password cannot be empty.

Please enter a valid password
You must type a password in the Change Network Account utility. Click
OK, type a password in the dialog box, type the same password in the
Confirm Password box, and then click OK again.
User account 'a' already exists.

Please enter another user name.
You chose to create a local account by selecting Create Local

Account in the Change Network Account utility. This account already
exists. Click OK, type a new user name in the Change Network
Account utility, and click OK.
Domain/Local Machine name

cannot be empty.
You must enter an existing local machine or network domain account.

Click OK, either type a valid network domain name or select the local
machine name from the list, and click OK. If you dont know the valid
network domain name, ask your network administrator.
User account 'a' does not exist.

Please enter another user name.
You chose to use a local machine or network domain account that

does not exist. Click OK. Ensure the user account you entered in the
Domain/Local Machine Name box is valid and the user name and
password you typed are valid for that user account, and then click OK.
If this message is displayed again, check with your network
administrator about the existence of the account.
The password policy for this

account allows the password to
expire and to be changed.
However the password must not
expire or should not be changed
for the ArchestrA products to
function properly. Do you want to
use this account?
You chose to use a local machine or network domain user account

whose password policy allows the password to be changed or to
expire. Click OK if you want to use this account or Cancel to return to
the Change Network Account utility. Then, you can choose to use or
create another user account.
Do you want to update user

account 'a' to use this new
password?
You chose to use a local machine user account, but the password you
typed does not match the account's password. Click OK if you want to
change the password for this user account or Cancel to revert to the
original settings. If you click OK, the password for the account is
changed. If you click Cancel, the Change Network Account utility is
displayed, allowing you to correct the password or type another user
name and password.
Invalid Domain name 'dom'.

Please enter a valid domain
name.
You typed an invalid network domain name in the Domain/Local

Machine Name box. Click OK, retype the domain name, and click OK.
Wonderware Training
Caution! We recommend that you do not use a domain account whose

password expires periodically or can be changed. Using such an
account is allowed, but after the expiration date or the password is
changed, node-to-node communications end. You then must use the
Change Network Account utility on each computer to update the
account data to re-establish communications.

Error Message
Action Required
Invalid Password for user account

'a'. Please enter the correct
password.
You chose to use a network domain user account, but the password
you typed does not match the account's password. Click OK, correct
the password, confirm the password, and click OK.
The system will now reboot.

Please close all your open
applications and press "OK" when
you are done.
You changed account information in the Change Network Account

utility. The computer must be restarted to implement those changes.
Close open applications, and click OK.
User name cannot contain these

characters: " / \\ [ ] : ; | , + * ? < >
Please enter a valid user name.
You used one or more invalid characters in the User Name box. Click
OK, type a valid user name and click OK.
A user name cannot consist solely

of periods [.] or spaces.
You must type a user name in the Change Network Account utility.
Click OK, type a user name in the dialog box, and then click OK again.
Multiple NIC Computers

Any node in your Galaxy that contains more than one network card must be configured according
to the following instructions to ensure communications with other ArchestrA nodes.
Note: If a multiple NIC computer in your Galaxy uses only one NIC, you should disable all cards
except the supervisory network.
For any multiple NIC ArchestrA node to communicate successfully with all other Galaxy nodes,
you must define the correct order of network connections in the network services of the computer.
Open the Network and Dial-up Connections dialog box (see image below) and rename each
card with a clearly identifiable function (for instance, "Supervisory Net" and "PLC net"). Different
operating systems provide unique access to the Network and Dial-up Connections dialog box
(in Windows 2000 Professional, click Start; point to Programs, Accessories and
Communications; and then click Network and Dial-up Connections).
6-27
6-28

Next, you must order the network cards properly. In the Network and Dial-up Connections dialog
box, click Advanced Settings on the Advanced menu. In the Advanced Settings dialog box
(see image below), use the up and down arrows to define the correct order of Connections and
click OK. The first connection in the list must be the supervisory network card. If a computer
contains more than two network cards (for instance, a supervisory connection, a PLC connection,
and an RMC connection for ArchestrA redundancy), the supervisory net must be listed first and the
others can be listed in any other position.
Several other parameters must be configured to ensure successful node-to-node communications

in the ArchestrA environment. You must configure the IP address and DNS settings as follows for
each network card to function properly.
Do the following for each network connection
1. In the Network and Dial-up Connections dialog box, right-click the network connection and
click Properties in the shortcut menu. The connection's Properties dialog box (see image
below) is displayed.
Wonderware Training
2. Select Internet Protocol (TCP/IP) in the list of components used by this connection, and click
Properties. The Internet Protocol (TCP/IP) Properties dialog box (see image below) is
displayed.
6-29
6-30
3. For the supervisory network, select Obtain an IP address automatically. For the other
network connections, select Use the following IP address. Consult your network
administrator for the proper settings for the remainder of the parameters in this group.
4. Click Advanced. The Advanced TCP/IP Settings dialog box (see image below) is displayed.
Click the DNS tab.
Wonderware Training
5. For the supervisory network, select Register this connection's addresses in DNS. For the
other network connections, clear this check box.
6. Click OK.
6-31
6-32
Wonderware Training
Section Objectives
z
Familiarize you with the background concept of historization, and
Enable you to understand details of historizable configuration.
Historization Background
The history system supports historization of process data in distributed history architecture.
One or more InSQL products can be installed on the same network as the App Server Galaxy.
The Galaxy can be configured to store history data into one or more of those InSQLs. Since the
Engines use push technology to historize, the InSQL box does not have any ArchestrA software
requirements.
Each Engine in the Galaxy is configured with the location of the InSQL storage node to which its
history data is to be sent. This configuration is stored in an attribute within the Engine.
InSQL requires an InSQL tag to be configured in its database for each attribute to be historized by
an AutomationObject. Thus, there is a one-to-one relationship between a historized object and a
tag in InSQL.
When an AutomationObject starts up it registers its configuration data with InSQL using an InSQL
supplied interface. If the InSQL tag already exists, it means this object has been previously
registered. If the InSQL tag does not exist, it is created automatically. In either case, the object
receives back a unique identifier (handle) for that tag. This is a push-style configuration model,
meaning the configuration data for each historized property of an object is dynamically, and
automatically, pushed to InSQL. The user does not need to run InSQL configure and import tags
from App Server (as done with InTouch today).
For storage, the story is similar. When an object decides to store a new VTQ to InSQL, it pushes
that storage update message, with the new VTQ, to InSQL using an InSQL supplied interface.
InSQL must exist on a different node from the AutomationObject. The history primitive uses the
previously-returned unique identifier for the InSQL tag that corresponds to the historized property
to identify the tag being stored.
Note: Alarms are stored at the Platform, history is stored at the Engine.
History Configuration
Historizable Data Types for Attributes
Attributes of the following data types support historization:
Float (numerical)
Double (numerical)
Integer (numerical)
Boolean (non-numerical)
String Unicode (non-numerical)
CustomEnum (non-numerical)
6-33
6-34

maps to InSQL Integer
ElapsedTime (numerical)
Maps to InSQL Float, converted to seconds.
Entire arrays or portions of arrays are not supported.
All numerical attributes are sent to InSQL in the engineering units form exposed by the attribute,
and InSQL does not scale the value. Additionally, the historized object does all change detection
and value deadbanding. All update packets sent to InSQL are stored to disk.
Configuration of a non-numerical Attribute for Historization

For an object that has non-numerical historizable attributes, the IDE user can enable history for
each attribute. No other configuration data is provided by the user since these attributes are
historized upon change of value. Also, a change in data Quality, regardless of whether the Value
changed too, always causes a new record to be historized/stored.
Configuration of a numerical Attribute for Historization

For an object that has numerical historizable attributes, the IDE user can enable history for each
attribute. Once enabled, certain configuration settings can be specified. These settings determine
how often data is historized.
The following configuration settings can then be specified:
z
Value Deadband the threshold value (measured in engineering units) that the absolute
value of the difference between the new and last-stored values must differ before storing
the new value to history. A value of 0 is valid and is the default and means that some
change is required prior to storing the value. A change in Quality always causes a new
record to be stored, regardless of whether the Value has changed.
Force Storage Period this is the time interval, in seconds (floating point), at which the value must
be stored regardless of the value deadband setting. In addition to the Value Deadband setting, the
value will be stored continuously at this interval. A value of 0 disables this feature.
Trend Hi specifies the initial maximum trend value for clients.
Trend Lo specifies the initial minimum trend value for clients.
Dynamic, Automatic Configuration of InSQL at Object Deploy Time

When an AutomationObject is deployed that has been historized, the object causes a dynamic
reconfiguration of the InSQL product. Each historized property causes a new tag to be created
and configured automatically in InSQL at deployment time. The InSQL storage system to be
configured is configured in the engine object itself.
If the link to the InSQL product is down at deploy time, the attempt to dynamically reconfigure
InSQL is achieved at the time the InSQL link is recovered. In other words, automatic retry is built
in.
Reconfiguration of InSQL at Object Redeploy Time

When an AutomationObject that has been historized is redeployed, the object causes a
reconfiguration of any changes that were caused by the redeploy to be changed in the InSQL
product automatically. For example, if the engineering units string for the tag changes from Deg
F to Deg C upon a redeploy, the InSQL configuration database must reflect this change.
Wonderware Training
Reconfiguration of InSQL at Object Undeploy Time
When an AutomationObject is undeployed that has been historized, object does not cause any
dynamic reconfiguration of the InSQL product. In other words, the InSQL tag and all its history is
left in the InSQL historian. This means the history data can still be examined in the future even if
the AutomationObject is no longer deployed.
InSQL Installation and Deployment

InSQL is installed and deployed using its standard mechanism. InSQL can be deployed on any
PC in the Galaxy, or on a PC outside the Galaxy but on the local network. InSQL requires a SQL
Server Database for its configuration data. This SQL Server Database can be the same or
different one used by the Galaxy Repository. More than one InSQL can be utilized by a single
Galaxy. However, a single engine sends its history to only one InSQL.
A single InSQL can receive historical data from a single Galaxy only.
InSQL Value Mapping

The update packet to be sent to InSQL contains a Value. This value may need to be converted
from the value received from Message Exchange if the received datatype is not one of the native
InSQL datatypes as specified below:
Enum historize as Integer ordinal value
Strings InSQL strings are limited to 512 characters, so truncation may occur. If so, Quality is set
to Uncertain.
NaN Handling
For Float and Double attributes, a potential value is the IEEE NaN encoding for the float or double
representation. NaN values can be generated for attributes that are to be historized. These NaNs
will be accompanied by a Bad OPC Data Quality. In any case, NaN is a valid value that can be
generated for floats and doubles. Unfortunately, InSQL clients do not handle NaN properly.
Therefore, ArchestrA will convert the NaN value to a Null value representation just prior to sending
to InSQL.
InSQL Quality Mapping

The Industrial Application Server Data Quality is somewhat different than the InSQL data quality.
The plan is for InSQL to support the OPC Quality definition. Thus, the 16-bit value for the OPC
Data quality is sent to InSQL. Within those 16-bits, the low order byte is the standard OPC part.
Wonderware reserves the high order byte. The Good, Bad, Initializing (which is a form of Bad) and
Uncertain states are in the low order byte per the OPC standard.
Any change in the OPC Quality, regardless of whether the Value component has changed, will
cause storage of a new record to InSQL. This means that a point that has an identical value over
some period of time with varying qualities will have multiple records stored to InSQL. The quality
stored in InSQL is to be the actual quality of the attribute in App Server with no modification.
However, InSQL may insert artificial quality (e.g. 24) and null value in the database when certain
situations such as disconnects occur. It does this in cooperation with the ActiveFactory clients to
project the right information on the client.
InSQL Timestamp mapping

The timestamp to be sent to InSQL for each attribute value/quality update is sent by the object in
the VTQ packet. Both App Server and InSQL use UTC time.
6-35
6-36

Application Server History Storage Performance
The link from the Application Server to InSQL may fail or be down for any of a number of reasons:
z
The network connection to InSQL goes down unexpectedly.
The InSQL storage node goes down or fails unexpectedly.
The Galaxy Platform and its Engines which are generating history startup prior to InSQL
node startup in a recovery situation.
History data must be preserved in these cases by having it stored locally until the link to
InSQL has recovered or InSQL has started. This is called store/forward. This capability is
limited by the hard disk capacity of the system where data is stored before forwarding.
The maximum data storage size to be consumed by store/forward must be configurable in
the Platform. Also, whether store/forward is enabled/disabled can be configured.
When store/forward capacity is consumed, the oldest data is discarded in preference to

newer data.
Wonderware Training
Introduction
An Industrial Application Server engine object can be configured to historize properties of the
objects it hosts by specifying the location of the InSQL node. When an object with a historized
property is deployed on an engine that has been configured to historize, a tag is built in the InSQL
MDAS group and the engine pushes the data to InSQL at the specified cycle (this cycle can not be
faster than the engine scans). If a connection to the InSQL machine can not be made at deploy
time, the engine will store the history to a path specified. In this lab, we will configure an objects
attributes to be historized by IndustrialSQL Server (InSQL). We will use the ActiveFactory
Trend object in InTouch to trend these attributes.
Objectives
z
Configure the objects instances to be historized.
Configure the App Engine and Platform to push data to InSQL.
Check Industrial Application Server connection to InSQL Server.
View data trend with the ActiveFactory Trend object in InTouch.
6-37
6-38

Tasks
Configure the LIT Template Object
1. Double-click on your XYLIT Template object to open its editor.
Select the History tab.
Wonderware Training
2. Check the box for PV. Leave the Value deadband at 0.0. Set the Trend high to the maximum
value of your object and the Trend low at the minimum value.
Then Lock all attributes.
Configure the TankSystem Template

4. Double-click on your XYTankSystem Template object to open its editor.
6-39
6-40

5. Select the UDAs tab and create a UDA called InletValve with a Data Type of String and
Category of User Writeable.
6. Create three (3) more UDAs as follows:

Name
Data Type
Category
LIT
Float
User Writeable
OutletValve
Integer
User Writeable
TransferPump
Integer
User Writeable
Wonderware Training
7. Select the Extensions tab.
6-41
6-42

8. For InletValve check Input extension and configure the Source as me.XYInletValve.PV.
Also, check History extension and lock it.
Note: If you configure the Input Extension as me.XYInletValve it will default to

me.XYInletValve.PV.
Wonderware Training
9. Configure the remaining UDA extensions as follows:
Name
Input Extension
Source
History extension
LIT
checked
me.XYLIT.PV
checked and locked
OutletValve
checked
me.XYOutletValve.PV
checked and locked
TransferPump
checked
me.XYTransferPump.PV
checked and locked

11. Redeploy the Tank System instance.
6-43
6-44

Configure the Engine
12. Double-click on the Engine object.
Wonderware Training
13. On the General tab, check the History box for Enable storage to historian. Verify that
100MB is selected for the Store forward deletion threshold.
6-45
6-46

14. Configure the Historian by typing in APU00 as the selected node
or
click on the ellipses box
APU00 node.
15. Click OK.
Wonderware Training
to activate the Browse Node dialog box and highlight the
Configure the Platform
17. Double-click the Platform object. At the General tab configure the History store forward
directory as follows:
Enter C:\S&F for the History store forward directory
19. Redeploy the Platform.
20. Configure the Deploy dialog box as follows and click OK.
Check the box for Cascade Deploy
Check the box for Force Off Scan
Check the box for OnScan
6-47
6-48
21. Click Close.
Wonderware Training
Configure ActiveFactory Trend
22. Select Start/Programs/Wonderware/ActiveFactory/Trend to launch the ActiveFactory
Trend.
23. Right-click on the Server icon and select Connect.
6-49
6-50

24. Configure the Connect to IndustrialSQL Server dialog box as follows:
InSQL Server
APU00
Select Use SQL Server authentication

Login Name
wwUser
Password
wwUser
Click OK.
25. Expand the Public Groups/Analog Tags and locate your object name in the TagName area
below.
26. Double-click the tag to add it to the Trend.

27. Click on the Live Mode icon to configure the Trend to update dynamically.
28. In the Auto refresh mode dialog box select 1 second from the drop down box and click OK.
Wonderware Training
Your trend will appear similar to the following example:
6-51
6-52
Wonderware Training
Module 7
Securing the Galaxy

Section 1 Security Overview
7-3
7-13
7-2

Module Objective
Configure, deploy, and test security with InTouch and Application Server.
Wonderware Training

Section Objective
Introduce Security with Application Server and InTouch.
ArchestrA security is designed to prevent users from performing unauthorized activities. This
includes users of:
z
The IDE when configuring and deploying objects.
The System Management Console (SMC) when performing maintenance and system
administration functions.
View (or other GUI client applications) when performing runtime operations including
monitoring, control and data entry functions.
Other future ArchestrA utilities.
The system is not designed to stop malicious access to the system. The security system is
designed to support the normal operating parameters of an automation system. Passwords are
encrypted but they are stored in a database that is accessible. So, the system is not designed to
stop determined programmers from accessing the system.
If your application requires a higher level of security, this can be achieved by typical IT
departments using tools provided by Microsoft. To facilitate a higher level of security, the security
model can be configured to support operating system authentication. In that case, the
configuration and runtime permissions can be mapped to the external operating system account.
Some options include password timeout and electronic signature authentication.
The ArchestrA Security Model

See the image below for a visual hierarchical overview of the ArchestrA security model. This
shows the relationships of the objects in the Security Model to each other and to the rest of the
ArchestrA System.
7-3
7-4
Each attribute of an AutomationObject is given a security classification. This provides the ability to
define who can write to attributes of an object.
For example, a certain attribute of the DiscreteDevice may be set by the operator to change its
status while a different attribute may be set by a technician. These attributes are meant for
different people, Operator (operate) and Technician (tuning). Configuring access to all users for all
AutomationObjects on individual bases would be a time-consuming and repetitive effort. Thus,
configured Roles and Security Groups can be applied to Users to enable easier configuration of
the Security Model.
Security Groups are simply the grouping of objects that you want to behave in the same way with
respect to security. Every AutomationObject belongs to exactly one Security Group. By default all
new objects belong to the Default Security Group, which cannot be removed. Roles generalize
Users function, such as Intake Operator or Dispatcher. Roles are granted permissions onto a
number of Security Groups. If, for instance, a Role is granted Tuning access to a Security Group,
then that role has write permissions to all object attributes with a security classification of Tuning
(but none other). Roles are also granted utility functions-based permissions, such as Deploy or
Can Edit.
For example, a Role of Software Engineer is created. This Role has full permissions to modify the
objects in the IDE, and has permissions to deploy as well. To undeploy an object, though, the
system requires that the object is offscan. Control of offscan/onscan is controlled by Operation
permissions -- not granted to the Software Engineer, so he cannot undeploy any objects in Onscan
mode. Only an operator (with Operation permissions) can do so.
Permissions are required to perform most ArchestrA activities. Usually only one permission is
required to perform a given activity, but occasionally, two or more permissions may be required for
operation-critical actions.
Wonderware Training

The final aspect of the Security Model is the User. This describes the access to the system
allowed by a User. The User can be granted as many Roles as needed to perform their job.
ArchestrAs security system is configured in the Edit Security dialog box by:
1. Enabling Security
2. Defining your Security Model
3. Mapping Users to the Security Model
4. Mapping AutomationObjects to the Security Model
If the Security is not enabled then Authentication mode is disabled.
Authentication Mode
7-5
7-6

On the Authentication Mode page, choose the mode of Galaxy security:
z
None: The default setting for new Galaxies, this mode is considered Open Security. It
leaves all functions open to all users. No authentication is provided for any operations in
the ArchestrA configuration or runtime environment. No login dialog boxes are displayed
for operating Industrial Application Server utilities or runtime processes.
Galaxy: This mode uses local galaxy configuration to authenticate the user. Use this
setting to create a user security system controlled by the Galaxy database.
OS User Based: This mode enables the Authorization of individual OS users. Use this
setting to take advantage of the operating system's (NT) user authentication system, on
an individual user basis.
OS Group Based: This mode enables the Authorization for users based on which OS
Groups they have been assigned to. Use this setting to take advantage of the operating
system's user authentication system, on a group basis. When you select OS Group
Based Authentication mode, the following Configurable Intervals options are displayed:
Login Time: This value (in milliseconds) is the timeout period during which the
system validates the user's membership against the OS groups selected as ArchestrA
Roles. After this timeout period, the login operation defaults to the local cache. The
result of a successful login for a value other than 0 (zero) is that local cache is stored/
updated. If the login operation times out and the user has performed a previous
ArchestrA login on the computer, local cache is used; if the user has never performed
an ArchestrA login on the computer, the ArchestrA login fails. Minimum allowed value
is 0 (zero); maximum is 9,999,999. Default value is 0 (zero), which switches off this
feature (the operation does not time out). The Login Time option should be used
primarily for intermittent or slow network scenarios. The value you should use in this
option is determined by the speed of your network and by the number of groups
configured in ArchestrA. In other words, the slower the network or the higher the
number of groups, the greater the value should be for Login Time.
Role Update: This value (in milliseconds) is the time between each validation attempt
per OS group for the user's membership when a login is attempted. The user
membership update is done one role per Role Update interval to minimize network
usage. Minimum allowed value is 0 (zero); maximum is 9,999,999. Default value is 0
(zero), which switches off this feature (the operation does not pause between
validating user membership and groups). This option should be used primarily for
intermittent or slow network scenarios. This option operates independently of the
Login Time option. In other words, even if Login Time times out, the role update
operation continues in the background and eventually updates user-to-role
relationships for this user in the local cache.
Note: When you select Authentication Modes, note the messages relevant to your ArchestrA
installation that are displayed in the Note box.
Wonderware Training

Authentication Mode selections provide the following general results:
z
Open security gives all users the Defaultuser credentials. No login dialog boxes are
presented to users during configuration, administration or runtime operations. Login dialog
boxes are presented for all other Authentication Modes.
If you have previously configured security under one Authentication Mode and then you
switch authentication modes, only those users created while configuring the new mode
are enabled. Other users are not deleted, just disabled in the new mode.
When you close the Configure Security dialog box after selecting any Authentication
Mode other than None, you must login. This action ensures that the new security model
can be enforced. If you select Cancel on the login dialog box, the IDE closes.
When you switch to None from another Authentication Mode and click OK, the IDE is
shut down.
When Galaxy authentication is selected, each user must provide a user name and
password in a login dialog box. The security system authenticates the user's credentials
against Galaxy user data. Access to all operations in the IDE and anywhere in the
ArchestrA environment are granted based on the logged in user's associated roles and
permissions. The IDE customizes the user interface to the user's previous preferences (for
instance, which Application Views are shown). The logged in user's name is shown in
the status bar of the IDE.
When OS User Based authentication is selected, each user must provide a domain, user
name and password in a login dialog box. The security system ensures that the OS user is
authorized to use the IDE.
When OS Group Based authentication is selected, each user must provide a domain, user
name and password in a login dialog box. The security system first ensures that the user
is authorized to use the IDE. Then the system authorizes the user's credentials against
operating system groups mapped to security roles in the Galaxy.
Note: In both OS-based authentication modes, a user is not presented with a log in dialog box
if that user has authorization to use that ArchestrA utility.
z
A user can have multiple accounts within the security system. For instance, a user may
have an account that provides permissions for working with instances but not templates.
The same person may have another supervisory account for working with templates and
managing users in the ArchestrA environment. To switch between levels of authority, the
person must login as the new user. To do this, click Change User on the Galaxy menu.
If the Security is not enabled then Authentication mode is disabled.
7-7
7-8
OS Group Based Security
If you use OS Group Based Authentication Mode, you should first familiarize yourself indepth with
the functions of the Windows operating system, particularly its user permissions, groups and
security features. ArchestrA OS Group Based security leverages those Windows features.
Take note of the following behaviors that are unique to OS Group Based Authentication Mode:
z
A newly-added user working on a computer that has no access to the Galaxy node cannot
write to an attribute on a remote node if that user has never logged on to the remote node.
This is true even if the user has been given sufficient runtime operational permissions to
do writes. To enable remote writing capabilities, log on to the remote node at least once.
If you log in to ArchestrA on a workstation that belongs to Domain A and Domain

Controller A fails, locally cached login data is used on subsequent logins. When the
domain controller returns to operation, your login will fail during the time period that trusts
are being reestablished by the controller. If during the controller outage, your username/
password data was changed, you may be able to use the old login data if you intend to
work locally. If you want to perform remote operations, you should attempt to log in with
Wonderware Training

the new login data. If that fails, the trusts are being reestablished by the controller, and you
should retry at a later time.
z
If you attempt to log in to ArchestrA on a workstation running Windows 2000, login will fail
until you properly set the TCB privilege in Local Security Policies. Do this as follows: On a
Windows 2000 Server computer - on the Start menu, point to Programs and then
Administrative Tools, and then click Local Security Policies (On a Windows 2000
Professional computer - on the Start menu, point to Settings and then click Control
Panel. In the Control Panel, double-click Administrative Tools. In the Administrative
Tools utility, double-click Local Security Settings.). In the left pane of the Local Security
Settings dialog box, expand the Local Policies folder and click the User Rights
Assignment folder. In the right pane, double-click Act as a part of operating system. In
the Local Security Policy Setting dialog box, add the user (the user logged in to the
computer) by selecting the Local Policy Setting check box, and then click OK. Log off
and log in to the computer again to implement the new TCB privilege. You must be an
administrator to set TCB privilege.
The list of domains and user groups appears differently in the group browser depending
on whether you have configured your domain as a Mixed or Native domain. Your unique
appearance should map to the list of domains and user groups you see when you use the
Windows tool for managing your domain. A domain group that is configured as
"Distribution" rather than "Security" cannot be used for security purposes.
The user's full name is not available to any client (for instance, an InTouch window) if the
domain controller is disconnected from the network when the user logs in to ArchestrA for
the first time. If the user previously logged in to ArchestrA when the domain controller was
connected, the user's full name will still be available to the client from data stored in cache
even if the domain controller is disconnected when the user subsequently logs in to
ArchestrA.
User Authentication
Client utilities like IDE, SMC, and View require their users to be authenticated so that the
appropriate permissions can be confirmed. An authenticated user is granted the sum of all
Permissions within their assumed Roles.
Supported Operating System User Configurations

The following is the list of supported Operating System (OS) user configurations that are
supported within the security system:
z
Login using an OS user who has been authorized and whose password has expired. The
user will get the message Login Failure: The specified account password has expired.
The user will then be able to change the password.
If the OS user is a new user and the account has been configured to require the password
to be changed on the first logon, on attempting the login they will receive the message
Login Failure: The password for the specified account must be change before first logon.
Supported Operating System Security Configurations

The following list of OS security configurations will be supported:
z
Machines and users participating in a domain.
Users being drawn from multiple domains.
7-9
7-10

z
Machines and users defined within a Workgroup. Note the users/groups have been
defined on each machine and imported into the Galaxy Repository (GR) and defined as
Local Host.
Minimal Operating System Permissions Required for Launching OS User

The OS user account must not be required to have any special privileges to enable it to utilize the
client utilities. Specifically it must not require the user to be an Administrator on the host machine.
The user will be able to change their own OS password from within the ArchestrA utility.
Logon Dialog
If security is enabled within the Galaxy, a client utility Logon dialog will be displayed. Application
Server provides a standard login dialog.
The login will appear:
z
The user explicitly chooses a Log On option from within the UI. It is not necessary to
explicitly Log Off before logging on using a different User Profile. The previous user will
be implicitly logged off.
Username and Password are entered onto this dialog.

If OS Authorization is being used then the user will also be required to select from a list of
accessible domain name for the user being logged in.
Logon Object
A Logon COM object is provided for use by any OS client utilities that need to log on to Application
Server. This COM object either provides a Log-on Dialog or is driven silently by an automation
interface. OS authentication and log on dialogs may be leveraged.
Wonderware Training
InTouch Access Level within Roles

The role will contain an additional Access Level that is required for legacy InTouch applications.
This will be utilized by InTouch to manage its internal access. When InTouch asks for its Access
Level, then the greatest Access Level for the roles assigned to the logged in user will be returned.
Attribute Security Classifications

Operators interact with AutomationObjects by accessing their Attributes. For example, a Valve is
opened by setting its objects Command Attribute to OPEN.
Attribute SecurityClassifications classify Attributes of AutomationObjects (like the above
Command attribute) from a security perspective. They are:
z
FreeAccess Any User can write to these attributes to perform safety or time critical
tasks that could be hampered by an untimely logon request (e.g. halting a failing process).
This does not require the user to have any privileges.
Operate Operators write to these attributes during normal day-to-day operations. These
include Attributes such as Setpoint, Output and Control Mode for a PID Object, Command
for a Discrete Device Object, etc. This requires the user to be assigned to the Security
Group of this AutomationObject, to allow the write.
Secured Write Operators write to these attributes for normal interaction with a highly
secured object forces re-authentication. This requires the user to be assigned to the
Security Group of this AutomationObject, to allow the write. The AutomationObject will
reject the write requested via the return status and the user must re-enter the login details.
Verified Write Operators write to these attributes for normal interaction with a very
highly secured object. This is similar to Secured Write, however it also requires a second
user authentication. The second user must also be assigned to the Security Group of this
AutomationObject, to allow the write.
Tune Writing to these attributes is considered a tuning activity. Examples are attributes
that adjust alarm setpoints, PID sensitivity, etc. This requires the user to be assigned to
the Security Group of this AutomationObject, to allow the write.
Configure Writing to these attributes is considered a significant configuration change.

For example, a PLC register that defines a Discrete Device input. This requires the user to
be assigned to the Security Group of this AutomationObject, to allow the write. It also
requires that the Object is currently OffScan.
View-Only The attributes are never written to at runtime, regardless of the user's
permissions.
There are two other situations where an Attribute's Security Classifications are specified:
z
When a User-Defined Attribute is configured.
When an Engineer overrides the Attribute Security Classification within a Template editor.
Note: Overriding Security Classifications is not permitted within Instances.
Security Across Multiple Galaxies

The ability for user profiles to span multiple galaxies will be supported in future versions.
7-11
7-12
Wonderware Training

Introduction
As we work with the security settings within the IDE we will set up various Roles and Users and
configure them with different sets of permissions. We will then observe the differences in the
Object Viewer as we logon as various users.
In this lab, we will create an instance of the SecurityTest Template, configure it, create an
Instance, and deploy it. Objectives
z
Create, configure and deploy an Instance SecurityTest Template called

XXSecurityTest_001.
Configure the Security settings for AppServer.
7-13
7-14

Tasks
Create and Configure a Derived Template Called $XYSecurityTest
1. Expand Template Toolbox.
Right-Click $UserDefined Object. Create a New/Derived Template and rename it
XYSecurityTest.
2. Assign $XYSecurityTest to your Toolset.
Wonderware Training

3. Double-Click $XYSecurityTest to open this object and select the UDA tab.
Click the + symbol to add a UDA.
4. Name the attribute Att1_FreeAccess.

Press Enter.
Click the Shield symbol to select the security level.
Select Free Access.
5. Repeat steps 6 and 7 for the following attributes:

UDA Name
Datatype
Security
Att1_FreeAccess
Boolean
Free Access
Att2_Operate
Boolean
Operate
Att3_SecuredWrite
Boolean
Secured Write
Att4_VerifiedWrite
Boolean
Verified Write
Att5_Tune
Boolean
Tune
Att6_Configure
Boolean
Configure
Att7_ReadOnly
Boolean
Read Only
7-15
7-16
6. Save and Close the editor and Check In the object.
Create an Instance Called $XYSecurityTest

7. In the Model View, create an instance of XYSecurityTest (it will be XYSecurityTest_001) and
assign it to your Line1.
Wonderware Training

Configure Galaxy Security
8. From the Galaxy menu, select Configure/Security.
7-17
7-18

9. Select Galaxy for the Authentication Mode.
Wonderware Training

10. Click the Security Groups tab.
11. Click the Add button to add a new group.

Name the new object TestGroup.
7-19
7-20

12. Select the Default Security Group.
13. Select the XYSecurityTest_001 instance object from the list in the right pane.
Wonderware Training

14. Drag XYSecurityTest_001 onto TestGroup in the left pane.
Select TestGroup again.
Note that XYSecurityTest_001 is now associated with TestGroup in the right pane.
15. Click the Roles tab.
7-21
7-22

16. Click the Add button.
Name the new Role TankOperator.
Press Enter.
Double-Click in the Access level field and assign TankOperator an access number of 500.
17. Click the Users tab.
Wonderware Training

18. Click the Add button to add a new user.
Name the new user Operator.
Press Enter and keep Operator selected.
Check TankOperator in the bottom pane. This will include Operator in the TankOperator
role.
19. Click the Change Password button to change the password.
7-23
7-24

20. Enter a new password and click OK. Here we are using the word password as the password
but your instructor may have you select a different password.
21. Click the Roles tab.

Select TankOperator.
Expand TestGroup in the Operational permissions pane in the lower right corner.
For the TankOperator TestGroup check the box for
Can acknowledge Alarms
Can modify Operate attributes
TestGroup will be checked automatically.
Wonderware Training

22. Select Administrator.
Expand TestGroup in the Operational permissions pane in the lower right corner.
For the Administrator TestGroup check the box for
Can modify Configure attributes
Can modify Operate attributes
7-25
7-26

23. Click OK.
Youll notice now that we have set the Galaxy to something other than Security of None, we
now have to identify who it is that is accessing the Galaxy.
In the future you can always change users by selecting from the Galaxy/Change User from the
menu bar.
24. Enter Operator and the password and click OK.
Wonderware Training

Deploy the SecurityTest Instance
25. In the Deployment View, right-click on the XYSecurityTest_001 instance object and deploy it.
26. Open the Object Viewer, add a watch window and rename the Tab to Security.
27. Add the following attributes to the Watch Window:
z
Att1_FreeAccess
Att2_Operate
Att3_SecuredWrite
Att4_VerifiedWrite
Att5_Tune
Att6_Configure
Att7_ReadOnly
ScanState
ScanStateCmd
Compare the attributes that are available while being logged on as the Operator vs. the
Administrator vs.the Developer.
28. In the Object Viewer, from the menu bar select Options/Change User.
29. Change to Administrator and click OK.
Notice the task bar at the bottom of the Object Viewer now indicates the Administrator is
logged in.
7-27
7-28
30. in the Object Viewer test the functionality that is available to the Administrator. Modify the
values of the Att* attributes to verify the security setting configured in the previous steps.
Note: Your instructor will demonstrate the Configure User Information dialog box where you can
change the default settings for various functions such as Prompts, Initial Scan state for deployed
objects, Scan state defaults and other User defaults
31. Right click on your XYSecurityTest_001 object and select Properties.
Select the Change Log tab.
Here you see the log of the changes made that affect the object.
Wonderware Training
32. Click Close.

33. Verify that the Alarm DB Logger Manager is still running.
7-29
7-30

View Alarm History and Event History
34. Select Start/Programs/Microsoft SQL Server/Enterprise Manager to launch the SQL
Server Enterprise Manager.
35. In the left pane under Console Root expand Microsoft SQL Servers.
Wonderware Training

36. In the left pane, verify that Microsoft SQL Servers/(local)/Databases/WWALMDB/Views is
still highlighted.
In the right pane, right click on v_EventHistory and select Open View/Return all rows.
Here you can investigate the details of the event history and the details associated with each
event.
7-31
7-32

IDE Security
37. In the IDE, select Galaxy/Configure/Security.
Wonderware Training

38. Select the Roles tab and select Default role.
Under IDE Permissions/Framework configuration uncheck can modify the security
model.
7-33
7-34

39. Select the Administrator role.
Verify under IDE Permissions/Framework configuration that can modify the security
model IS checked.
Note: Actually, the can modify the security model cannot be set to unchecked for the
Administrator.
Click OK to close the Configure Security dialog box.
Wonderware Training

40. In the IDE, select Galaxy/Configure/Security.
You will be reminded that the Operator has not been configured to change security.
41. Click No.
42. Logon as Administrator.

In the IDE, select Galaxy/Config Security. You should see no error and be able to config
security.
7-35
7-36
Wonderware Training
Module 8
Galaxy Maintenance
Section 1 Exporting and Importing a Galaxy
8-3
8-13
Section 2 System Management Console (SMC)
8-29
8-2

Module Objectives
Obtain an overview and understanding of:
z
How to Export and Import Galaxies;
How to use the System Management Console to manage platforms.
Wonderware Training

Section Objective
z
This section will discuss some fundamental functions dealing with Galaxy Maintenance.
Specifically, we will illustrate how to Export for future use and how to Import a galaxy
created previously.
Exporting Galaxy Objects

When exporting Galaxy objects there are three options available. These are:
z
Exporting Automation Objects
Exporting All Automation Objects
Galaxy Dump
Each of these has unique features and characteristics which are discussed in this section.
Exporting Automation Objects

Use the IDEs export function to share objects with other users or to recreate them in other
Galaxies. The resulting file (.aaPKG extension) contains the selected objects, their associated
templates and the configuration state of those objects. The export file can later be imported into
the same or another Galaxy.
Subsequent exports retain the default folder as last used for the duration of the IDE session. If the
designated file already exists, you are prompted to confirm overwrite.
If any of the selected objects are currently checked out, only the checked in versions are exported.
Exporting an entire Galaxy is similar to using the Galaxy Database Manager utility to back up the
database. However the change logs for the objects are not exported while they are saved during
backup. Also, the backup process retains security model settings for objects while exporting them
does not.
Note: When exporting an object that uses a script function, the script function is not transferred
with it. You must ensure that the script function libraries are transferred separately.
To export an object
1. Select an object in the Template Toolbox or Application Views pane.
2. From the Galaxy menu, select Export/AutomationObject(s).
8-3
8-4
Note: You can export more than one object with this function by first multi-selecting objects
(Shift+Click or Ctrl+Click). If you want to export all of the objects in the Galaxy, point to
Export and then click All AutomationObjects.
3. The Export AutomationObject(s) dialog box is displayed. In the export dialog box, browse to
the path and filename (.aaPKG extension) of the export file and click Save. Click Cancel to
terminate the export function. If you click Save, a progress box is displayed.
Wonderware Training
4. When the export process is finished, click Close. The resulting .aaPKG file can be used to
import the chosen objects into another existing Galaxy.
Note: Export maintains containment relationships that were previously specified. Also, if an
object is currently checked out, the last checked in version of the object's configuration is
exported.
8-5
8-6

Exporting All Automation Objects
The Exporting All Automation Objects function is much like the Exporting Automation Objects
procedure. The key difference being that with the Export Automation Objects function only the
objects that are selected are exported into a .aaPKG file. With the Export All Automation Objects
function all of the objects and any derived templates are also exported.
The procedure is as follows:
Use the IDEs export function to share objects with other users or to recreate them in other
Galaxies. The resulting file (.aaPKG extension) contains the selected objects, their associated
templates and the configuration state of those objects. The export file can later be imported into
the same or another Galaxy.
Subsequent exports retain the default folder as last used for the duration of the IDE session. If the
designated file already exists, you are prompted to confirm overwrite.
If any of the selected objects are currently checked out, only the checked in versions are exported.
Exporting an entire Galaxy is similar to using the Galaxy Database Manager utility to back up the
database. However the change logs for the objects are not exported while they are saved during
backup. Also, the backup process retains security model settings for objects while exporting them
does not.
Note: When exporting an object that uses a script function, the script function is not transferred
with it. You must ensure that the script function libraries are transferred separately.
To export all automation objects
1. From the Galaxy menu, select Export/All AutomationObject(s).
Wonderware Training

2. The Export AutomationObject(s) dialog box is displayed. In the export dialog box, browse to
the path and filename (.aaPKG extension) of the export file and click Save. Click Cancel to
terminate the export function. If you click Save, a progress box is displayed.
3. When the export process is finished, click Close. The resulting .aaPKG file can be used to
import the objects into another existing Galaxy.
One key factor to mention is that the security model settings for objects does NOT get exported
when using the Export function. In order to export those you would have to use the Backup
process in the Galaxy Database Manager in the System Management Console (SMC)
discussed in the next Section of this manual.
Exporting a Galaxy Dump File

Object instances and their configuration data can be exported to a comma-delimited format Galaxy
dump file (.csv extension).
8-7
8-8
Note: This function only dumps instances. Templates cannot be dumped. The .csv file contains
the configuration for the checked in versions of the selected objects as well as the checked-out
objects of the user who initiates the Galaxy dump. The file contains only those attributes that are
unlocked and configuration time-writeable, one column per attribute. Attributes that are locked,
calculated or runtime writeable only are not saved to the file. Attributes that are not text based (for
example, type QualifiedStruct) are not dumped. Object Help files are not dumped.
To export objects to a Galaxy dump file
1. Select an object in the Application Views pane. You can export more than one instance with
this function by first multi-selecting objects (Shift+Click). Also, you can dump all instances
derived from a template by selecting just the template.
2. Select Export on the Galaxy menu and then click Galaxy Dump. The Galaxy Dump save
dialog box is displayed.
3. Browse to the name and location of the .csv file to which you want to dump the selected
instances. Click Save to continue or Cancel to end the export function. The Galaxy Dump
progress box is displayed.
Wonderware Training
4. After the Galaxy dump process is finished, click Close. A .csv file has been created containing
the selected objects and configuration data.
The actual .csv file that has been created.
Galaxy Dump File (.csv) Structure

Dumped objects are organized in the resulting .csv file based on the template each is derived
from. A header row per template indicates the instances columns reference. Comments can be
added in the resulting .csv file by adding a line preceded by a semi-colon.
8-9
8-10
Note: Carriage returns in scripts associated with dumped objects are replaced with "\n" in the .csv
file. If you edit the dump file, do not delete the "\n" characters. If you edit scripts in the dump file,
use "\n" for a carriage return. This character set is interpreted as a carriage return when the dump
file is used in a Galaxy Load function. When editing a script in a dump file, use "\\n" if you want to
include the character "\" followed by the character "n" in a script. This character set is not
converted to a carriage return in a Galaxy Load function.
Importing a Galaxy Load File

Object instances and their configuration data in an existing Galaxy can be exported to a commadelimited format Galaxy dump file (.csv extension). A .csv file can be edited in most text editors
and spreadsheet programs. Using editing functions like copy and paste, you can create quantities
of already-configured objects ready to be imported into your Galaxy.
Note: The contents of the .csv file is determined by the original Galaxy dump. A load file contains
only instances. Templates cannot be dumped and loaded.
Important: The Dump contains only Object Instances. For the Load to succeed, the templates
from which those objects were derived must already exist in the Galaxy.
To import a .csv file
1. Select Import on the Galaxy menu and then click Galaxy Load. The Galaxy Load dialog box
is displayed.
Wonderware Training

2.
In the Galaxy Load dialog box, browse to locate the .csv file that contains the objects and
configuration data you want to import. Select the file and click Open to continue or Cancel to
end the import function. The Galaxy Load Conflict Resolution dialog box is displayed. Use it
to resolve conflicts that occur if objects you want to load already exist in the Galaxy.
3. Choose the preferred conflict resolution and click OK. A progress box is displayed during the
Galaxy load process. Click Cancel to terminate the Galaxy load process.
A Galaxy Load dialog box appears indicating that the Load was successful.
8-11
8-12
All objects that were changed or created during the Galaxy Load process are checked out to
the logged in user.
Note: A comment line in a .csv file created in Microsoft Excel may create an unintended
default-value object. To avoid this scenario, open the .csv file in Notepad to ensure the
comment line does not contain quote marks.
Wonderware Training

Introduction
There are times when it may be desired to modify certain parameters of objects outside the IDE
environment and then load those changes back into the IDE. This lab will illustrate how objects
can be exported and modified externally. Subsequently they can be imported so as to create
additional instances of the objects.
We will create an instance of your Tank template and export it to a CSV file. There we will modify
it slightly and import it back into the IDE creating a new instance of that Tank with the changes. A
Flow Indicator Transmitter (FIT) object will then be created and another instance of the Tank with
the FIT will be created. Again, we will export those objects, modify them externally and import
them back into the IDE creating a new instance of Tank with the changes.
Objectives
z
Use the Galaxy Dump utility to export object instances.
Modify the file externally.
Use the Galaxy Import utility to import the modified file.
8-13
8-14

Tasks
Galaxy Dump and Load
1. Select the TankSystem_001 instance and its children. Then Export to a Galaxy Dump by
either right-clicking on the Tank, and selecting Export/Galaxy Dump.
Or,
From the File menu select Galaxy/Export/Galaxy Dump.
2. Save the file as TankTest1.csv.
Wonderware Training
You will see the Galaxy Dump dialog box indicating the dump as complete when it finishes.
8-15
8-16

3. Open TankTest1.csv in Notepad.
Note: We are using Notepad instead of Excel to open the file because CSV files built in
Unicode currently do not translate correctly in Excel.
Wonderware Training
4. For Tank and its children (Inlet Valve, Outlet Valve, Transfer Pump and LIT) change the
references to a different suffix (e.g., 001 to 301). Remember, the last digit represents a tank
number so it must be 0 or 1.
Note: It is recommended that you turn off WordWrap for ease of viewing.
8-17
8-18
5. Select File/Save As and save the file as TankTest2.csv. Be sure that it is a csv file.
Wonderware Training
6. In the IDE, select File/Import/Galaxy Load and select TankTest2.csv.
8-19
8-20
7. At the Galaxy Load Conflict Resolution dialog box select Skip and click OK.
Wonderware Training
You will notice the Tank has been imported essentially du;licating our original
XYTankSystem_001.
8-21
8-22

Galaxy Dump and Load PH Object
8. In the Template Toolbox, derive a template called XYPH from an Analog Device.
Wonderware Training

9. Assign the XYPH object to your Tank System TemplateToolset.
10. Create an instance of the XYPH template and assign it to your TankSystem_001.
8-23
8-24

11. Right click on your XYPH object and select Export/Galaxy Dump.
12. Save it as XYPH.csv.
Wonderware Training

13. Open XYPH.csv in Notepad.
14. Copy the last line and change the reference in the last line to XYPH_002.
15. Copy the last line again two more times and change the references to XYPH_003 and
XYPH_004.
16. Select File/Save As and save the file. Be sure that it is a csv file.
8-25
8-26

17. In the IDE, select File/Import/Galaxy Load and select your XYPH.csv file.
18. At the Galaxy Load Conflict Resolution dialog box select Skip and click OK.
Wonderware Training

You will see your original XYPH object and the additional three that you created directly in the
csv file. Since we did not change the TankSystem instance association we see they are
assigned to our XYTankSystem_001.
8-27
8-28
Wonderware Training

Section Objectives
z
Understand the role of the System Management Console, and;
Have an understanding of how it can be configured.
About System Management Console

The System Management Console (SMC) provides ArchestrA AppServer application diagnostics
by allowing you to view the run-time status of some system objects and to perform actions upon
those objects. Actions include setting platforms and engines in an executable or idle mode and
starting and stopping platforms and engines.
The System Management Console is used to assist system integrators and system administrators
in performing administrative tasks and diagnostics on an ArchestrA application. It provides
application infrastructure diagnostics by allowing the viewing of runtime status of some system
objects and the ability to perform actions upon those objects. Actions include setting Platforms
and Engines in an executable or idle mode and starting and stopping Platforms and Engines.
This tool is one in a series of administrative tools that can be used for diagnostic purposes on
ArchestrA applications. Another tool available for performing diagnostics on applications is the
Visual Local Message Exchange (VLMX) Test Tool, which allows viewing and modifying of
attributes of AutomationObjects. Because the Platform Manager is a Microsoft Management
Console (MMC) Snap-in, its interface is integrated into the MMC environment and it appears as a
single interface.
Features of the Platform Manager

Some of the key features of the Platform Manager are that it:
z
Runs with minimal ArchestrA and operating system requirements, equivalent to "Safe
mode"
Uses the local platform as the gateway to the ArchestrA application
Does not rely on the Galaxy Repository to exist
Allows viewing of the layout of the Galaxy Repository, Platforms, and Engines
Provides the ability to set Platforms and Engines OnScan or OffScan
Provides the ability to start and stop Platforms and Engines
Starting Platform Manager

Platform Manager is a common component of an Application Server application and it is available
from any PC node in the application that has a deployed platform; therefore, you do not need to
install it onto each node. This ensures that all nodes used within a galaxy have access to Platform
Manager.
When you use Platform Manager, you can access the platforms and engines deployed to the local
PC node and to any other PC node in the Galaxy. Platform Manager does not require the
GalaxyRepository to be installed on the PC node.
After highlighting a platform, you can use the Action menu to start or stop a platform, or set it
OnScan/OffScan. If the platform has security implemented, you must be logged on as a user
configured with the proper SMC permissions to start SMC, Start/Stop engines and platforms, or
write from the Object Viewer.
8-29
8-30
To Start Platform Manager

Ensure your AppServer application is running. Start Windows and click Start to start your
programs. Select Programs/Wonderware/System Management Console.
If Platform Manager has security enabled, the Platform Manager Login dialog box appears.
From the Platform Manager Login dialog box, enter your User Name and Password. If the
configured security is OS User Based, then select the domain from the Domain list box. Click OK.
Wonderware Training

After successfully logging in, or if no security is enabled for Platform Manager, the Platform
Manager appears under the ArchestrA System Management Console (SMC) root node.
Console Tree
The console tree has a Windows Explorer-type hierarchical structure layout, with the ArchestrA
System Management Console appearing as the root node and the SMC snap-ins appearing
below this node. Like Windows Explorer, the console tree can be expanded or collapsed by
clicking on the "+" or the "-" symbols that appear next to the snap-in.
The console tree shows the items that are available in the console. The snap-ins that appear
below the ArchestrA SMC node include the Platform Manager, the Log Viewer, the DAServer
Manager, and the Galaxy Database Manager.
The contents of the details pane changes as you select items in the console tree.
Details Pane
The details pane is comprised of two main elements:
z
Column headings: when Galaxy Database Manager is selected in the console tree, two
columns are displayed, Node and Galaxy. The Node column identifies which node a
galaxy resides on. The Galaxy column displays the galaxys name. Use this information
when backing up and restoring galaxies.
Data window: displays galaxy data.
The contents of the details pane changes as you select items in the console tree.
8-31
8-32

Security
For all ArchestrA administrative utilities, including Platform Manager, security is configured
through the IDE. By default, there is no security enabled for Platform Manager or any of the other
utilities.
There are four authentication modes for security that can be enabled for Platform Manager:
z
No authentication
Galaxy authentication mode
OS User Based authentication mode
OS Group authentication mode
When no security is enabled from the IDE, the user is automatically logged into Platform Manager
as "DefaultUser." Without security, the logon dialog box does not display when Platform Manager
is launched and the user is granted all permissions.
If the security configured from the IDE requires Galaxy authentication, OS User Based
authentication, or OS Group authentication, then some of the existing users and roles are not valid
and the user may not be able to perform some operations.
Galaxy Authentication
Galaxy authentication requires the user to log into Platform Manager every time the utility is
started.
OS User Based Authentication

OS User Based authentication allows users who have matching OS accounts to log in, while all
others are rejected.
OS Group Authentication
In OS Group authentication, the user defines roles that match OS Groups and at log in, the OS
Groups are matched with the roles.
Console Menu Commands

Upon opening the System Management Console there are a wide selection of options available
from the menu and icon bar:
The following commands are available from the Platform Manager Action menu when you select
a platform or engine in either the console tree or the details pane.
Wonderware Training
Command
Description
Configure
Allows configuration of the Log Viewer and Storage
Log Flags
Opens the Log Flag editor
Open Log File
Allows the opening of a Log File
Connect
Allows either local or remote connections configuration
Messages
Allows Messages to be exported, purged, or printed
Refresh
Refreshed the database
Help
Access to the System Management Console Help files
These commands are also available by right-clicking an item in either the console tree or the
details pane. The available commands are dependant on the current state of the object and your
security permissions. If you do not have permission to perform a particular command, then that
command is grayed out.
The following commands are available from the Platform Manager View menu when you select a
platform or engine in either the console tree or the details pane.
Command
Description
Filter
Allows filtering of Messages, Time Range, or Terminal Sessions
Find
Search capability on Process ID, Thread ID, Log Flag, Component, or

Message
Go To
Allows redirection to a Bookmarked location
8-33
8-34

Command
Description
Bookmarks
Allows Adding or removing of a Bookmark
Mark
Allows the entry of a Marker Message to the log
Choose Columns
Select specific columns to show or hide
Customize
Change the appearance of the view
Platform Manager Toolbar Buttons

The following toolbar buttons may appear on the console toolbar, but will vary depending on the
object that you select in the console tree and its current state.
Button
Description
Back
Forward
Up one level
Show/Hide Console Tree/Favorites
Refresh
Help
Filter
Enable/Disable Message Filter
Find
Fast Mark
Export
Print
Print Preview
Log Viewer
The Logger is an ArchestrA utility that records information regarding the activity occurring on the
computer. For example, it records start-up data, error conditions, and DAServer information.
Wonderware Training

The Log Viewer can:
z
Monitor messages on any machine in the system
Send a portion of the log to notepad or E-mail
Filter messages on a flag
Security for the log viewer is set at the galaxy level.

When running an ArchestrA application, the Logger runs as a system service. The Log Viewer
is a Microsoft Management Console (MMC) snap-in that provides a user interface for viewing
messages reported to the Logger. The MMC is a host or container utility for the Log Viewer with
its own generic functions.
Note: If a problem occurs while running an ArchestrA application, always check logged
messages by using the Log Viewer prior to calling Technical Support.
The Logger and Log Viewer are automatically installed when an ArchestrA component is
installed.
z
Logger - This is the background process that stores messages and events in the system.
This process occurs without any prompting from or interaction necessary from the user.
The logging process can be customized with the LogFlag Editor Snap-In utility. The
Logger is installed as a system service, and can be configured to be an Auto Service or
Manual Service. As an Auto Service utility, the Logger is started when the PC is booted
up. As a Manual Service utility, the Logger requires a manual start through the System
Services utility in Windows Control Panel. In either case, the logging process is always
started when an ArchestrA component begins functioning.
Log Viewer - This utility is used to view error and informational messages that are sent by
ArchestrA components. The look-and-feel and the format of the user interface can be
customized to suit individual needs.
Typical Log Viewer Usage

The Log Viewer is primarily a troubleshooting tool. After initially installing an ArchestrA-enabled
program and on occasion, you might check logged messages to determine whether all processes
are functioning well. But typically, you would use the Log Viewer to work through problems you
encounter with a DAServer, the IDE or other ArchestrA component.
Note: The Log Viewer displays error messages in red-highlighted stripes. These indicate
malfunctioning processes and should be resolved quickly. Warning messages are displayed in
yellow stripes. These indicate major events in the system.
A good strategy for troubleshooting problems
1. Gather as much information first about the process that is malfunctioning. For instance, you
attempted to deploy an object in the IDE and a message was displayed stating the deployment
was not completed. Note the function you attempted and the message you received.
2. Open the Log Viewer by clicking Start, pointing to Programs and then to Wonderware, and
then clicking System Management Console. In the SMC, select Log Viewer and then the
node the IDE is located on. Look for red and yellow messages. Also, use the information you
collected about the failed process to search for clues in the logged messages.
3. Use the Find command on the View menu to single out messages by message text or other
category of data, or use the Filter command on the View menu to reduce the number of
displayed messages based on message, time range or terminal session criteria.
8-35
8-36

The following chart indicates the key differences in Log Viewer and WWLogger.
The journey of a Log Message originates with the Application where Log Flags are generated.
These are passed to the Logger where they are then stored in the Log Message Storage. They
are then available for viewing by the LogFlag Viewer. The LogFlag Editor provides the capability
to edit the LogFlags. This is illustrated in the following diagram.
6
LogFlag Editor
LogFlag Viewer
5
3
4
Wonderware Training
2
1

Using Bookmarks
Bookmarks are unique labels you can apply to individual messages for quick access. They differ
from marks in that bookmarks are associated with specific messages while marks are messages
added below the message that is currently last in the log.
You cannot enter duplicate bookmark names for more than one message, and a message can
have only one bookmark.
The message window can display a Bookmark column, which is initially hidden by default. To
show the Bookmark column, right-click on the column header of the message window and click
Show. In the Choose Columns dialog box, click Bookmarks in the Columns Hidden box, click
the Show button to move it to the Columns Shown box and click OK. The Bookmark column is
added at the far right of the column header. Click and drag it to another position if you want. When
the text of a bookmark in the Bookmark column is partially obscured, point to it to display the
entire bookmark like a tool tip.
You can set bookmarks in two ways: adding a regular bookmark that you can name and setting a
fast bookmark that is named for you.
To add a regular bookmark to a message

1. Right-click the message and click Add Bookmark on the Bookmark submenu.
2. In the Add Bookmark dialog box, either accept the default name (Bookmarkx where x is a
number in an ascending sequence) or overwrite it with something more descriptive. You can
change the bookmark name in the Bookmarks dialog box at a later time. See "To manage
bookmarks" below.
3. Click OK to set the bookmark or Cancel to terminate the process.
To set a fast bookmark on a message

1. Right-click the message and click Fast Bookmark on the Bookmark submenu. A default
naming sequence is applied to the message (Bookmarkx where x is a number in an ascending
sequence). Alternatively, you can set a fast bookmark by selecting the message and clicking
the Fast Bookmark icon on the toolbar.
2. Change the bookmark name to something more descriptive, if necessary, in the Bookmarks
dialog box at a later time. See "To manage bookmarks" below.
To go to a bookmarked message
1. On the View menu, click Go To.
2. In the Go To dialog box, enter the name of the messages bookmark by typing it in the box or
selecting from the list.
3. Click Go To. The Go To dialog box remains open.
4. Use the Previous and Next buttons to go to the nearest bookmarked message above and
below, respectively.
5. When you are done searching, click Close.
Note: You cannot go to bookmarked messages that are currently hidden by a filter. If you cannot
find the desired message, disable filtering and try again.
8-37
8-38

To manage bookmarks
1. On the View menu, click Bookmarks.
2. In the Bookmarks dialog box, you can manage current bookmarks and create new ones. The
bookmark list shows the current set of bookmark names and associated Message No. (the
same number as the No. column in the message window). The bookmark list provides several
functions.
3. For instance, to rename a bookmark, select it, press F2 and type the new name. Note that
each bookmark must have a unique name; so you cannot bookmark two messages with the
same name.
4. To go to a bookmarked message, double-click on it in the list or select it and click Go To.
5. To remove one or all bookmarks from your logged messages, select a message and click
Remove, or click Remove All.
6. To add a new bookmark, select the message you want to bookmark in the message window
and click Add. This function is comparable to a fast bookmark. Rename it by pressing F2.
7. When you are done, click Close.
Note: Bookmarks are not saved when you quit the Log Viewer application. To mark your
message log more permanently, use the Mark command on the View menu.
Galaxy Database Manager

Selecting the Galaxy Database Manager on the SMC Menu allows you to view all the galaxies in
the Galaxy Repository, as well as the nodes they reside on.
You must have Administrative privileges to use the Galaxy Database Manager.
DAServer Manager
The DAServer Manager allows local or remote configuration of the DA Server and its device
groups and items, and can monitor and perform diagnostics on DAServer communication with
PLCs and other devices.
Like the LogViewer and Platform Manager, the DAServer Manager is a Microsoft Management
Console (MMC) snap-in. Many high-level functions and user-interface elements of the DAServer
Manager are universal to all DAServers; to understand the DAServer Manager, it is critical to read
the documentation for both the MMC and the DAServer Manager.
To read the documentation about the MMC and DAServer Manager, click the Help topics on the
SMC Help menu. Both the MMC Help and the DAServer Manager Help are displayed.
Wonderware Training
Module 9
DAServers and DI Objects

Section 1 DAServers
9-3
Section 2 DI Objects
9-7
Section 3 FactorySuite Gateway
9-9
9-15
Section 4 Intermittent Network Configuration
9-25
9-2

Module Objectives
z
DAServers and DI Objects and how they relate to the connectivity of our application to
external data.
FactorySuite Gateway and how it can enhance the connectivity of your application.
Wonderware Training
Section 1 DAServers
Section 1 DAServers
Section Objective
z
Become familiar with DAServer and its use with the Industrial Application Server.
Introduction
Wonderwares DAServer is designed to provide simultaneous connectivity between client
applications based on Wonderware SuiteLink, OPC and DDE protocols that run on Microsoft's
Windows 2000 and Windows XP operating systems and the data devices supported by the
specific protocol being translated.
Wonderware's DAServers also come with an exclusive new user interface called the DAServer
Manager, which is installed as a Microsoft Management Console snap-in. Its end-user benefits
include simple remote server activation, configuration and operation, and extensive protocol
diagnostic troubleshooting.
Several standard features are available with each DAServer, including:
z
Compliance with OPC version 2.05
Stand-alone operation mode
Support for hot configuration, device additions and device- and server-specific parameter
modifications
A wide range of DAServers support connectivity to numerous protocols and products.

Wonderware's current DAServers offering also includes support for:
z
Allen-Bradley's CIP protocol for ControlLogix
Allen-Bradley's TCP protocol
Allen-Bradley's DH Plus protocol
Siemens' Simatic Net S7
Modbus Serial protocol
Configuration
DAServers can be configured using the DAServer Manager utility. The DAServer Manager is an
MMC shell capable of displaying specific configuration pages for each configuration node. This
utility allows browsing and editing of servers on different nodes.
DAServers are hot configurable. In other words, they are configurable while the server is running
or even acquiring data. Certain restrictions imposed by the underlying network/protocol/hardware
might apply. For instance, if you uncheck System Items on the global parameters configuration
dialog of the DAServer Manager and select Apply, and then re-check System Items and Apply,
System Items data is valid only to newly connected clients.
The configuration data format for DAServers is XML. Any XML-enabled program (for example, IE
and XML Notepad) can read this format.
9-3
9-4

Component Architecture
A DAServer is comprised of three physical parts:
z
Plug-in Component(s): (responsible for communicating with clients, used by all

DAServers). Plug-ins provide protocol translation functionality for device integration
clients.
Typical Plug-ins use DDE, SuiteLink or OPC protocol, and serve as interfaces between
their clients and the DAS Engine. A protocol can be disabled when customizing the
installation for your DAServer.
DAS Engine: common component used by all DAServers.

The DAS Engine is a middleware component that exposes two sets of unique interfaces,
one for communicating with Plug-ins and one for communicating with Device Protocol
Layer components. It encapsulates common tasks for the DAServer, like handling the item
database, distributing data to clients, propagating clients' requests to the protocol, and
providing diagnostics.
Device Protocol Layer: Server specific (responsible for communicating with hardware and
specific to the DAServer). The Device Protocol Layer provides translation between the
hardware- specific protocol such as ModBus and CIP and the DAS Engine interface:
Each physical part of a DAServer is comprised of a set of .EXE and/or .DLL modules. ArchestrA
provides the Plug-in and DAS Engine modules.
Wonderware Training
Section 1 DAServers
You must create the Device Protocol Layer (server specific) modules with the DAServer, and all
three sets of modules are required for a fully functioning DAServer.
Plug-ins
Plug-ins provide protocol translation functionality for device integration clients. Typical Plug-ins
communicate in DDE, SuiteLink or OPC protocol, and serve as interfaces between their clients
and the DAS Engine. You can disable a protocol when customizing the installation for your
DAServer.
DAS Engine
The DAS Engine is a middleware component that exposes two sets of unique interfaces, one for
communicating with Plug-ins and one for communicating with Device Protocol Layer components.
It encapsulates common tasks for the DAServer, like handling the item database, distributing data
to clients, propagating clients' requests to the protocol, and providing diagnostics.
Device Protocol Layer

The Device Protocol Layer provides translation between the hardware specific protocol such as
Modbus and CIP and the DAS Engine interface.
DAServer Characteristics
Configuration
The DAServer Manager is capable of displaying specific configuration pages for all servers. This
utility allows browsing and editing of servers on different nodes.
Recall that DAServers are hot-configurable. In other words, they are configurable while the server
is running or even acquiring data. Certain restrictions imposed by the underlying network/protocol/
hardware might apply.
For instance, if you uncheck System Items on the global parameters configuration dialog of the
DAServer Manager and select Apply, and then re-check System Items and Apply, System Items
data is valid only to newly connected clients.
The configuration data format for DAServers is XML. Any XML-enabled program (for example, IE
and XML Notepad) can read this format.
Runtime
The DAS Engine is loaded by the DAServer as an in-process COM object.
It is not statically linked. In other words, a new DAS Engine (feature
enhancement or bug fix) would not require re-linking to the other components nor re-QA of those
other components. It is deployed to the system and attaches to all existing server components.
This is an important added value for the customer to be independent of ArchestrA release cycles,
especially for OEM customers with their own release schedule.
Newly deployed Plug-ins do not require re-linking nor re-QA of associated components. Even new
Plug-ins would not require any development effort for the other components. In fact, it is feasible to
implement new functionality (like Store-and-Forward) in a Plug-in to enhance the server without
involvement of the code of the other components.
9-5
9-6

Diagnostics
The DAServer Manager diagnostic tool displays generic diagnostic objects common to all servers
as well as server-specific/server developer defined diagnostic data.
Hot Configuration
One of the big advantages provided by the DAServer is the ability to make your DAServer
configurable while the server is running - hot configuration.
The extent to which a specific DAServer is hot configurable varies from server to server. You can
choose from a variety of hot configuration responses, from not being hot configurable at all to
being configurable of each individual parameter while the server is running.
The DAServer handles most of the hot configuration work. In general, a user will run the DAServer
Manager and configure each hierarchy. Any changes she makes that add/delete/update a
hierarchy are sent immediately to the running DAServer.
Server-specific code may elect to react to the change. Some parameters cannot be changed while
the DAServer is running due to protocol-specific issues, and these can be ignored by the serverspecific code.
Here is a complete list of notifications to the server about changes in the configuration:
z
Add configuration hierarchy.
Delete configuration hierarchy.
Rename configuration hierarchy.
Update parameters of configuration hierarchy.
Add device group.
Delete device group.
Rename device group.
Update parameters of device group.
Clear the current configuration set.
Switch to a new configuration set.
Wonderware Training
Section Objective
z
Become more familiar with DI Objects and their use with the Industrial Application Server.
Introduction
Device Integration (DI) Objects are designed for applications that connect to the Industrial
Application Server. They represent the application's network and devices, and mirror the actual
device hierarchy. In the Industrial Application Server, Device Integration (DI) Objects are a subset
of Automation Objects available in the Template Toolset of the Integrated Development
Environment (IDE). As a subset of these Automation Objects, Device Integration Objects consist
of two parts:
z
DI Network Object, which represents the communications port and are thus associated
with DA Servers.
DI Device Object, which represents the physical devices that make up a network.
Examples of DI Device Objects are network bridge devices or PLCs. When the objects are
deployed, they represent the network hierarchy. Each level of this hierarchy can be
monitored for its individual status.
Device Integration objects are used to represent communications channels and field controllers.
As such, they are most often arranged in a hierarchy that models the physical hierarchy of the
network and devices on that network.
Device Integration objects are designed to make it very easy to integrate DAServers into the
ArchestrA environment.
Therefore, deploying a DI Network actually deploys the DAServer and its associated components
within the IDE/Galaxy. This facilitates the DAServer installation process for end-users.
DI Objects in the IDE

DI objects are located in the Template Toolbox and can also be imported into the Galaxy in the
same way as Application Objects. They are imported directly into the Device Integration area of
the Template Toolbox:
9-7
9-8
The differences between the Application and DI Objects are listed below:
z
DI Objects are associated with a DAServer.
DI Objects include some extra primitives in addition to the common Primitive (also hidden
by default. A special dialog provides access to the attributes developers might need to
override.).
DI Objects include extra dependency files.
DI Network Objects are hosted by an AppEngine, not an Area.
This impacts the Deployment view within the IDE.
The Host must be deployed before the object can be deployed.
DI Objects can be hosted by each other or by DI Networks.
GUIDs tie the host and the hosted object together.
DI Devices and DI Network objects have extra tabs within their editors to configure
ScanGroups, BlockReads, and BlockWrites.
Wonderware Training

Section Objective
z
This section discusses integration to third party applications, specifically through the
Integration to Third Party Applications

FactorySuite Gateway (FS Gateway) is a universal translator, capable of translating all major
protocols (MX, OPC, DDE, SuiteLink) to any protocol required by a network component.
A primary purpose of FS Gateway is to translate between ArchestrA MX protocol and other
protocols. For instance, an Industrial Application server, which uses MX, previously could not be
accessed by third-party clients except through InTouch. Excel, Visual Basic, and other third-party
applications were unable to receive data from FactorySuite products without using InTouch tags.
Using FS Gateway as a protocol translator allows direct connection to an Industrial Application
Server. FS Gateway can replace OPCLink, which translates OPC to DDE or SuiteLink.
FS Gateway is also useful for legacy servers, controllers, and operating systems. Gateway can
translate older DDE to the newer SuiteLink protocol, enabling legacy products to connect to newer
systems.
Other Connectivity Tools

Industrial Application Server can access device data by using client application objects. These DI
Objects ($DDESuiteLinkClient, $InTouch proxy, $OPCClient) enable the server to interface with I/
O devices that use DDE, SuiteLink, InTouch tags, or OPC protocol.
Other protocol connectivity tools include third-party OPC servers, the Archestra DAS Toolkit, the
Rapid Protocol Modeler Kit, the ActiveX SECS-II/GEM kits, and the InTouch Tag Creator.
I/O servers provide connectivity for devices using DDE, FastDDE, and SuiteLink protocols. I/O
servers can connect every FactorySuite 2000 and FactorySuite A2 component, as well as PLC,
RTU, DCS, and ESD systems.
9-9
9-10

You can build I/O servers using Wonderware's Rapid Protocol Modeler (RPM) Kit. The RPM Kit
can handle both serial and TCP/IP communications with either ASCII or binary protocols to
connect FactorySuite client applications to devices with non-standard protocols.
DAServers (Data Access Servers), provide simultaneous connectivity between plant floor devices
and DDE, SuiteLink and/or OPC-based client applications running under Microsoft Windows. The
DAS Toolkit allows you to create a DAServer specific to your needs. DAServer architecture is
modular, allowing for plug-ins for DDE/SL, OPC, and other protocols.
Wonderwares InControl software offers connectivity to third-party OPC servers and clients by
allowing you to create an OPC Server and/or OPC client. You can use the OPC set of interfaces to
collect and transfer data between software packages from any vendor. OPC uses the client-server
model and the Microsoft COM/DCOM protocols for vendor-independent data transfer. The
InControl OPC Server consists of these three primary types of objects: server, group(s), and
item(s). Each OPC item object represents a single data element in the data source and has a
name, value, time stamp, and quality. Items also have attributes and properties. OPC groups
manage the attributes of each item contained in them. The OPC server maintains the properties of
all OPC items. The InControl OPC server uses SuiteLink for communications.
In addition to its own database, SQL Server can act as a gateway to systems based on Oracle,
Sybase, Ingres and other databases. Once connected to SQL Server, external databases operate
as if they were part of the native SQL Server database. Data from multiple databases can be
combined in reports and queries.
Refer to the FactorySuite support website, especially the Compatibility Matrix, for more information
on specific connectivity tools.
FactorySuite Gateway FAQs

1) What is FactorySuite Gateway?
FactorySuite (FS) Gateway is an integration server and protocol translator that can be used to
integrate classic FactorySuite products with newer ArchestrA based products, as well as
exposing FactorySuite data sources as OPC Servers to third party applications and external
systems. FS Gateway therefore provides:
z
A Universal Protocol Converter for Wonderware Products
Exposes FactorySuite A2 as an OPC Server
Integration for classic servers
2) How is FS Gateway Delivered?

FS Gateway behaves like a DAServer and is therefore installed from the Wonderware Device
Integration Products CD.
3) How is FS Gateway Licensed?

FS Gateway is available for use with any Wonderware Product, at no additional charge. The
only stipulation is that it must be always used in conjunction with a Wonderware product, either
in a server or client connection capacity.
Wonderware Training

Release 1.0 of FS Gateway will not have license enforcement as part of the Wonderware
License Management Utility but will be restricted for use with a Wonderware product via a
paper license. A future version may contain license enforcement.
4) What product client protocols are supported?

DDE, FastDDE, Suitelink and OPC
5) What is the value provided by FS Gateway?

FS Gateway provides totally free OPC connectivity for Wonderware products as well as third
parties. This will allow a user to expose our classic IO servers as OPC servers and will allow
them to interface third party OPC client products to Wonderware products. Wonderware is one
of the few vendors who does not charge for OPC Server capability. It also breaths new life into
classic products, by adding OPC DA as a supported interface. This is especially important as
support for NetDDE is being phased out by Microsoft.
6) Why is FS Gateway needed?

z
To remove NetDDE dependency
To provide connectivity to earlier versions of InTouch
To provide NT support which will allow connections to classic products that have not been
migrated to later Operating Systems.
To provide OPC connectivity to FS products (e.g. InTouch and Industrial Application

Server)
To replace the OPCLink product used when connecting InTouch to OPC Servers.
To provide Industrial Application Server data for 3rd party clients
To provide a mechanism for the transport of IAS data between two different Galaxies.
7) Does FS Gateway provide Galaxy to Galaxy communications with ArchestrA and the Industrial
Application Server?
FS Gateway does provide the means for data access from an ArchestrA Object Attribute in
Galaxy A to an ArchestrA Object Attribute in Galaxy B, in the same fashion that an Object
Attribute in Galaxy A could receive data from any OPC Server. The plan is that a future release
of the Industrial Application Server will have built-in "Intergalactic Communications". FS
Gateway can still be used for this in the interim, but an even better solution is forth coming.
8) How is security controlled with FS Gateway?

When used with the Industrial Application Server, Role-based security is employed. That
means that a User is defined on the node where the FS Gateway is installed. That User
account is linked to an ArchestrA Role, which is linked to a Security Group, which is linked to
individual Object Attributes. Therefore, the defined user can only access those attributes
which it is assigned within the Galaxy. This needs to be managed carefully as any program
that utilizes that user account on the FS Gateway node, either locally or remotely can access
the associated attributes, with no specific knowledge of which external application is
accessing the Galaxy.
9-11
9-12

9) What are the common uses for FS Gateway?
z
Exposes InTouch as an OPC Server
Exposes InSQL as an OPC Server (live data only)
Exposes IAS as an OPC Server
Basic Galaxy to Galaxy Data Access
Exposes classic IO Servers (DDE) as a OPC DA or SuiteLink Servers
Basic Read/Write Data Access from Classic InTouch (pre-7.11) to a Galaxy
Factory Suite Integration (DT analyst, SCADAlarm, InBatch) to a Galaxy
Replaces InTouch OPCLink
Acts as a Data Concentrator for a client wanting access to many different sources.
10) What capability is there to browse tag and attribute values for products using the FS Gateway?
FS Gateway can "browse" InTouch and OPC DA Servers Data Connections. This is
accomplished inside the SMC which is the centralized place for configuration and diagnostics.
All other data connection items are manually entered (or alternatively can be imported from a
CSV file) before the data can be browsed. This "browse" is the ability to navigate the actual
native information (either on InTouch or OPCServer). Once a group is created and the items
created inside the group then a client can browse this "configured" data.
For the Industrial Application Server, it is necessary to manually enter the item names. This
can be done on the IAS platform first and then exported into a .csv file and then imported into
the FS Gateway. Once these items have been manually entered the OPC Client will be able to
browse the data. The user can still access data that has not been configured for browsing but
the item name must be known. SuiteLink inherently does not allow for browse capabilities.
11) How is the FS gateway configured and managed?

The FS gateway is configured like any other DAServer, by using the ArchestrA System
Management Console or SMC.
12) What data is accessible in the Industrial Application Server Galaxy via the FS Gateway?
The FS Gateway exposes 4 basic data types in a Galaxy. They are Boolean, String, Float and
Integer.
13) What is FS Gateway compatible with?

Client Products
z
DDE Clients [including FASTDDE V2 (pre-FactorySuite2000) and FASTDDE V3

(FactorySuite2000 Plus)]
SuiteLink Clients
OPC Clients (DA v2.05)
Server Products
z
DDE Servers
Wonderware Training

z
InTouch Data Source
ArchestrA Galaxy Data source from Industrial Application 2.0
SuiteLink Data Source
OPC DA Servers (v2.05)
14) Can I run more then one instance of FS Gateway on a single computer?
No, only a single instance of the FS Gateway can be run on a single computer at the same
time. This is similar to our DAServers.
15) Can I have multiple galaxies as data sources connected to an instance of FS Gateway?
No, the FS Gateway must be on the same platform as the Application Server and only one
instance of Application Server can reside on a particular platform.
16) How many clients can I have connected to an instance of FS Gateway?

As many as you like!
17) How many Data Sources can I have connected to an instance of FS Gateway?
The FS Gateway can act as a data concentrator and can access as many sources as you
would like to connect to (with the limitation of only one can be an Application Server).
18) What OS Versions is FactorySuite Gateway 1.0 Compatible with?

z
Windows XP
Windows NT 4.0
Windows 2000
Windows 2003
For additional information or details on how to access and configure Factory Suite Gateway please
refer to the Wonderware FactorySuite Gateway Users Guide.
9-13
9-14
Wonderware Training

Introduction
This lab will identify the steps needed to configure both the Instructor machine and the Student
machine for FactorySuite Gateway.
Objectives
z
Use the DAServer Manager to create and ArchestrA Object on the Instructor machine.
Configure the ArchestrA Object.
Understand how to activate the server in the SMC.
In the Student machine, create and configure a DDESuiteLinkClient object in the IDE to
connect to the Instructor machine.
9-15
9-16

Tasks
Instructor Configuration
Note: FactorySuite Gateway 1.0 must be previously installed on the Instructor's computer.
1. From the Start menu, select Programs/Wonderware/System Management Console to
open the SMC.
Wonderware Training

The System Management Console opens as shown below.
2. Expand DAServer Manager/Default Group/Local/ArchestrA.FSGateway.1 and select

Configuration.
9-17
9-18

3. Right-click Configuration and select Add ArchestrA Object.
4. Name the added object MyGalaxy.
Wonderware Training

5. Configure MyGalaxy as follows:
Reconnect Attempts:
Reconnect Period:
30000 MSec
Read Only:
Checked
6. Save the configuration.
7. Select ArchestrA.FSGateway.1.
9-19
9-20

8. Right-click ArchestrA.FSGateway.1 and select Activate Server.
Or,
Click the Activate Server icon on the icon bar.
Wonderware Training
Student Configuration
9. In the Deployment View, create an instance of the $DDESuiteLinkClient object by dragging
it from the Template Toolbox to the Application Views pane.
10. Name the instance XYInstructor.
11. Double-click XYInstructor to open the DDESuiteLinkClient editor.
9-21
9-22

12. Configure the General tab as follows:
Server node:
<instructor's node name>
Server name:
FSGateway
Communication protocol:
SuiteLink
13. Select the Topic tab.
Wonderware Training

14. Add a new Topic by clicking in the Add Topic button [+] in the Available topics section, name
the topic ArchestrA.

At the Check In dialog box, enter"Initial configuration and setup." in the Comment field and
click OK.
16. Assign XYInstructor to XYAppEngine.
17. Deploy XYInstructor. Verify that Initial Scan state is set to On Scan.
18. View the object in Object Viewer.
9-23
9-24

19. Type XYInstructor.ArchestrA.ABLIT in the Attribute Reference textbox (where ABLIT is
the Instructors LIT object) and press the Go button to add the reference to the Watch Window.
20. Press OK in the dialog box that pop-ups.
21. Verify that you're reading data from the instructor's galaxy.
Wonderware Training

Section Objectives
z
Understand the concept on Intermittent Networks and how to configure for them
Introduction
Intermittent networks are physically distributed networks that, because of low bandwidth and/or
high traffic, tend to have delays or breaks in communication.
Any distributed network that is routed (uses modems or radio transmitters) is considered
intermittent. A wide area network is also considered intermittent because of the time lag in
transmitting data. Industries such as water and waste control, telecommunications, natural gas
and oil distribution, in which fast response is not critical, can often use intermittent networks.
Intermittent networks are usually controlled by SCADA (supervisory control and data acquisition)
systems in which a central computer is used to communicate to remote PLCs or RTUs. A SCADA
system gathers real-time data, transfers the data to a central site, performs the necessary analysis
and control, and displays the information visually in an appropriately organized fashion. SCADA
architecture can easily be expanded to handle additional remote sites and I/O points.
A SCADA host performs centralized alarm management, data trending, and operator display and
control. The priority of SCADA is collecting and recording data events and alarms.
In a SCADA system, current status and commands are handled by local controllers (RTUs and
PLCs). SCADA systems employ RTU or PLC protocols including Modbus, AB-DF1, and DNP3.0.
SCADA communications can use a range of wired (lease line, dialup line, fiber, ADSL, cable) and
wireless media (licensed radio, spread spectrum, cellular, CDPD, satellite). IO servers and DA
servers collect data from remote units, then send this data to the Industrial Application Server
using OPC, or SuiteLink protocols.
Critical needs for the SCADA industry are timestamping, disaster recovery, security, and dealing
with bandwidth limitations.
z
Timestamping:
For RTU protocols where data timestamps may be retrieved from the remote site, it is
necessary that a DA Server or I/O Server acquire this timestamp and make it available
as a parameter of the data. Given the data's value and its timestamp, it is possible to
transfer the data's value and timestamp into the historical database or process the
data with event analysis algorithms. Such data transfer and processing require the
development of specific Application Server objects designed for this task.
RTU event information: For RTU protocols where event information may be retrieved,
particularly as structured blocks with point ID, value, timestamp, and description, a DA
Server or I/O Server must acquire the structured information and make it available for
processing. Typically this requires special programming to transfer the data to a
database. In particular the data may be transferred directly into the Industrial SQL
Server historian.
Disaster Recovery: For insuring the integrity of an operational system where the central
site is "at risk" from fire, tornado, hurricane or other catastrophe, it is important to establish
a site, physically separated from the central one, that has replication capability. The
replication capability includes having duplicated hardware, and requires that software
configuration and key 'state' information is periodically propagated from the central site to
the recovery site. Each disaster recovery scenario will be unique, thus it is important to
consult with system integration experts regarding the design of communications
equipment, hardware and the configuration of the software.
9-25
9-26

z
Security: Galaxy security is configured via the Security dialogue of the IDE. Users/Groups
are assigned, roles are created and mapped to Galaxy privileges, and individual
Application Objects are allocated to Security Groups. For geographically distributed
systems it is likely that the topology will involve the use of more than one Domain
Controller. Such a distributed topology allows that computer nodes at different sites are
joined to different Domain Controllers; the operators, engineers and technicians log into
those Domains. As long as their membership is then authenticated against Galaxy
authorized groups, they will have access to the capabilities of the system.
There is one specific requirement for the account used when installing the Industrial
Application Server bootstrap at each computer node. For a contiguous Galaxy, that
account must be identical on all computers in the system, i.e. it must be one Domain, one
user name and its associated password. The configuration of Microsoft Security with
Active Directory and DNS supports invoking such 'cross-domain' accounts when
configuring the bootstrap service at installation time. It is important to properly configure
the DNS settings for the NIC adapter to insure that multiple Domains are visible to the
computer.
Bandwidth limitations: Bandwidths of 56K or slower are dealt with using RTU technology
through a DAServer or I/O server.
Configuration and Deployment

Distributed InTouch HMIs
InTouch NAD (Network Application Development) can be used to design and configure systems,
and to maintain graphical interfaces in a physically distributed system. The server maintains a
master copy and clients maintain a copy of the master, so that if the master is unavailable, the
client keeps working. Note that remotely notifying client applications of InTouch over a slow
network is limited by the number and size of changes that may be effectively transmitted within a
reasonable amount of time.
Note: When NAD is used in a Terminal Services environment on a Win2003 machine, a share
must be created to the Master application even if the Master is on the Terminal Server Node.
When Not to Use Cascade Deployment

For large numbers of Platforms and Engines residing on computers that are situated over slow
network connections, it is not recommended that a Cascade Deployment of the entire Galaxy be
initiated. For such networks it is important to deploy the Platforms separately. Also, Platforms that
have complex combinations of Areas and Objects or large numbers of Objects should be selected
in smaller groups and deployed as groups.
Note: DCOM: In setting up the network, be careful in setting blocked ports. Some DCOM ports
need to be open to communicate with OPC. Leave open the ports that interact between
FactorySuite components.
Wonderware Training

7HUPLQDO
6HUYHU
9-27
'LDOXS
.ESV
OLQH
76&OLHQWV
(WKHUQHW
+LVWRULDQ'DWD
DQG$ODUPV
(QJLQHHULQJ6WDWLRQ
:HE6HUYHU
&RQILJXUDWLRQ'DWDEDVH
,QGXVWULDO$SSOLFDWLRQ6HUYHU
6XSHUYLVRU\1HWZRUN
'$6HUYHU
&RQWURO1HWZRUN
56
+(:/(77
3$&.$5'
5RXWHU
5785DGLR0RGHP
5785DGLR0RGHP
5785DGLR0RGHP
56
1HWZRUN
+8%0$8
1,&
87,/ ,=$7,21
7$%
*'
-$
0
%1&
0 E V
5(
.%
1
/HYHOWUDQVPLWWHU
+8%0$8
*' * '
7
9
:
; < =
8
7$%
*'
-$
(17(5
5 81
35 1
, 7
+(/ 3
%1&
0 E V
$/ 3+$
6+,)7
1,&
87,/ ,=$7,21
, )
/ &
2
*'
*'
5(
.%
/HYHOWUDQVPLWWHU
, )
/ &
0
1
*'
*' * '
*'
7
2
9
:
; < =
8
(17(5
5 81
35 1
, 7
+(/ 3
$/ 3+$
6+,)7
9-28

Reducing data traffic is especially important in intermittent networks. This can be accomplished in
many ways. Please refer to the Deployment Guide for detailed recommendations for reducing data
traffic.
Wonderware Training
Module 10
Visualization
Section 1 Visualization
10-3
10-13
10-33
10-39
10-67
10-2
Module Objective
z
Obtain an overview and understanding of how the Industrial Application Server integrates
with InTouch and InSQL
Wonderware Training
Section Objective
This section will familiarize you with an understanding of how Industrial Application Server
integrates with InTouch and InSQL from a visualization perspective
Integration with Other FactorySuite Products

In a few short years, the AppServer has emerged as the engine for e-business, acting as the
development platform for server-based applications, a key connector for integrating Web and
legacy systems and the launching pad for the next generation of IT infrastructure such as
enterprise portals and Web services. The AppServer is becoming the central piece of a larger,
more complex middle-tier computing infrastructure.
Because the fundamental ArchestrA architecture of AppServer comes bundled with an array of
products, such as databases, server operating systems, and Integrated Development
Environments (IDEs) it naturally follows that it act as the centerpiece of a much larger platform,
one that also includes integration, portal and edge serversnot to mention related technologies
such as identity management systems.
This trend has been long in coming. The recent Gartner report looked to label this evolution,
calling this extended AppServer platform the "application server platform suite."
The following diagram illustrates the concept of integration with existing systems, or, in our case,
other FactorySuite systems.
In this more detailed example it is clear that with the ArchestrA architecture of AppServer,
integration with FactorySuite is clearly the fundamental solution to plant floor management and
coordination.
10-3
10-4
In the following lab we will use the AppServer to interface with InTouch to see how the integration
with InTouch leverages the visualization of both InTouch and AppServer.
InTouch Integration
InTouchs communications protocol support has been expanded beyond SuiteLink and DDE
capabilities to include Message Exchange. WindowViewer acts as an anonymous Engine when
accessing Message Exchange. This means it has no attributes that can be accessed by Message
Exchange clients, and that it is not configured, managed or viewed as an AutomationObject within
the AppServer Galaxy. InTouch advises (subscribes to) only those items that are active. This
would be the currently displayed Window items and items needed for script execution. This
minimizes the Message Exchange subscription activity to those elements that are currently active.
Tag Browser
The browser enables InTouch WindowMaker environment to select an App Server database
source as a Tag Source for remote tags and browse through the namespace of the Galaxy. An
object attribute or property of an attribute is to be mapped to an InTouch remote tag.
Access Name
A pre configured Access Name called Galaxy is available in WindowMaker for Message
Exchange access. This Access Name will only be relevant for InTouch in the ArchestrA
environment. There will be no user configurable settings for this access name.
Wonderware Training
Tag Source
To create a Tag Source within InTouch the user will be required to give the tag dictionary a name.
Select the predefined Access name Galaxy and this will preset the Tag Source Type with a value
of Galaxy. The user then enters the connection information for the dictionary:
Username
Password
Name of Galaxy
Galaxy Location (This is the node where the Galaxy Repository is located.)
Tag Browser
With the new Tag Source, the user is presented with a list of all the objects within the target galaxy.
He can expand objects to see either the contained objects or the runtime accessible attributes.
The browser does not expose those attributes that start with an _ (i.e. marked as hidden) or any
attribute of type QualifiedStruct. The Column mappings are as follows:
Tagname = ObjectTagname.Attributename
Datatype = See list in next section for the datatype mappings.
Access Name =
AlarmGroup = Objects Area
Comment = Name of the Template that the instance was derived from
If the user has selected a tag from the App Server Browser then the next time a Browser is
launched from InTouch the App Server Browser will be automatically launched.
The following restrictions apply when the App Server browser is launched:
z
Only runtime visible attributes in a single Galaxys namespace are viewable, this will
include the capability to switch between an Objects TagName and its HierarchicalName .
The selection will be based on:
z
Runtime visible attributes
From a Currently Checked in AutomationObject
Where the attribute name does not have an _ following a .
The browser does not allow browsing of attribute datatypes that are not supported. See
the datatype mapping table in a next section for the list of attribute datatypes and their
mapping to InTouch.
The browser disallows selecting attributes that would result in an InTouch item name
length greater than the maximum allowed by InTouch, which is currently defined as 95
characters. Those attributes are not viewable in the browser The burden falls on the App
Server developer to use concise enough names to fit within the limitation of InTouchs item
name string length. The name displayed from the Galaxy is the Object
TagName.AttributeName plus [1] for each array dimension. The name length must
include all of these and the maximum length of a DotField name. So this allowable length
for a displayed attribute name as 80 characters.
The browser allows selection of a property of an attribute as detailed below. By default,

the Value property is selected when the attribute is selected.
Attribute Data Types

The following list is the Tag Source data types that will be displayed within the Tag Browser.
10-5
10-6
z
Boolean
Integer
Float
Double (Cast to InTouch Float)
String
Time (Cast to InTouch String)
ElapsedTime (This will be cast to InTouch float convert to seconds)
Reference (Cast to InTouch String)
Enumeration (Cast to InTouch String)
Attribute Properties
The WindowMaker Tag Browser and the Message Exchange client in WindowViewer add and
recognize special extensions to each Attribute in order to provide access to information that
otherwise would not be available to InTouch. These extensions are optional and do not need to be
used by the InTouch application. However, applications that are concerned with status and quality
information will likely use these extensions heavily. These items extend the name space of
attributes to include additional properties that WindowViewer can expose to application scripts
and Windows. For example, the reference to TIC101.PV.#ReadSts provides access to the
MxStatus information for the subscription to TIC101.PV. This information is very useful for
displaying extended information that is exposed by Message Exchange.
These items do not exist as object attributes in App Server (nor in Message Exchange as
attributes) as named elements. This is purely a client-side extension (supplied in the client
abstraction layer) that makes them appear to exist to the client. The Client Abstraction Layer
obtains the information that is provided by these elements from Message Exchange API calls (e.g.
UserGetStatusDescription(), UserGetQualityDescription()).
Attribute Extension
DataType
Purpose
None
Coerced
This is the default case. Means no extension was supplied.

The item should be read/written as normal, with the value
datatype coerced as appropriate to InTouch native type.
Failed read or write status information can be obtained if the
client subscribes in addition to the #ReadSts or #WriteSts
items described below. Example: Pump1.PV.
Wonderware Training
Attribute Extension
DataType
Purpose
.#VString
for floats/doubles
attributes only:
.#VString1
.#VString2
.#VString3
.#VString4
String
(read-write)
Sets up a subscription to the reference that is prefixed by

.#VString. This is the underlying reference. Returns the
current value of the underlying reference as a string (via
coercion) when both reads and writes are working correctly.
However, if the UserGetAttribute returns bad status, this item
returns an abbreviated Status description string (based on
MxStatus) instead of the value. The abbreviated status
description strings are:
?Pending for pending
?Warning for warning
?Comms for communications error
?Config for configuration error
?Oper for operational error
?Security for security error
?Software for software error
?Other for other error
If the status is good but the quality is bad, this item returns the
Quality description string (available from Message Exchange)
instead of the value. Only when quality and status are both
good, or when quality is uncertain and status is good, for
UserGetAttribute does it return the value as a string (this may
require coercion if the type returned by Message Exchange is
not a string). When uncertain, the value is always suffixed
with a ? to indicate the uncertainty of the value. For
example, 3.14 ? or True ?.
When a write is performed to this item, the client abstraction
layer does the UserSetAttribute to the underlying reference.
The return status from the UserSetAttribute call is used to
generate a status string, which is placed in the return value for
this item. This status will always be ?Pending initially. Later,
when the write completes, the returned string is updated as
follows. If the write does complete successfully, the returned
value for this item reverts back to the current value for the
underlying subscribed reference as a string as described
above. If the write returns an error or pending, the \Status
item continues to show the last write status even if
subscription updates continue to come in on reads. Error in
write status is therefore given priority over any read status.
This applies for only 20 seconds, at which time the value
reverts back to the read value. When the window is deleted,
then the logic resets for future subscriptions to this item.
For example, Pump1.PV.#VString actually registers the
reference Pump1.PV with Message Exchange. The Client
Abstraction Layer strips off the .#VString string and applies
the special logic described here.
For formatting of Floats/Doubles to a string format, the
.#VStringN options (where N=1-4) are provided. The N
indicates the number of decimal places to return in the
formatted string. For example, 3.1234 would be a valid
returned string for .#VString4. The .#VString acts as if N=0
for float and double.
10-7
10-8
Attribute Extension
DataType
Purpose
.#EnumOrdinal
Integer
(read-write)
Contains the currently read ordinal value for attributes of

Qualified Enum type. This is a way of returning an integer for
enumerations rather than a string. Since qualified enum
attributes return a string to InTouch by default, and InTouch
may need an integer for some animation links, this extension
allows the integer value to be accessed by applications. Only
exposed for attributes of type Qualified Enum. This causes a
subscription to the underlying item and does not require that
the item is already previously subscribed to. Example,
appears in InTouch as Pump1.PV.#EnumOrdinal. When this
item is registered with the client abstraction layer, it strips off
the .#EnumOrdinal part of the string and registers
Pump1.PV with Message Exchange. When the value
updates, the client abstraction layer returns the ordinal integer
value for the enumeration rather than the string.
.#ReadSts
String
(read-only)
Contains the current read-status of the subscribed to item that

this string is concatenated to (e.g. appears to InTouch as
TIC101.PV.#ReadSts). Provided by the MxStatus structure
and translating it to a string. Blank (empty string) if status is
OK. Otherwise, contains the abbreviated translated MxStatus
string. The abbreviated status description strings are:
(These strings are localizable within InTouch).
NOTE: This item cannot be written to since it is status of read
only.
NOTE: If the associated item (for example TIC101.PV) is not
currently subscribed, then this returned string is blank .
Wonderware Training
Attribute Extension
DataType
Purpose
.#WriteSts
String
(read-only)
Contains the last write-status of the item that this string is

concatenated to (e.g. appears to InTouch as
Pump1.Cmd.#WriteStatus). Provided by the MxStatus
structure and translating it to a string. Blank (empty string) if
status is OK. Otherwise, contains the full translated MxStatus
string. Otherwise, contains the abbreviated translated
MxStatus string. The abbreviated status description strings
are:
(These strings are localizable within InTouch).
NOTE: This item cannot be written to since it is status of write
only.
NOTE: If the associated item (for example TIC101.PV) has
not yet been written to, then this returned string is blank .
Data Type Support

ArchestrA Attributes/Properties can be of several datatypes that do not directly map to InTouchs
four primary datatypes. The following table defines how the client abstraction layer maps
datatypes for read and write operations. It also describes the datatypes that the Galaxy Dictionary
exposes within InTouchs Tag Browser.
Attribute/property
datatype
InTouch
datatype
Notes
Float
Float 32 bit
Pass thru.
Double
Float 32 bit
If double is IEEE NAN, then convert to float IEEE NAN. If

overflows, set .quality to bad and pass float IEEE NAN. If
double fractional value is a smaller fraction than the smallest
float fraction of 1.17549E-38, treat as 0.0 float and set .quality
to Good. (This is consistent with the double-to-float coercion
in MxValue).
Boolean
Discrete
False = 0, True = 1
Integer
Integer 32 bit Pass thru.
String (always Unicode)
String MBCS
( multi-byte
character set
encoded )
Truncate string if is too long for InTouch. Set quality uncertain

if it does so. Retain both bytes of each Unicode character.
Time
String
Unicode
(MBCS)
Format as appropriate string for locale. Use MxValue

conversion to string.
ElapsedTime
Supported.
Pass as float seconds. MxValue supports coercion to this

type.
MxDataType
String MBCS
Pass the string.
MxSecurityClassification
String - MBCS
Pass the string.
10-9
10-10
Attribute/property
datatype
InTouch
datatype
Notes
MxQuality
String - MBCS
Pass the string.
MxReference
String MBCS
Pass the reference string portion only as Unicode.
MxCategorizedStatus
String - MBCS
Pass the string.
MxQualifiedStruct
Not supported
Not supported. Return bad data quality and empty string.
MxQualifiedEnum
String MBCS
Pass the enum string. The integer ordinal value can be

accessed by applications by referencing .#EnumOrdinal. For
example, Pump1.PV.#EnumOrdinal.
Array of Strings
String MBCS
(read-only)
Put each element of the array into a comma separated string,

such as: String1,String2,String3
Up to the maximum string limit of InTouch string value. If
truncate, then associated quality sent to InTouch will be set
uncertain. Cannot write to an entire array of Strings.
All arrays
Integer, Float,
String, or
Discrete.
Only support the subscription to a single element of an array.

In that case the conversions above apply. Otherwise, return
empty string with quality Bad. An array shows up once and
only once within the browser.
For example, Object.AttributeArray[1]. The browser returns 1
as the index into the array and the user can change it to the
required value such as [3]. Single elements of arrays are
writable (attribute-category permitting).
MxInternationalizedText
String
This at runtime is accessed as a String type.
The table on the following page indicates a very detailed description of how the value/quality
mapping to various InTouch animations is to be implemented.
Sample Detailed Mapping Table:
App Server
Data Type
App Server
Value
App
Server
Quality
InTouch
Analog
Animation
InTouch
Discrete
Animation
InTouch
String
Animation
InTouch
String
(#VString)
float/ double
3.14
Good
3.14
On Msg
3.14
3.14
float/ double
3.14
Uncertain
3.14
On Msg
3.14
3.14 ?
float/ double
3.14
Initializing
3.14
On Msg
3.14
Initializing
float/ double
3.14
Bad
3.14
On Msg
3.14
Bad
float/ double
NaN
Good
0.00
Off Msg
NaN
float/ double
NaN
Uncertain
0.00
Off Msg
NaN ?
float/ double
NaN
Initializing
0.00
Off Msg
NaN
float/ double
NaN
Bad
0.00
Off Msg
NaN
float/ double
1.7E308
Good
0.00
Off Msg
1.7E308
float/ double
1.7E308
Uncertain
0.00
Off Msg
1.7E308 ?
float/ double
1.7E308
Initializing
0.00
Off Msg
Initializing
float/ double
1.7E308
Bad
0.00
Off Msg
Bad
Cust Enum
Open
Good
0.00
Off Msg
Open
Open
Cust Enum
Open
Uncertain
0.00
Off Msg
Open
Open ?
Cust Enum
Open
Initializing
0.00
Off Msg
Open
Initializing
Cust Enum
Open
Bad
0.00
Off Msg
Open
Bad
Boolean
True
Good
1.00
On Msg
True
Boolean
True
Uncertain
1.00
On Msg
True ?
Boolean
True
Initializing
1.00
On Msg
Initializing
Wonderware Training
App Server
Data Type
App Server
Value
App
Server
Quality
InTouch
Analog
Animation
InTouch
Discrete
Animation
InTouch
String
Animation
InTouch
String
(#VString)
Boolean
True
Bad
1.00
On Msg
Bad
String
In the bank
Good
0.00
Off Msg
In the bank
In the bank
String
In the bank
Uncertain
0.00
Off Msg
In the bank
In the bank ?
String
In the bank
Initializing
0.00
Off Msg
In the bank
Initializing
String
In the bank
Bad
0.00
Off Msg
In the bank
Bad
Integer
45
Good
45.00
On Msg
45
45
Integer
45
Uncertain
45.00
On Msg
45
45 ?
Integer
45
Initializing
45.00
On Msg
45
Initializing
Integer
45
Bad
45.00
On Msg
45
Bad
Time
5/10/2002
11:06:44 AM
Good
0.00
Off Msg
5/10/2002
11:06:44 AM
5/10/2002
11:06:44 AM
Time
5/10/2002
11:06:44 AM
Uncertain
0.00
Off Msg
5/10/2002
11:06:44 AM
5/10/2002
11:06:44 AM ?
Time
5/10/2002
11:06:44 AM
Initializing
0.00
Off Msg
5/10/2002
11:06:44 AM
Initializing
Time
5/10/2002
11:06:44 AM
Bad
0.00
Off Msg
5/10/2002
11:06:44 AM
Bad
ElapsedTime
5 03:42:22.22
Good
445342.22
On Msg
445342.22
445342.22
ElapsedTime
5 03:42:22.22
Uncertain
445342.22
On Msg
445342.22
445342.22 ?
ElapsedTime
5 03:42:22.22
Initializing
445342.22
On Msg
445342.22
Initializing
ElapsedTime
5 03:42:22.22
Bad
445342.22
On Msg
445342.22
Bad
Note: This table applies to good MxStatus. If MxStatus is bad, then the #VString string will
indicate the abbreviated status category such as ?Comms. For other animations such as
Analog, when MxStatus is bad, no operation is performed (no value is sent to InTouch and the
previous value is left as is).
LMX, NMX Client Abstraction Layer

The client abstraction layer has been modified to allow for Message Exchange communications.
When using Message Exchange, the client abstraction layer (and WindowViewer) can
communicate to a single AppServer Galaxy at a time. In addition, the client abstraction layer may
be using SuiteLink or DDE at the same time. To use Message Exchange, WindowViewer requires
that a single AppServer Platform object, and its prerequisites, be previously configured and
deployed to the PC upon which WindowViewer is to run. A Platform can be shutdown when
WindowViewer is running (for example by using the SMC). This situation is handled gracefully,
meaning WindowViewer continues to run and communicate with other applications using SuiteLink
or DDE. However, all subscribed remote tag references to MessageExchange must receive bad
data quality. When the Platform starts back up, WindowViewer resumes its communications to
MessageExchange.
IO Status
WindowViewer provides the status of each communications channel via the special (internal)
IOStatus access name. Within WindowMaker, the user can create a discrete tag that monitors
this special access name for the communications status to Message Exchange. The name of the
item on the IOStatus access name is the name of the topic. Since the topic name does not apply
10-11
10-12
for Galaxy communications, the topic name is assumed to be Galaxy for this case. So if the user
creates a Discrete Tag that monitors IOStatus:Galaxy, this tag provides the communications
status to message exchange. In all normal situations (even if the network is down), this status
returns 1 (or good) status. This is because the Galaxy communications is established locally via
LMX. Only when an unusual situation develops, such as the local Bootstrap or local Platform
being shutdown locally, will the communications status ever go to 0 (or bad).
Similar to the previous item, WindowViewer also provides the status of a communications channel
via a special item called Status that exists on every topic. Therefore, the Galaxy Access Name
also supports a special item called Status that indicates the status of the communications
channel. This status behaves the same as the one that exists on the IOStatus access name for
the Galaxy item.
Note that this basically makes Status a reserved word by InTouch, such that there should be no
object name in the Galaxy called Status. This is not enforced anywhere (other than by the user). If
there is an actual Galaxy object called Status, InTouch cannot see it.
Quality Data
The AppServer data quality on read operations (subscriptions) includes two major parts, the first
the AppServer enumeration and the second the OPC quality. InTouch uses only the OPC quality
part, placing it in the .Quality field for the remote tag. The client abstraction layer pulls out the
OPC quality part and returns it to InTouch. InTouch places this part in the .Quality field of the
remote tag.
Read and Write Status

Message Exchange read and write operations return an MxStatus structure which defines detailed
error information when an operation fails. This structure can then be translated into a humanreadable string by Message Exchange. InTouch makes this string information available to the user
for both read and write operations. This is accomplished though remote tag references that end in
the strings #VString, #ReadSts and #WriteSts.
Galaxy Security
Message Exchange operations are all processed as UserGet and UserSet requests and security
checking is performed by the receiving AutomationObject. Within InTouch both user sets and
script sets are treated the same.
The Galaxy can be configured to use either AppServer or InTouch security for user authentication
and authorization.
When Galaxy Security is in use no users will need to be created in the InTouch environment.
AppServer users will be authenticated against the AppServer security system. Domain users
would be authenticated through the OS. The AppServer Security Model contains the AccessLevel
used within Traditional InTouch Applications so that they can maintain the mechanisms for
controlling screen display. InTouch will then return the log in information to the same $Operator
Tags as is defined within the InTouch 9.0.
An additional script function has been added to InTouch that enables the user to write a script that
can determine if the currently logged in user has a defined Role. This enables the InTouch
developer to integrate their screen display scripts with the AppServer security model (enables
AccessLevel to be ignored).
If an InTouch Application is using InTouch mode then there is no Trust relationship between
InTouch and the ApplicationServer. If InTouch Security is being used then the user will always be
defined as the Default user.
Wonderware Training

Introduction
When using InTouch as the view component for Industrial AppServer the InTouch application
must reside on a node with a Bootstrap and Platform object deployed. In this configuration
InTouch will use the message exchange functionality of the Platform, enabling Galaxy namespace
browsing and increased data communication functionality. In this lab you will configure a remote
tag source to point to the galaxy, and map the ApplicationObject properties to InTouch Animation
Links for viewing.
Objectives
z
Set up properties in InTouch and configure tag sources to link them to our ArchestrA
application.
our objects in a common galaxy later in the course
10-13
10-14
Tasks
Configure InTouch Properties
1. Copy the appropriate application to your Drive C:
Note: Your instructor will provide you with the correct application.
2. Open InTouch.
3. In the InTouch Application Manager dialog box, select Tools/Find Applications to locate
the Application provided by your instructor.
Wonderware Training

4. Click on the WindowMaker icon to open InTouch WindowMaker.
5. Select the Properties window of the Application and click OK.
10-15
10-16
6. Double click on the text object (#) following the Attribute.PV.#String.
Wonderware Training

7. Select the Value Display, String.
8. Delete any existing expression and double-click in the white space area of Expression:
9. Click on the ellipse to create a new tag source definition.
10-17
10-18
10. Select New to create a new Tag Source.
Wonderware Training

11. Configure the Tag Source as follows then click OK:
Tag Source Name:
Your Galaxy Name
Access Name:
Galaxy
Tag Source Type:
Galaxy
GR node name:
Your Node Name
Galaxy name:
Galaxy currently running on your node
Generic Configuration
10-19
10-20
An Actual Configuration
12. Click Close to close the Define Tag Sources dialog box.
Wonderware Training

13. Select your tag source from the Tag Source drop down box.
The Attribute Browser dialog box opens.

14. Select XYLIT and PV from the attribute list. Make sure the Property is <none>.
Note: The Show all attributes box must be checked.
Click OK.
15. Confirm the String Expression is correct and click OK.
10-21
10-22
16. Click OK on the Properties configuration dialog box.
17. Click on Runtime to verify the value.
18. Repeat these steps for the remaining links assigning the Attribute Property to the respective
link.
Or
Click on the background of the Properties window to activate the window.
Press F2 to select all items on the window.
Wonderware Training

Configure the remaining attributes as follows:
obj1.PV.#QString
as
XYLIT.PV.#QString
obj1.PV.#ReadSts
as
XYLIT.PV.#ReadSts
obj1.PV.#VString
as
XYLIT.PV.#VString
obj1.PV.#VString1
as
XYLIT.PV.#VString1
obj1.PV.#VString2
as
XYLIT.PV.#VString2
obj1.PV.#VString3
as
XYLIT.PV.#VString3
obj1.PV.#VString4
as
XYLIT.PV.#VString4
obj1.PV.#WriteSts
as
XYLIT.PV.#WriteSts
obj1.PV.#Locked
as
XYLIT.PV.#Locked
Select Special / Substitute Tags from the menu bar.
10-23
10-24
Click the Replace button and replace obj1 with XYLIT.
Click OK.
Wonderware Training
Click OK.
19. Click on Runtime to verify the values.
10-25
10-26
Wonderware Training

Configure Data Connection between the InTouch Application and Industrial
Application Server
20. Go to Development.
Open the Security Window within the Application.
Note: If you see ?Config for any of the live data connections in WindowViewer, you will
need to perform all the tasks in this section of this lab. This indicates that your InTouch
Application is not yet configured to communicate with your Galaxy in Application Server.
10-27
10-28
21. Click on the background of the Security window to activate the window.
Press F2 to select all items on the window.
22. Select Special / Substitute Tags from the menu bar.
23. Click Replace.

You want to replace it with references to your galaxy.
Wonderware Training

24. Enter the Old Text for SecurityTest.
Enter the New Text for the SecurityTest. Remember that XY stands for your initials.
Click OK in the Replace Text dialog.
Click OK in the Substitute Tagnames dialog.
25. Verify that ArchestrA security is selected from the main menu.
Special / Security / Select Security Type / ArchestrA.
10-29
10-30
26. Click Runtime to test your configuration.
You should see the correct Object Name and Security Group.
Test Security in InTouch

27. Do not log on with any user name at this point.
Attempt to change Att1_FreeAccess and Att2_Operate from 0 to 1 (or vice versa).
You should be able to change Att1_FreeAccess, but not Att2_Operate based on the security
you configured.
Wonderware Training

28. Click Log On.
Logon as operator.
Click OK.
29. Attempt to change all the Attribute values.

Note the behavior of each Attribute and whether or not it will change or require a password.
30. Click Logon.

Logon as Administrator.
31. Attempt to change all the Attribute values.

Note the behavior of each Attribute and whether or not it will change or require a password.
Note: You will receive challenge boxes identical to those you saw earlier.
You will not be able to change Configure while the object is OnScan.
You will not be able to change the Read Only attribute.
10-31
10-32
Note the outcome of your testing.
Wonderware Training

Introduction
This lab will illustrate how to connect InTouchs Alarm ActiveX controls to the Galaxy.
Objectives
z
Set up Galaxy connectivity in InTouch for viewing and acknowledging Alarms and Events.
10-33
10-34
Tasks
Configure the Alarm ActiveX Controls in InTouch
1. In InTouch WindowMaker, open the Alarm Test window of the Instructor provided
application.
2. Double-click the Alarm Summary (AlarmViewCtrl) control to open the Properties dialog box
for this object.
Wonderware Training

3. Click the Query tab.
4. Enter \Galaxy!<Area> in the Alarm Query field where Galaxy is a fixed key word and Area is
the area from which you wish to view alarms.
Click OK to continue.
10-35
10-36
5. Double-click the Alarm History (AlmDbViewCtrl) control to open the Properties dialog box
for this object.
6. Click the Database tab and configure the Server Name as local.
Check the Auto Connect box.
Depending on your
configuration, your
instructor may need to
provide you with a
password.
Wonderware Training

7. Click the Test Connection button to verify connectivity to the database.
8. Click the General tab and for the Display Mode select Alarm History.
9. Click OK to close the AlmDbViewCtrl3 Properties dialog box.

10. Go into Runtime and monitor the alarms. Right-click in the upper control and acknowledge
alarms.
10-37
10-38
Wonderware Training

Introduction
The client abstraction layer used by InTouch to communicate with the Galaxy exposes several
object property dot fields that can be used to build animation links. The Object.Property.Value will
map to a data type in InTouch as described in the mapping table in this section (e.g. an object
Boolean will map to an InTouch discrete). The Object.Property.#VString will map to a message
that represents not only the object value but diagnostic information also. The
Object.Property.#EnumOrdinal will map to an InTouch Integer that represents one of many
states the property can assume. In this lab you will use some of the property dot fields to build
animation links against the App Server objects.
In this lab, we will build a visualization of our Tank System in InTouch and configure it to link to our
Tank System in ArchestrA.
Objectives
z
Set up properties in InTouch and configure them to link to our ArchestrA application.
Create a SmartSymbol from the Tank System created in InTouch.
10-39
10-40
Tasks
Configure InletValve Properties
1. In WindowMaker, create a new window.
2. Name the new window Tank.
3. Draw a Valve
Wonderware Training

4. Double-click on the Valve and select a Fill Color Analog link.
10-41
10-42
5. For the Expression, enter Galaxy:XYTankSystem_001.XYInletValve.PV.#EnumOrdinal
where InletValve is the name of your InletValve object in TankSystem_001 and click OK.
Or
Double click in the Expression area and select
XYTankSystem_001.XYInletValve.PV.#EnumOrdinal.
Note: You want to use the Hierarchical name instead of the Tagname so make sure you have
clicked on the Hierarchical filter button before you select.
Closed
color
(red)
Open
color
(green)
6. Test the Valve in Runtime.
Wonderware Training
Traveling
color
(yellow)

7. Insert a button on the application window and substitute the string to label it as OPEN.
8. Configure the OPEN button for the InletValve with a Touch Pushbutton action script as
follows:
Action Script:
Galaxy:XYTankSystem_001.XYInletValve.Cmd.#EnumOrdinal = 2;
10-43
10-44
Wonderware Training
9. Configure the OPEN button for the InletValve with a Visibility link as follows:
Visibility Link:
Galaxy:XYTankSystem_001.XYInletValve.PV.#EnumOrdinal == 1
Visible State : On
10-45
10-46
10. Insert another button on the application window and substitute the string to label it as CLOSE.
11. Configure the CLOSE button for the InletValve with a Touch Pushbutton action script as
follows:
Action Script:
Galaxy:XYTankSystem_001.XYInletValve.Cmd.#EnumOrdinal = 1;
Wonderware Training
12. Configure the CLOSE button for the InletValve with a Visibility link as follows:
Visibility Link:
Galaxy:XYTankSystem_001.XYInletValve.PV.#EnumOrdinal == 2
Visible State : On
10-47
10-48
13. Insert another button on the application window and substitute the string to label it as
TRAVELING. This button will not require any configuration.
14. Test the application in Runtime.
15. Place the buttons on top of one another so that the TRAVELING button is on the bottom.
16. Test the application again in Runtime verifying the proper buttons are displayed during the
appropriate operation.
Wonderware Training

Create Outlet Valve
17. Select all of the Valve and the Buttons, right-click and select Edit/Duplicate from the Menu
to duplicate the cell.
Or
Right-click and select Duplicate.
10-49
10-50
18. With the duplicate valve and buttons still selected, right-click and select Substitute Tags.
19. Substitute InletValve for OutletValve and click OK.
20. Click OK.
21. Test in Runtime.
Wonderware Training
Create the LevelMeter

22. Draw a LevelMeter and configure it as follows:
Percent Fill/Vertical:
Galaxy:XYTankSystem_001.XYLIT.PV
23. Insert a text display and configure it as follows:

Text (#, Arial Regular 14):
String Value Display:
Galaxy:DLTankSystem_001.DLLIT.PV.#VString2
10-51
10-52
Create the Pump

25. Draw a Pump and configure it as follows:
Fill Color/Analog Expression:
Galaxy:XYTankSystem_001.XYTransferPump.PV.#EnumOrdinal
Wonderware Training

26. Insert a button on the application window and substitute the string to label it as ON.
27. Configure the ON button for the TransferPump with a Touch Pushbutton action script as
follows:
Action Script:
Galaxy:XYTankSystem_001.XYTransferPump.Cmd.#EnumOrdinal = 2;
10-53
10-54
28. Configure the ON button for the TransferPump with a Visibility link as follows:
Visibility Link:
Galaxy:XYTankSystem_001.XYTransferPump.PV.#EnumOrdinal == 1
Visible State : On
Wonderware Training
29. Insert another button on the application window and substitute the string to label it as OFF.
30. Configure the OFF button for the TransferPump with a Touch Pushbutton action script as
follows:
Action Script:
Galaxy:XYTankSystem_001.XYTransferPump.Cmd.#EnumOrdinal = 1;
10-55
10-56
31. Configure the OFF button for the TransferPump with a Visibility link as follows:
Visibility Link:
Galaxy:XYTankSystem_001.XYTransferPump.PV.#EnumOrdinal == 2
Visible State : On
Wonderware Training
32. Identify the Tank System as follows:

Text (#, Arial Bold 14):
String Value Display:
Galaxy:DLTankSystem_001.DLLIT.PV.#VString
10-57
10-58
Generate Smart Symbol
34. Select the entire Tank System, right-click and select CellSymbol/Make Cell.
35. Before we generate a SmartSymbol, we want to replace the Instance references with the
Template references.
Right-click on the Tank System cell and select Substitute/Substitute Tags.
Wonderware Training

36. Click Replace.
37. Replace XYTankSystem_001 with $XYTankSystem.
38. Click OK.
10-59
10-60
39. Right-click on the cell and select SmartSymbol/Generate SmartSymbol.
40. At the InTouch SmartSymbol - Management Mode dialog box highlight the NewSymbol and
clock Close.
You will be prompted to convert the current object to the new SmartSymbol.
Wonderware Training
41. Click OK.

42. Double-click on the SmartSymbol to open the SmartSymbols Properties dialog box where
you can view the properties associated with your New Symbol. Notice in particular the
Template References on the lower right portion of the dialog box.
Click on the ellipses
for ArchestrA Instance to activate the Object Browser dialog box
and link it to an instance from your Galaxy.
You will get a prompt to configure a Galaxy for browsing.

Click OK.
10-61
10-62
43. Enter the name of your GR Node Name and the Galaxy Name and click OK.
44. Select XYTankSystem_001 and click OK.
Wonderware Training

Notice the references in the Instance References column have changed.
45. Click OK.
10-63
10-64
Add and Configure an Additional Smart Symbol
47. Click on the SmartSymbol Wizard to add another SmartSymbol.
48. Click on your application window.

The InTouch SmartSymbol - Select Mode dialog box opens.
Highlight your SmartSymbol and click OK.
Wonderware Training
49. Click on the ellipses

for ArchestrA Instance to activate the Object Browser dialog box
and link it to an instance from your Galaxy.
50. Select XYTankSystem_000 or any other tank system that you might have in your Galaxy and
click OK.
10-65
10-66
Notice the references in the Instance References column have changed.
51. Click OK.
Wonderware Training

Introduction
In AppServer, we can use a Device Integration Object to connect to InTouch, browse the
Tagname Dictionary and import those tags into our object in the IDE. This can provide faster
connectivity. In this lab we will configure an InTouchProxy Device Integration object to connect
to InTouch, browse the Tagname Dictionary and select a certain one to connect to through the
IDE. We will then use the Object Viewer to verify connectivity.
Objectives
z
Configure the InTouchProxy object to select tagnames from the InTouch Tagname
Dictionary.
Configure the AnalogDevice to connect to the InTouchProxy object.
10-67
10-68
Tasks
Configure the IT1 Object
1. Check with your instructor as to the location of the application.
Note: It is recommended that there be ONE computer running the Reactor Demo (either on
the Instructor computer or one of the Students computers) and share the app folder as
ReactorDemo.
2. In the IDE, create an instance of the InTouchProxy Device Integration object.
3. Rename the object IT1.
Wonderware Training

4. In the Model View, assign it to your System area.
5. In the Deployment View, assign it to your AppEngine.
6. Double-click on the IT1 object to open its editor.
10-69
10-70
7. On the General tab, for InTouch runtime node enter the node name where the InTouch
Application resides.
8. Click on the ellipses

correct application.
Wonderware Training
to activate the Browse For Folder dialog box to browse to the

9. Now you can locate the application and click OK.
The application is now inserted into the Item browse path field.
10. Select the Items Configuration tab.
10-71
10-72
11. Click on the
to add an attribute.
12. While being prompted to enter the attribute name in the left most portion of the form, click on
the ellipses
in the right most portion of the form.
This will open the Tag Browser dialog box to allow selecting the tag(s) you desire to include
as attributes to the IT1 object.
Wonderware Training

13. We now want to select the following tags.
z
$Second
ReactLevel
ReactTemp
ProdLevel
With the first tag highlighted, scroll to the other tags and select them while holding down the
Control key. Then click OK.
The tags are now listed as available attributes in the Items Configuration tab of your IT1
object.
10-73
10-74
14. Save and Close the editor and Check In the object.
15. Right-click on the IT1 object and deploy it.
16. Create a new instance of an AnalogDevice object, rename it XYReactLevel and assign it to
Line1.
Double click on the object to open its editor.
17. Select the I/O tab and click on the ellipses
Wonderware Training
for the PV input source.

18. Select IT1 as the Tagname. Then select ReactLevel as the Attribute and click OK.
The I/O tab now has IT1.ReactLevel configured as the PV input source.
10-75
10-76
19. Save and Close the editor. Check in the object. Then Deploy it.
20. Right-click on your XYReactLevel object and select View in Object Viewer.
21. Right-click on PV and add it to the Watch List window. Verify the correct value.
Note: If the value displays as Bad, verify the connection status of the IT1 device object and
reconnect if necessary.
Wonderware Training
Module 11
Multi-Node Galaxies
Section 1 Redundancy and Redundant DI Objects
Lab 22 Redundancy
Section 2 Converting to a Multi User Galaxy
11-3
11-19
11-33
11-37
11-2

Module Objectives
z
Migrating to a network environment;
Using exporting and importing to take objects that were created on one node and migrate
them to a single node, and:
How to deploy and undeploy objects on a galaxy located on a different node.
Wonderware Training

Section Objective
z
This section will covers the concept of redundancy, how it can be configured and key
points to more effectively implement this feature.
Understand the concept and functionality of Redundant DI Objects
Redundant Configuration
Redundancy is important in processes that rely on continuous availability of information. There are
two basic types or topologies of redundant configuration:
z
Redundant Application Engines
Redundant DI Objects
Redundant Application Engines

The purpose of Application Engine Redundancy is to ensure continuous operation by providing an
engine that remains active in the event of a single system component failure. It operates on the
principal that with redundant engines, one engine is in an Active Role while the other is in a
Standby Role waiting to take control.
The hardware topology required for Redundant Application Engines functionality is simple: two
computers with two network interface cards (NIC) each. (Additional network cards could be used
for other purposes.)
To configure redundancy, open the Application Engine Object Editor and check "Enable
Redundancy" on the Redundant tab.
11-3
11-4
Wonderware Training

The Application Engine that is enabled is considered the Primary engine of the redundant pair;
when you enable this engine, an additional (Backup) engine is automatically created.
Since an engine is required to run under a platform, the platform objects that sponsor the Primary
and Backup application engines need to be configured to use the dedicated NIC. This NIC
provides a high speed inter-connection link or Redundant Message Channel between the
platforms. The Message Channel is vital to keep both engines synchronized with alarms, history,
and checkpoint items from the engine that is in the Active Role. Each engine also uses this
Message Channel to provide its health, along with status information, to the other.
The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of
Application engines determines which of these in the pair will take the Active Role. The first engine
deployed takes the Active role while the other one takes the Standby role. The engines maintain
their current roles until a failure occurs. (A failure might consist of computer hardware lost or failed,
or a network card failure.) If a failure occurs, the engine with the Standby role assumes the Active
role and the engine that was in the Active role is given the role of Standby - Not Ready. When the
cause of the failure has been remedied, this engine assumes the Standby - Ready role.
Terminology
Two sets of terms are critical to understanding the functions of redundant objects. These are
described below.
During Configuration
Primary object: The object intended as the main or central provider of the functionality in the
run-time. For AppEngines, it is the object you enable for redundancy. For data acquisition, it is
the DIObject you intend to use first as your data source in the run-time.
Backup object: The object that provides the functionality of the Primary object when it fails.
For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary
object has been enabled for redundancy. For data acquisition, it is the DIObject you do not
intend to use first as your data source in the run-time.
During Run-Time
Active object: The object that is currently executing desired functions. For AppEngines, it is
the object that is hosting and executing ApplicationObjects. For data acquisition, it is the object
that is providing field device data through the RedundantDIObject.
Standby object: The passive object; that is, it is waiting for a failure in the Active object's
condition or for a force-failover. For AppEngines, it is the object that monitors the status of the
Active AppEngine. For data acquisition, it is the object that is not providing field device data
through the RedundantDIObject.
The Primary/Backup and Active/Standby objects form a redundancy pair. For AppEngine pairs,
only the Primary and its hierarchy of assigned ApplicationObjects must be created, configured and
deployed. The Backup is handled completely by the ArchestrA infrastructure (for instance, it is
deployed separately from the Primary). For data acquisition, the Primary/Backup DIObjects (the
data sources) must be separately created, configured and deployed. Also, you must create,
configure and deploy a RedundantDIObject to control failovers between the two data source
objects.
11-5
11-6

In the AppEngine redundancy environment, the Active and Standby objects monitor each other's
status and switch when failure conditions occur. In the data acquisition environment, the
RedundantDIObject monitors the status of the two DIObject data sources, and handles the
switching from Active to Standby objects.
The relationship between the configuration time (Primary/Backup) and run-time (Active/Standby)
object pairs is not static. In the run-time, either the Primary or Backup object can be the Active
object at any particular time. Whenever one becomes the Active object, the other automatically
becomes the Standby.
Configuration values for Primary and Backup also can be changed after deployment of the objects.
Note: In the case of AppEngine redundancy, ArchestrA supports a one-to-one topology in which
the computers hosting the Primary and Backup object sets must be connected by crossover cable
and have fixed IP addresses.
Key Points
a. Before placing an engine with redundancy enabled under a platform in the Deployment view,
configure the platform Redundant Message Channel; otherwise the engine will show an error.
b. In the Application Views panes of the IDE, only in the Deployment view will the Backup engine
be visible.
c. The Backup Engine cannot be edited.
d. After editing an engine with redundancy enabled while it is deployed, when it is redeployed the
engine which has the Active role will perform this function. It will then update the engine that is
in the Standby role.
e. A Backup engine's deployment status can be different from that of the Primary Engine, but
operations such as renaming, importing and exporting, GRdump and GR load that are
performed on the Primary Engine are automatically performed on the Backup. These
operations cannot be performed on the Backup Engine alone.
f.
Platforms hosting primary and backup AppEngines should have identical configuration. For
instance, it is possible to configure the platform with the Primary to be the InTouch Alarm
provider and filter the areas you want to query in the Platform editor. For the Alarm
Management system to behave correctly, this same configuration should be implemented in
the platform with the Backup. It is recommended that you make the following parameters
common to both platforms:
z
IT Alarm provider-Areas
Store Forward directories
Common user-defined attributes (UDAs)
Common scripting.
Role Determination
The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of
Application engines determines which of these in the pair will take the Active Role. The first engine
deployed takes the Active role while the other one takes the Standby role. The engines maintain
Wonderware Training

their current roles until a failure occurs. If either engine is deployed by itself, it assumes the Active
Engine role.
If a failure occurs (computer hardware lost or failed, or a network card failure), the engine with the
Standby role assumes the Active role and the engine that was in the Active role is given the role of
Standby - Not Ready. When the cause of the failure has been remedied, this engine assumes the
Standby - Ready role.
If you edit an engine with redundancy enabled while it is deployed, when it is redeployed the
engine which has the Active role will perform this function. It will then update the engine that is in
the Standby role.
Dedicated and Shared Loads

There are two types of redundant engine configuration: Dedicated and Shared load.
Note: Depending on the order of deployment, the Primary or Backup engine may take the role of
Active Engine. If either engine is deployed by itself, it assumes the Active Engine role.
In a Dedicated redundant configuration, if the Active Engine fails or is shut down, or if a
communication failure occurs, the engine in the Standby Ready role assumes the Active role. In
this scenario, the platform with the engine in the Standby Ready role is essentially idling. See the
following illustration.
11-7
11-8
Visualization Nodes
Supervisory Network
AutomationObject Server
Redundancy Message Channel

AE_1
(Active)
Primary
Backup
AE_1
(Standby)
Platform 2
Platform 1
Control Network
In a Shared redundant configuration, two or more Redundant Engines reside on each of two
platforms. Each platform hosts a Primary and a Backup engine. See the illustration below. This
scenario operates similarly to the Dedicated configuration, but allows the application load to be
shared on two computers until a failure occurs. When a failure occurs, one platform hosts the load
of both application engines. The benefits of using this approach is that the time of failover is
shortened and that only part of an application process is affected during a failure.
Note: It is important to understand both the CPU and memory load requirements of each engine.
Each computer must be capable of supporting these needs when a failure occurs; otherwise,
throughput for the application can be compromised
Wonderware Training
Visualization Nodes
Supervisory Network
Redundancy Message Channel
Primary
AE2
AE1 Bck
Platform 1
Backup
Backup
AE1
Bck AE2
Primary
Platform 2
Control Network
What Happens in Run-time

During initial deployment to its assigned WinPlatform, first code modules and other files for the
Primary AppEngine are deployed, followed by those files for its assigned ApplicationObjects. All of
these files are then deployed to the Standby AppEngine by the Active engines WinPlatform using
the redundancy message channel (RMC).
Note: If some or all of these files already exist on the Standby AppEngines WinPlatform (perhaps,
assigned to another AppEngine on that platform), only the delta files are deployed to the Standby
AppEngine.
11-9
11-10

AutomationObjects are always assigned to the Primary AppEngine in the configuration
environment. But in the run-time, AutomationObjects are always deployed to the Active
AppEngine whether or not it was initially configured as the Primary object. All files are then
deployed by the Active AppEngines WinPlatform to the Backup AppEngine as described above.
In the run-time environment, the Active and Standby AppEngines first attempt to establish
communications across the RMC. This occurs when an AppEngine belonging to a redundant pair
first starts up. Therefore, if one AppEngine is relocated later to a different WinPlatform, this
communication between AppEngines can be reestablished.
During run-time, the Active and Standby engines communicate with each other and monitor each
other's status.
In the case of a hardware or software failure on one computer, the Standby AppEngine will
become the Active one. Then, if you want to move the new Standby AppEngine from its hosting
computer, undeploy this AppEngine by using the On failure mark as undeployed option on the
Undeploy dialog box, and then reassign and redeploy it to a WinPlatform that is configured for
redundancy on another computer.
AppEngine Redundancy States

Redundant pairs of AppEngines can have one of the following states at a time:
z
Active: The state of an AppEngine when it has communication with its partner object, its
partner is in Standby-Not Ready, Standby-Syncing with Active, or Standby-Ready state. A
Standby AppEngine transitions into this state when a failover condition has been detected.
In this state, an AppEngine schedules and executes deployed objects, sends checkpoint
data and sends subscriber list updates to the Standby AppEngine.
Active - Standby not Available: The state of an Active AppEngine when it determines it
cannot achieve communications with its partner object. This could mean that checkpoint,
subscription and alarm state changes have not been successfully transmitted to the
Standby object, a heartbeat ping has not been received from the Standby object, or
notification is received that the Standby AppEngine has shutdown or is not running. If an
AppEngine is in this state, it 1) continues normal execution of hosted objects, 2) cannot be
manually switched to Standby state, and 3) while continuing to attempt communicate with
the Standby, does not attempt to send data to the Standby object.
Determining Failover Status: The initial state of a redundancy-enabled AppEngine when

it is first started. It has not determined yet whether it is the Active or Standby AppEngine.
Communication between the two AppEngines is attempted first over the RMC and then
over the primary network to make this determination. If communication cannot be made
after a certain timeout period, an AppEngine assumes the Active role if it has all of the
code modules and checkpoint file data to do so. Continued attempts are made at
communicating with its partner.
Standby - Missed Heartbeats: The state of an AppEngine when 1) a heartbeat ping has
not been received from its Active partner within a configured timeout period, 2) the Active
AppEngine fails or hangs up, or 3) the Active AppEngine is shutdown on purpose. When in
this state, the Standby object attempts to determine whether or not the Active object has
failed. If a manual failover is initiated (by using the ForceFailoverCmd attribute), it will be
processed only if the heartbeats were missed over the primary network and not missed
over the RMC.
Standby - Not Ready: The state of an AppEngine when one of several conditions occurs:
1) its has lost communications with its partner object or it maintains communications with
its partner but has missed checkpoint updates or alarm state changes from the Active
Wonderware Training

AppEngine, 2) new objects are deployed to the Active AppEngine and necessary files
have not been installed on the Standby AppEngine yet, or 3) the Standby AppEngine has
lost communications over the RMC before it could complete synchronizing data. Typically,
the AppEngines partner is in one of the following states: Active-Standby not Available,
Active, or Standby- Missed Heartbeats.
z
Standby - Ready: The state of an AppEngine when is has completed synchronizing code
modules and checkpoint data with the Active AppEngine. In this state, the AppEngine
monitors for Active AppEngine failure by verifying heartbeat pings received from the
Active engine, checks that all files required for execution are in sync with the Active
engine, and receives the following from the Active AppEngine: checkpoint change data,
subscription-related notifications, alarm state changes, and history blocks.
Standby - Sync'ng with Active: The state of an AppEngine when it is synchronizing code
modules with the Active object. If code modules exist on the Standby computer that do not
exist on the Active node, they are uninstalled, and likewise, any code modules that exist
on the Active node but not on the Standby node are installed. Once all code modules are
synchronized, the AppEngine transitions to Standby-Syncd Code state.
Standby - Sync'd Code: The state of a Standby AppEngine that has successfully
synchronized all code modules with the Active object.
Standby - Sync'd Data: The state of a Standby AppEngine when all object-related data,
including checkpoint and subscriber information, are synchronized with the Active object.
An object in this state typically transitions to Standby-Ready state.
Switching to Active: A temporary, transitional state when a Standby AppEngine is

commanded to become Active.
Switching to Standby: A temporary, transitional state when an Active AppEngine is

commanded to become Standby.
Unknown: The state of a redundant partner when a communication loss occurs between
AppEngines or when the partner AppEngine is not running.
Alarm Generation
When failover conditions occur, the ArchestrA system reports alarms to the Logger. These alarms
contain the following information:
z
The name of the AppEngine reporting the alarm.
The node name of the AppEngine reporting the alarm.
The state of the AppEngine.
The node name of the AppEngines partner object.
Note: Depending on the scenario that causes a failover, the Standby AppEngine may become the
Active in an offscan state and alarms may not be generated. If the Active AppEngine is shutdown
offscan, the checkpointer may transfer that state to the Standby, and when the latter becomes the
Active, it will startup offscan. When the AppEngine is put onscan, alarms then are generated.
Alarms reported are the following:
11-11
11-12
Previous
State
Current
State
Alarm Raised
When
Alarm Cleared When
Alarm
Reported
By
Standby - Not
Ready 1
Active
Standby - Not
Ready
Standby - Not
Ready
Entering Standby Ready
ACtive
Engine
Standby - Not
Available
Active
Active Standby Not

Available
Active - Standby Not

Available
Entering Active
Active
Engine
Standby Becomes
Active
During the next scan

of the Active Engine
Active
Engine
Alarm
Failover
Occurred
Legend:
1
The Active AppEngine monitors the status of the Standby through the RMC to determine
when to raise this alarm. Also, if the Active AppEngine is in Active-Standby not Available state,
this alarm is not generated.
When a failover occurs, the Standby AppEngine that becomes active will not report alarms
outstanding from the old Active AppEngine. The state of those old alarms, though, is reflected on
the new Active AppEngine as follows:
z
Out of alarm
Unacknowledged
Unacknowledged-Return to normal
Acknowledged-Return to normal
Acknowledged
Timestamps are also preserved for alarms, including when:

z
The alarm was acknowledged
The alarm condition went true
The alarm condition went false
Finally, the following information is preserved for alarms:

z
An alarm was acknowledged
The message input by the operator when the alarm was acknowledged
Note: All alarm state information is collected and sent to the Standby AppEngine at the end of a
scan cycle and before being sent to alarm clients. Any alarms that occur between scan cycles,
therefore, may not be reported to the Standby object if the Active object fails. The sequence of
reporting alarms ensures that alarm clients do not report alarms in states that are different from
those reported by the Standby AppEngine if the Active one fails.
History Generation
All active objects (AppEngine and hosted objects) report history data as they normally do in the
run-time environment.
Historical data is reported to the historian only from the Active AppEngine.
Loss of connectivity with the historian does not cause a failover. The Active AppEngine then goes
into store-forward mode and caches data every 30 seconds. Store-forward data (when the
historian is unavailable) is synchronized with the Standby AppEngine.
Wonderware Training

When failover conditions occur, no more than 30 seconds of history data should be lost in the
transition from Standby to Active status. This is done through a combination of store-forward
operations when the historian is unavailable and normal reporting operations when it is available.
Forced Failover
Failover can be forced to occur. Do this through the ForceFailoverCmd attribute of the AppEngine.
For instance, you can link multiple conditions in a script or use the Object Viewer utility to trigger a
forced failover.
Deployment
Primary and Backup AppEngines can be deployed together or individually. When they are
deployed together (no matter which object is actually selected for deployment), the Primary always
becomes the Active and the Backup becomes the Standby. When they are deployed individually,
the first one deployed becomes the Active.
Hosted ApplicationObjects are always deployed to the Active AppEngine. When deploying the first
of a redundant pair of AppEngines, you can cascade deploy all objects it hosts. This operation can
be paired with deploying both the Primary and Backup AppEngines at the same time.
Note: If you deploy the Backup AppEngine first and then deploy hosted objects to that
AppEngine, ensure that network communications to both target computers is good before
deploying the Primary AppEngine. Otherwise, errors may occur.
In the run-time environment, either the Primary or Backup AppEngine can become the Active or
Standby depending upon failure conditions on either computer.
Before deploying the Primary and Backup AppEngines, all configuration requirements must be
met. Each AppEngine must be assigned to a separate WinPlatform. A valid redundancy message
channel (RMC) must be configured for each WinPlatform. To deploy the Primary and Backup
together, select Include Redundant Partner in the Deploy dialog box. This option is not available
when doing the following operations:
z
Cascade deploy from the Galaxy
Multiple object selection deploy
Deployment of the WinPlatform that hosts the Primary or Backup AppEngine
11-13
11-14

See the following table for a matrix of allowed operations based on specific conditions.
Deploy Both Primary
and Backup Objects
Cascade Deploy
Allowed
Yes
Yes
Backup AppEngine in error state.
Yes
Yes
Backup AppEngine's host WinPlatform not deployed.
No
Yes
Backup AppEngine's host WinPlatform not configured for

failover and deployed.
Yes
Yes
Deploy from Galaxy node.
No
Yes
Condition
Backup AppEngine's host WinPlatform configured for
failover and deployed.
Deploy from WinPlatform hosting Primary AppEngine.
No
Yes
Multiple object selection deploy.
No
No
Backup AppEngine's host WinPlatform not configured for

failover and not deployed.
No
Yes
Deploy from Backup AppEngine.
Yes
Yes
Deploy from Primary AppEngine.
Yes
Yes
Undeploying redundancy pairs of AppEngines is similar to any regular object undeployment. The
Active and Backup AppEngines can be undeployed separately. Also, they can be undeployed as a
pair by selecting one of the objects in an Application View, selecting the Undeploy command, and
selecting Include Redundant Partner in the Undeploy dialog box.
Note: Undeployment of any AutomationObjects, including redundant AppEngine pairs, does not
uninstall code modules for that object from the hosting computer. Code modules are uninstalled
only when the WinPlatform is undeployed.
Wonderware Training

Errors and Warnings
Certain requirements (for instance, the order you configure an object pair for redundancy) are
validated by the system infrastructure. If a requirement is not met, you may see error messages
that describe the following:
z
You can configure an AppEngine for redundancy before its associated WinPlatform, but if
you do, you will get an error message that the Platform (specifically, the RMC) is not
configured yet.
If the RMC IP Address parameter is not configured in both hosting WinPlatforms, then the
configuration state of both Primary and Backup AppEngines changes to Error, with a
message indicating that the host WinPlatform is not configured with the network adapter
required for redundant communications. When the RMC IP Address is configured and the
WinPlatforms are checked in, the hosted AppEngines are automatically revalidated and
the Error state is resolved. If hosted AppEngines are checked out, they are not
revalidated.
If both Primary and Backup AppEngines are assigned to the same WinPlatform and an
attempt is made to deploy both engines, both the Primary and Backup will fail to deploy
with a message noting that the Primary and Backup objects must be hosted by different
WinPlatforms. Reassign the Backup object to another WinPlatform and deploy it
separately.
If both the Network Address and RMC IP Address parameters in the WinPlatform's
editor address the same network card, you will get a warning message when you save the
configuration. These two parameters must address different network cards.
Redundant DI Objects
Application Engines can host Redundant Device Integration Objects (DI Objects). The
RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike redundant
AppEngines, individual DIObject data sources do not have redundancy-related states. For all
intents and purposes, they function as standalone objects.
Only one DIObject data source provides field device data through the RedundantDIObject at a
time. Both data sources must have commonly configured DAGroups which are reflected in and
channeled through the RedundantDIObject, which monitors the two DIObject data sources and
determines which one is Active at any given time. Both data sources must also have the same
item address space.
The Redundant DI Object is a DINetwork Object used to enable continuity of I/O information from
field devices. The Redundant DI Object provides the ability to configure a single object with
connections to two different data sources. If the primary data source fails, the Redundant DI
Object automatically switches to the backup data source for its information. There is a one-to-two
relationship between an instance of the Redundant DI Object and the running instances of the
source DI objects; that is, for each Redundant DI Object, a pair of source DI Objects is deployed.
11-15
11-16

:RUNVWDWLRQV
5HGXQGDQW
',2EMHFW
6XSHUYLVRU\1HWZRUN
',B
$(
3ODWIRUP
$SSOLFDWLRQ6HUYHU
',B
'$6HUYHUB
'$6HUYHUB
$%7&3
'+
&RQWURO1HWZRUN
3/&
Configuration RedundantDIObjects
Configure redundancy in data acquisition objects in the IDE through their editors. Data acquisition
redundancy objects (two DIObjects and the RedundantDIObject) do not have redundancy-related
deployment statuses.
In data acquisition redundancy, you must configure all three components: a Primary DIObject data
source, a Backup one, and a Redundant DIObject.
Because data acquisition redundant components are essentially standalone objects, all valid
operations that apply to any other ApplicationObjects apply to the three objects. All IDE
commands, Galaxy Dump and Load functions, and import and export operations are valid on the
two DIObject data sources and the RedundantDIObject.
The main focus of RedundantDIObject configuration is:
z
Setting the Primary DI Source and Backup DI Source on the General tab of the objects
editor.
Setting up the common scan groups, and block read and block write groups on the
respective tabs of the objects editor.
Wonderware Training
Note: You must configure at least one scan group before you can deploy the RedundantDIObject.
Also, only scan, block read, and block write groups shared by the Primary and Backup DIObjects
should be configured in the RedundantDIObject.
Deployment
Deployment for data acquisition redundancy is the same as individually deploying unrelated
objects. No special conditions apply to each DIObject data source and the RedundantDIObject.
What Happens in Run-time

The three objects in the data acquisition redundancy scheme (RedundantDIObject and its two
DIObject data sources) function like any other ArchestrA object with respect to deployment,
alarming and historization. They have no special redundancy-related states or restrictions with
respect to deployment, undeployment and redeployment.
During run-time, the RedundantDIObject monitors the status of the DIObject data sources, and
handles the switching from Active to Standby object when failure conditions arise.
11-17
11-18
Wonderware Training
Lab 22 Redundancy
Lab 22 Redundancy
Introduction
This lab will describe the steps necessary to configure redundancy between two nodes. It explains
the necessary hardware requirements and configuration as well as the required IDE configuration.
Note: Because of the additional hardware and network requirements necessary it is

recommended that this lab be done as an Instructor Demonstration only.
Objectives
z
Configure the required hardware installation
Configure network connections
Configure the Galaxy for redundancy
Test redundancy
11-19
11-20

Tasks
Dual NICs Configuration
Note: The steps are for Windows 2003 Server, similar configuration can be accomplish on other
Windows OS.
Hardware installation
1. Shutdown Windows and turn off both computers.
2. Install the second NIC cards on both computers.
3. Plug the network crossover cable on the second NIC on both computers.
4. Turn on both computers.
Configure the Network connections

Follow these steps on both computers.
5. Open the Control Panel and then double-click Network Connections.
Wonderware Training
Lab 22 Redundancy
6. Right-click Local Area Connection 1 and select Rename from the context menu. Rename
the connection ArchestrA. (For identification purposes)
11-21
11-22

7. Right-click Local Area Connection 2 and select Rename from the context menu. Rename
the connection RMC. (For identification purposes)
8. Select the menu option Advanced/Advanced Settings. The Advanced Settings dialog box
will pop-up.
9. At the Advanced Settings dialog box, on the Adapters and Bindings tab configure (or
verify) the Connections section in the following order:
ArchestrA
RMC
(Remote Access connections)
Wonderware Training
Lab 22 Redundancy
10. Click the OK button to close the dialog box.
11. Right-click ArchestrA and select Properties. The ArchestrA Properties dialog box will popup.
12. In the This connection uses the following items section (or Components checked are
used by this connection section - depending upon your operating system) select Internet
Protocol (TCP/IP) and click the Properties button. The Internet Protocol (TCP/IP)
Properties dialog box will pop-up.
11-23
11-24

13. On the General tab click the Advanced button. The Advanced TCP/IP Settings dialog box
will pop-up.
Wonderware Training
Lab 22 Redundancy
14. Select the DNS tab. Verify that the Register this connection's addresses in DNS checkbox
is checked.
15. Click OK to return to the Internet Protocol (TCP/IP) Properties dialog box.
11-25
11-26

16. Click the OK button twice to close all dialog boxes.
17. Right-click RMC and select Properties. The RMC Properties dialog box will pop-up.
18. In the This connection uses the following items section select Internet Protocol (TCP/IP)
and click the Properties button. The Internet Protocol (TCP/IP) Properties dialog box will
pop-up.
Wonderware Training
Lab 22 Redundancy
19. Select the Use the following IP address option and configure the IP with a mask that is
different that the ArchestrA network connection. For example:
20. Click the OK button to close all dialog boxes.
11-27
11-28

Configure the Galaxy for Redundancy
21. If it is not already open, open the ArchestrA IDE, connect to the galaxy and Undeploy the
Galaxy.
The following steps assume that the instance names are as follows. Adjust accordingly:
XYPlatform1:
$WinPlatform instance configure for NODE 1.
XYPlatform2:
$WinPlatform instance configure for NODE 2.
XYAppEngine:
$AppEngine instance hosted by XYPlatform1 in the Deployment View.
Wonderware Training
Lab 22 Redundancy
22. Double-click XYPlatform1 to open the $WinPlatform editor.
On the General tab configure the Redundancy section with the IP address of the RMC
network connection for NODE 1 as follows:
Redundancy message channel IP address:
192 . 168 . 0 . 1
Redundancy message channel port:
<default_value>
Redundancy primary channel port:
<default_value>
23. Save and close the editor. At the Check In dialog, enter RMC configuration in the Comment
field. Click OK.
24. Double-click XYPlatform2 to open the $WinPlatform editor.

On the General tab configure the Redundancy section with the IP address of the RMC
network connection for NODE 2 as follows:
Redundancy message channel IP address:
192.168.0.2
Redundancy message channel port:
<default_value>
Redundancy primary channel port:
<default_value>
11-29
11-30
25. Save and close the editor. At the Check In dialog, enter RMC configuration in the Comment
field. Click OK.
26. Assign XYAppEngine to XYPlatform2.
Wonderware Training
Lab 22 Redundancy
27. Double-click XYAppEngine to open the $AppEngine editor.
Select the Redundancy tab and check the Enable redundancy checkbox.
28. Save and close the editor. At the Check In dialog, enter Redundancy configuration in the
Comment field. Click OK.
29. Assign XYAppEngine (Backup) to XYPlatform1.
11-31
11-32
30. Deploy the Galaxy.
Test Redundancy
31. View XYAppEngine in the Object Viewer and add the following attributes to the Watch
Window:
z
XYAppEngine.Host
XYAppEngine.Redundancy.FailoverOcurred
XYAppEngine.Redundancy.ForceFailoverCmd
XYAppEngine.Redundancy.Identity
XYAppEngine.Redundancy.PartnerPlatform
XYAppEngine.Redundancy.PartnerStatus
XYAppEngine.Redundancy.Status
32. Add "live" attributes for any of the Application Objects hosted by XYAppEngine to the Watch
Window.
33. Force failure of NODE 2 by unplugging the power cable, shutting down Windows or
disconnecting both network cables at the same time.
34. Check Object Viewer on NODE 1 to monitor the attributes and see the failover.
35. Restore NODE 2 and monitor the attributes on NODE 1 to see the behavior.
36. Use XYAppEngine.Redundancy.ForceFailoverCmd to force a failover.
37. Monitor the changes on the attributes in Object Viewer.
Wonderware Training

Section Objective
This section will deal with migrating from a standalone configuration to a network configuration.
At the conclusion of this section the student will have an understanding of the steps necessary to
migrate to a network environment.
Standalone to Network Configuration

Earlier we discussed the standalone configuration we have been using up to this point. At this
time we want to migrate over to a network configuration that will reflect four nodes accessing one
Galaxy Repository. This will allow us to utilize a networked configuration to convey more complex
concepts relating to connectivity, exporting objects and templates and other multi-node
environmental considerations.
Each of the nodes contains the Bootstrap, the IDE, and a Galaxy Repository. Once we have
reconfigured the environment there will be one machine (Node1) that will contain the Bootstrap,
the IDE, and a Galaxy Repository. Three other nodes will be connected to the Galaxy on Node1.
Those other three nodes will contain only the Bootstrap and the IDE.
In the networked architecture a common Galaxy Repository will be shared between a set of PCs
allowing multiple users to simultaneously work on the same application.
The existing standalone environment is illustrated as follows:
11-33
11-34
Hardware and Associated Software
Application
Server
Galaxy
Repository
InTouch
Station
Contains
Bootstrap
IDE
InTouch 9.0
Contains
Bootstrap
Contains
Bootstrap
InTouch 9.0
Present on
each machine
Standalone Configuration
PLC
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
The networked environment that we will migrate to is illustrated as follows:
Wonderware Training
Bootstrap
IDE
InTouch 9.0
PLC
Galaxy 1 Node4
G1N4
Galaxy 1 Node3
G1N3
Galaxy 1 Node2
G1N2
Galaxy 1 Node1
G1N1
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Industrial Application
Server and InTouch
Application Object Server ,

Galaxy Repository, and
InTouch
Multi User Conversion Considerations

When migrating from a Stand Alone environmental configuration to a networked configuration
there are some factors that must be taken into consideration. One of the key ones being that
certain functions take place on the Galaxy Repository node BEFORE they take place from the
connecting nodes.
There will be a need for only one PLC so the one residing on the resulting Galaxy Repository node
will be the one that is most likely the one desired for the network. Therefore, that is the on and
only one that will be exported in preparation for the network environment.
The node that will contain the Galaxy Repository must do several tasks before any other nodes
can connect. These include:
z
Create the Galaxy to which all other nodes will connect.
Create Platforms for other galaxy members.
Rename the node.
Name and deploy their own Platform as the first Platform deployed on the Galaxy
Repository node.
Failure to follow these key steps before others connect and start deploying objects can produce
less than desirable results.
11-35
11-36
Wonderware Training

Introduction
This lab will describe the steps necessary to convert to a Networked Configuration. In the
networked environment a common Galaxy Repository will be shared between a set of PCs
allowing multiple users to simultaneously work on the same application.
Objectives
z
Migrate to a network environment
Use exporting and importing to take objects that were created on one node and migrate
them to a single node
Understand how to deploy and undeploy objects on a galaxy located on a different node
Requirements
Galaxy with access to IDE and I/O Servers.
Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.
(e.g., if the user is John Burns, Valve would be JBValve) This will eliminate problems when we
deploy our objects in a common galaxy.
11-37
11-38

Tasks
Preparing to Convert to Networked Environment
Before we can convert to the networked configuration there are certain steps that must be initially
undertaken.
1. Your Instructor will assign a specific grouping of multi-user galaxies (Members) and assign
one student to host their galaxy (Galaxy Master).
2. On each node, export your TankSystem Template AND its children.
Wonderware Training
11-39
11-40

3. On the node that will contain the Galaxy Repository, THE GALAXY MASTER ONLY is to
export the InControl instance.
4. All nodes are then to Undeploy their respective Galaxies.
Wonderware Training

Converting to the Networked Environment
Note: The Node that will contain the Galaxy Repository (the Galaxy Master) is to do these initial
steps alone.
All other nodes are NOT to create any Galaxies at this time. It is imperative that the node that will
contain the Galaxy Repository be the FIRST node to create a Galaxy, create a Platform and
deploy that Platform.
STEPS 5 THROUGH 11 ARE FOR THE GALAXY MASTERS ONLY!

5. On the node that will contain the Galaxy Repository (the Galaxy Master), select File/Change
Galaxy to create and change to a new Galaxy.
11-41
11-42
6. Create a Galaxy called Galaxy1. This will ensure that for each network, Galaxy1 will be the
Galaxy that resides on the same node as the Galaxy Repository.
Wonderware Training

7. On the Galaxy1 node that will contain the Galaxy Repository create a Platform.
8. Deploy the Platform.
9. On the Galaxy1 node that will contain the Galaxy Repository, import the Tank Template and
the InControl object.
11-43
11-44

10. The Galaxy Master is to configure Security with Galaxy Authentication and user accounts for
each member of the team. Each user will belong to the Administrator role.
Wonderware Training
11. On the Galaxy1 node that will contain the Galaxy Repository, the Galaxy Master is to deploy
the Engine, Area and the InControl object.
11-45
11-46

AFTER THE GALAXY MASTER HAS COMPLETED STEPS 5 THROUGH 11,
ALL NON GALAXY MASTERS CONTINUE AT THIS POINT!
12. All the Non Galaxy Master nodes are now to login and connect to the Galaxy1 node
containing the Galaxy Repository using the Security login created by the Galaxy Master.
13. All the Non Galaxy Master nodes are to create a Platform.
z
Node 2 creates Platform2,
Node 3 creates Platform3,
Node 4 creates Platform4
14. All the Non Galaxy Master nodes are to create an Engine and an Area.
15. All the Galaxy nodes are to import their Tank.
16. All the Non Galaxy Master nodes are to do a Cascade Deploy to the Tank to their Platform.
17. Use the Object Viewer to verify that communication is occurring with the InControl object on
the Galaxy Repository.
Wonderware Training
Appendix A
ArchestrA Licensing
A-2
Appendix A ArchestrA Licensing
Licensing
The Industrial Application Server utilizes the FactorySuite A2 licensing. This appendix is designed
to provide information about where the detailed license requirements for a FactorySuite A2 system
reside.
Note: For additional deployment and pricing information, please see the Wonderware
FactorySuite A2 Deployment Guide and the Wonderware Global Price List which are available
from Wonderware Sales.
In addition to the Application Server, the following Wonderware products may also be present:
z
FactorySuite Development 8.0 or higher
InTouch View 9.0 SP2 or higher
InTouch 9.0 SP 2 or higher
InSQL Server 8.0 SP1 or higher
InTouch for Terminal Services 8.0 or higher
SuiteVoyager 2.0 or higher
ActiveFactory 8.0 or higher
and others.
Note that the use of the term License in this document refers to the legal rights a customer has to
use Wonderware Software.
There is also a local License Manager and associated .LIC file which is loaded with specific
Wonderware Software packages and monitors the use of that specific package. Please refer to the
appropriate product documentation to learn more about the Wonderware License Management
System.
The detailed licensing information is located on Team.Wonderware.com in the following location.
Wonderware Training

1. Open your browser and go to Team.Wonderware.com.
2. Select Product Info/Industrial Application Server.
A-3
A-4

3. Select Proposal Guides, Lockout Specs & Sales Tools.
4. Select Licensing Guide for the Industrial Application Server v2.0.
Wonderware Training

5. Select the Licensing Industrial Application Server file near the bottom of the screen.
A-5
A-6

6. At the File Download dialog box select either Open or Save depending upon your needs.
Wonderware Training
Appendix B
FactorySuite Support Tools
B-2
Appendix B FactorySuite Support Tools
Overview
This Appendix explains Wonderware Support programs, as well as detailed information
concerning registration, support, and the Expert Knowledge Base.
Note: The Web pages shown and described in the following materials are subject to change
without prior notice.
Wonderwares Website is located at: www.wonderware.com.
To access the Support page, click the Support link.
Wonderware Training

Next, select FactorySuite eSupport.
You may now either Login or Register.
Registration
To access the different areas and services available, you must first register yourself by selecting
the Register link on the main page. You must fill out all the requested items of information.
The new User will be prompted to enter basic registration information. Once the registration
information has been completed, the Technical Support Administrator will issue you a Userid and
Password. If you are already registered, click Login.
B-3
B-4

A Userid and Password are not required if you simply want to enter the Wonderware corporate
web site.
Levels of Access
When the Technical Support Administrator processes your registration, your Userid and Password
is based on one of the following levels of access: Basic Support, Comprehensive or Enterprise
customers, Wonderware Distributor, or Certified Support Provider.
System Integrators and OEM sites will be granted access if they have a valid Comprehensive
Support or Enterprise support contract.
The Password Verification dialog box appears:
Wonderware Training

Users, Providers, and Subscribers
Basic Support Users: Basic Support users who register on the Technical Support web page will
be able to access the following areas and services by selecting www.wonderware.com/support/
mmi/esupport.
On the Support page, under the Self Support tab, you will find a variety of information including
the Expert Knowledge Base, Documentation, FAQs, Tech Alerts, Tech Articles, Tech Notes, and
Tech Support Forums.
More Support links are contained within the Support page. The links are available according to
your access level status.
B-5
B-6

Comprehensive Support Subscribers and Enterprise Support Customers
Comprehensive Support subscribers and Enterprise Customers who register on the Technical
Support web page can access all of the Basic Support services and additional exclusive areas on
the web site.
At www.wonderware.com/support/mmi click Contact Us for phone numbers and E-mail addresses
for contacting Tech Support. For the latest contact information, please view the KBCD, issued
quarterly.
Enterprise Support: Wonderware Technical Support offers Enterprise Support for those
customers who have exhibited a high level of commitment to Wonderware products. It extends
beyond the full service Comprehensive Support services that are available.
Some of the advantages are:
z
A designated Enterprise Support Program account manager.
Account Manager site visits.
Bi-weekly status reports submitted to Enterprise customers.
Wonderware Distributor Support: Wonderware has over 150 distributors and sales offices
located throughout the world. Each is available to assist you with your needs.
To locate the nearest Wonderware distributor, go to: www.wonderware.com/Aboutus/Sales.
Solution Providers: Select the Solution Providers link from the Support page.
Information on this page includes innovative enhancements for WW products. These include
vertical market wizards, ActiveX objects, and I/O Servers.
Wonderware System Integrator: Select the Solution Providers/Wonderware SIs link from the
Support page.
From this page you can also locate a Wonderware Registered or Certified SI. Qualified System
Integrators and developers are accessed from this location. They have the technical ability to
assist you with your needs.
Certified Support Provider: Most of our worldwide Wonderware distributors are Wonderware
Certified Support Providers (CSPs). Our distributors provide valuable application and technical
support, as well as FactorySuite product training.
Wonderware CSPs undergo a rigorous certification process including passing lengthy written
examinations in each FactorySuite component. This ensures you receive a consistent, high-quality
level of support no matter where in the world you are located.
If you contact Wonderware Technical Support in Lake Forest, CA either by telephone or by e-mail,
the Technical Support Administrator will forward your call or e-mail to a Technical Support
engineer at the nearest Certified Support Provider site. (Callers from outside the U.S. and Canada
may be given the telephone number of the nearest Certified Support Provider).
Our Certified Support Providers are trained to answer even the most difficult questions that you
may have about the FactorySuite. For issues that require further research, our Certified Support
Providers may work with Wonderware Technical Support to ensure that you are given a complete
solution to your issue.
For further questions on our Certified Support Provider program, contact either your local
Wonderware distributor or Wonderware Technical Support in Lake Forest, CA.
At www.wonderware.com/support/mmi click Contact Us for all up-to-date phone numbers and Email addresses for contacting Tech Support.
Wonderware Training

Expert Knowledge Base
Navigate to this page by selecting the Expert Knowledge Base link on the Support page.
Information included on this page includes the 10 Most Frequently Asked Questions, expert
search capabilities and troubleshooting information for all of our products:
Team Wonderware
Support information is also located on: team.wonderware.com.
B-7
B-8
Intentionally left blank
Wonderware Training
Appendix C
Industrial Application Server Glossary
C-2
Appendix C Industrial Application Server Glossary

Application
A collection of objects within a Galaxy Repository that performs an automation task. Synonymous
with Galaxy. There may be one or more applications within a Galaxy Repository.
Application Engine (AppEngine)
A scan-based engine that hosts and executes the runtime logic contained within
AutomationObjects.
ApplicationObject
An AutomationObject that represents some element of your application. This may include things
such as (but not limited to) an automation process component (for instance, a thermocouple,
pump, motor, valve, reactor, or tank) or associated application component (for instance, function
block, PID loop, Sequential Function Chart, Ladder Logic program, batch phase, or SPC data
sheet).
Application Views
The Applications Views pane displays the object-related contents of the Galaxy in three different
ways: Model, Deployment, and Derivation Views. The Model View is the default display when the
IDE is first opened.
ArchestrA
The distributed architecture for supervisory control and manufacturing information systems. It is an
open and extensible technology based on a distributed, object-based design.
ArchestrA Object Toolkit
A programmers tool used to create new ApplicationObjects and Device Integration Object
Templates, including their configuration and run-time implementations. Includes a developer tool
used to build DI Objects and create unique Domain Objects that interact with DI Objects in the
ArchestrA environment.
Area
A logical grouping of AutomationObjects that represents an area or unit of a plant. It is used to
group related AutomationObjects for alarm, history, and security purposes. It is represented by an
Area AutomationObject.
Area Object
The System Object that represents an Area of your plant within a Galaxy. The Area Object acts as
an alarm concentrator, and is used to place other Automation Objects into proper context with
respect to the actual physical automation layout.
Assignment
The designation of a host for an AutomationObject. For example, an AppEngine AutomationObject
is assigned to a WinPlatform AutomationObject.
Attribute
An externally accessible data item of an AutomationObject.
Attribute Reference String
A text string that references an attribute of an AutomationObject.
AutomationObject
A type of object that represents permanent things in your plant (such as Application Objects or
Device Integration Objects) as objects with user-defined, unique names within the Galaxy. It
provides a standard way to create, name, download, execute, and monitor the represented
component.
Wonderware Training

Automation Object Server (AOS)
A computer that hosts one or more application engines and associated automation objects. An
Industrial Application Server Galaxy Namespace can contain several Automation Object Servers,
each which requires a Platform.
Backup Application Engine
The object created by the ArchestrA infrastructure when the Primary object has been enabled for
Redundancy. See Redundancy for further detail.
Base Template
A root template at the top of a derived hierarchy. Unlike other templates, a base template is not
derived from another template but developed with the Application Object Toolkit and imported into
a Galaxy. Base templates and derived templates always have a $ before their name in the IDE.
Block Read Group
A DAGroup that is triggered by the user or another object. It reads a block of data from the external
data source and indicates the completion status.
Block Write Group
A DAGroup that is triggered by the user or another object after all the required data items have
been set. The block of data is then sent to the external data device. When the block write is
complete, it indicates the completion status.
Bootstrap
The base ArchestrA service which is required on all ArchestrA computers. It provides the base
software environment to enable a platform and allows a computer to be included in the Galaxy
Namespace.
Change Log
The revision history that tracks the life cycle activities of ArchestrA Objects, such as object
creation, check-in/check-out, deployment, and import/export.
Change Propagation
The ability to create templates which will allow each component template to support changes such
that a change in one of the elements can be automatically propagated to all or select, related
instances.
Check-In
IDE operation for making a configured object available for other users to Check-Out and use.
Check-Out
IDE operation for the purpose of editing an object. It makes the item unavailable for other users to
Check-Out.
Checkpoint
The act of persisting to disk the configuration, state, and all associated data necessary to support
automatic restart of a running AutomationObject. The restarted object has the same configuration,
state, and associated data as the last checkpoint image on disk.
Compound Object.
An Application Object that contains at least one other Application Object.
Contained Name
An alternate naming convention that when combined with the tag name of the root container
object, results in the Hierarchical Name. For instance, for a given object, its Hierarchical Name =
Line1.Tank1.InletValve and its Contained Name= InletValve
Containment
The notion of hierarchical grouping that allows one or more AutomationObjects to exist within the
name space of a parent AutomationObject and be treated like parts of the parent
C-3
C-4

AutomationObject. This functionality allows for relative referencing to be defined at the template
and instance level.
DAGroup
A data access group associated with Device Integration Objects. It defines how communications is
achieved with external data sources. It can be a ScanGroup, Block Read or Block Write groups.
DAServer Manager (DAS Manager)
The System Management Console (SMC) snap-in supplied by the DAServer that provides the
required user interface for activation, configuration, and diagnosis of the DAServer.
Data Access Server (DAServer)
The server executable that handles all communications between field devices and client
applications. Similar in function to I/O Servers but with more advanced capabilities.
Data Access Server Toolkit (DAS Toolkit)
A developer tool used to build Data Access Servers (DAServers).
Deployment
The operation which instantiates an automation object instance in the ArchestrA runtime. This
action involves installing all the necessary software and instantiating the object on the target
platform with the objects default attribute data from Galaxy Repository.
Deployment View
The part of the Applications View in the IDE that shows how objects are physically dispersed
across Platforms, Areas and Engines. This is a view of how the application is spread across
computing resources.
Derivation
The creation of a new Template based on an existing Template.
Derivation View
The part of the Applications View in the IDE that shows the parent-child relationship between base
templates, derived templates and derived instances. A view into the genealogy of the application.
Derived Template
Any template with a parent template.
Device Integration Object (DIObjects)
An AutomationObject that represents the communication with external devices or software.
DIObjects run on an Application Engine, and include DINetwork and DIDevice objects.
DIDevice Object
An object that represents the actual external device (for example, a PLC or RTU) that is
associated with a DINetwork Object. It provides the ability to diagnose and browse data registers
of the DAGroups for that device.
DINetwork Object
An object that represents the network interface port to the device via the Data Access Server or
the object that represents the communications path to another software application. It provides
diagnostics and configuration for that specific network card.
Engine Object
An ArchestrA system enabled object that contains Local Message Exchange and provides a host
for Application objects, Device Integration objects and Area objects.
Event Record
The data that is transferred about the system and logged when a defined event changes state (for
instance, an analog crosses its high level limit, an acknowledgement is made, or an operator logs
in to the system).
Wonderware Training

Export
The act of generating a Package file (.aaPKG file extension) from persisted data in the Galaxy
Database. The resulting .aaPKG file can be imported into another Galaxy through the IDE import
mechanism.
FactorySuite Gateway is a Microsoft Windows application program that acts as a communications
protocol converter. Built with the ArchestrA DAS Toolkit, FS Gateway can be used to link clients
and data sources that communicate using different data access protocols.
Galaxy
The entire application. The complete ArchestrA system consisting of a single logical name space
(defined by the Galaxy Database) and a collection of Platforms, Engines and objects. One or more
networked PCs that constitute an automation system. This is referred to as the Galaxy
Namespace.
Galaxy Database
The relational database containing all persistent configuration information like Templates,
Instances, Security, etc. in a Galaxy Repository.
Galaxy Database Manager
The Galaxy Database Manager is a utility you can use to manage your Galaxies. It can back up
and restore Galaxies should they become corrupted or to reproduce a Galaxy on another
computer. The Galaxy Database Manager is part of the System Management Console (SMC).
GalaxyObject
The object that represents a Galaxy.
Galaxy Repository
The software sub-system consisting of one or more Galaxy Databases.
Hierarchical Name
The name of the object in the context of its container object. For instance, Tank1.OutletValve,
where an object called Tank1 contains the OutletValve object.
Historical Storage System (Historian)
The time series data storage system, used to compress and store high volumes of time series data
for latter retrieval. For the Industrial Application Server, the standard Historian is IndustrialSQL
Server.
Host
The parent instance of a child instance in the deployment view. (Example: a Platform instance is a
Host for an AppEngine instance).
Import
The act of reading a .aaPKG File and using it to create AutomationObject instances and
Templates in the Galaxy Repository.
Industrial Application Server
Refers to the FactorySuite A2 Supervisory Control Platform, commonly known as the Application
Server. The Industrial Application Server is sized by (a) the number of Workstation / Server
Platforms, (b) by real I/O in the system, and (c) the number of Terminal Services sessions. The
Application Server license is per Galaxy. An Application Server can be distributed across multiple
computers as part of a single Galaxy Namespace. The Industrial Application Server is designed to
leverage existing Wonderware products such as InTouch for visualization, Industrial SQL as its
historian, and the device Integration product line (I/O Servers) for device communications. The
Industrial Application Server uses InTouch v8.0 or InTouch View v8.0 for visualization with the
addition of Platforms to the visualization node.
C-5
C-6

Instance
An object, which is a unique representation of a template that can exist in runtime.
Instantiation
The creation of a new object instance based on a corresponding Template.
The Integrated Development Environment (IDE) is the user interface for the configuration side of
Application Server. It is used to manage templates, create object instances, deploy and un-deploy
objects and a host of other functions associated with the development and maintenance of the
system. It is only available as part of the FactorySuite A2 Development License.
InTouch View
InTouch View Clients are InTouch Runtime Version 8.0 clients that solely use of the Industrial
Application Server for its data source. In addition, standard InTouch v8.0 runtimes can leverage
the Industrial Application Server with the addition of a Platform license.
I/O Count
Number of I/O points being accessed into the Galaxy. I/O points are real I/O and are not equivalent
to InTouch tags. I/O count is based on the number of I/O points that are configured through an
OPC Server, I/O Server, DA Server or InTouch Proxy Object, over the whole Application Server
namespace, regardless of how many PCs are in the system.
Life Cycle Cost
The cost of a Supervisory Control System attributed to initial development, application changes
and on-going maintenance. The Industrial Application Server reduces these costs through the use
of a component object-based development environment and automated change propagation
capabilities.
Live Mode
An action in ActiveFactory that enables the configuration of a Runtime application to be
refreshed at a designated interval.
Log Viewer
A Microsoft Management Console (MMC) snap-in that provides a user interface for viewing
messages reported to the LogViewer.
Message Exchange
The object to object communications protocol used by ArchestrA and the Industrial Application
Server.
Model View
The part of the Applications View in the IDE that shows how objects are arranged to describe the
physical layout of the plant and supervisory process being controlled.
Object
Any template or instance found in a Galaxy Database. A common characteristic of all objects is
they are stored as separate components in the Galaxy Repository.
Object Extensions
The capability to add additional functions to an Automation Object while not altering the objects
original behavior. Can be added to derived templates and object instances. They include Scripts,
User Defined Attributes (UDAs) and Attribute Extensions.
Object Viewer
A utility in which you can view the attribute values of the selected object in run-time. This utility is
only available when an object is deployed. Object Viewer provides the user with diagnostic
information on Application Objects for the purpose of detecting performance parameters, resource
consumption and reliability measurements. In addition to viewing an objects data value, data
quality and the communication status of the object, you can also modify some of its attributes for
Wonderware Training

diagnostic testing. Modifications can include adjusting timing parameters and setting objects in an
execution or idle mode.
OffScan
The state of an Object that indicates it is idle and not ready to execute its normal runtime
processing.
OnScan
The state of an Object in which it is performing its normal runtime processing based on a
configured schedule.
Package Definition File (.aaPDF)
The standard description file that contains the configuration data and implementation code for a
base template. File extension is .aaPDF.
Package File (.aaPKG)
The standard description file that contains the configuration data and implementation code for one
or more object instances or Templates. File extension is .aaPKG.
Platform Count
Number of PCs in the Galaxy. Each Workstation and/or Server communicating directly with the
Application Server requires a platform to be part of the Galaxy Namespace. This includes each
InTouch 9.0 or higher and InTouch View 8.0 or higher client. Each InTouch Terminal Services
Session needs IAS Terminal Services Session License. A Platform License includes a per seat
FSCAL2000 with Microsoft 2000 SQL Server CAL. Stand-alone computers that only host InSQL
Servers or remote DA Servers do not need a platform license.
Platform Manager
The Platform Manager provides Galaxy application diagnostics by allowing you to view the runtime status of some system objects and to perform actions upon those objects. Actions include
setting platforms and engines in an executable or idle mode and starting and stopping platforms
and engines. This utility is an extension snap-in to the ArchestrA System Management Console
(SMC).
Platform Object
An object that represents a single computer in a Galaxy, consisting of a system wide message
exchange component and a set of basic services. This object hosts all Application Engines.
PLC
Programmable logic controller.
Primary Application Engine
The object created by the ArchestrA infrastructure when the Backup object has been created
through Redundancy. See Redundancy for further detail.
Properties
Data common to all attributes of objects, such as name, value, quality, and data type.
Proxy Object
A Proxy Objects is an Automation Object that represents an actual product for the purpose of
device integration with the Industrial Application Server or InTouch HMI. For example, there is a
Proxy Object that enables the Industrial Application Server to access an OPC server.
Redundancy
During Configuration
C-7
C-8

z
Primary object: The object intended as the main or central provider of the functionality in
the run-time. For AppEngines, it is the object you enable for redundancy. For data
acquisition, it is the DIObject you intend to use first as your data source in the run-time.
Backup object: The object that provides the functionality of the Primary object when it fails.
For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary
object has been enabled for redundancy. For data acquisition, it is the DIObject you do not
intend to use first as your data source in the run-time.
During Run-Time
z
Active object: The object that is currently executing desired functions. For AppEngines, it
is the object that is hosting and executing ApplicationObjects. For data acquisition, it is the
object that is providing field device data through the RedundantDIObject.
Standby object: The passive object; that is, it is waiting for a failure in the Active objects
condition or for a force-failover. For AppEngines, it is the object that monitors the status of
the Active AppEngine. For data acquisition, it is the object that is not providing field device
data through the RedundantDIObject.
Redundant DI Object
The RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike
redundant AppEngines, individual DIObject data sources do not have redundancy-related states.
For all intents and purposes, they function as standalone objects.
Redundant Message Channel
The Redundant Message Channel (RMC) is a dedicated Ethernet connection which is required
between the platforms hosting redundant engines. The RMC is vital to keep both engines
synchronized with alarms, history, and checkpoint items from the engine that is in the Active Role.
Each engine also uses this Message Channel to provide its health and status information to the
other.
Reference
A string that refers to an object or to data within one of its attributes.
Relational Reference
A reference to an objects attributes that uses a keyword in place of an object's tagname. These
keywords allow a reference to be made by an object's relationship to the target attribute. Examples
of these keywords are "Me", "MyPlatform", and "MyContainer".
Remote Reference
The ability to redirect ArchestrA object references or references to remote InTouch tags. The new
script function used to redirect remote references at runtime is IOSetRemoteReferences.
Runtime
The InTouch (WindowViewer) function that provides the viewing of data from the configuration
of the application in InTouch development (WindowMaker).
Scan Group
A DAGroup that requires only the update interval be defined and the data will be retrieved at the
requested rate.
Scan State
The Scan State of an object in run-time. This can be either off-scan or on-scan.
Security
Industrial Application Server security is applied to IDE, SMC, and the runtime data level. At the
runtime data level which centralizes the definition of all permissions to the ApplicationObjects.
These ApplicationObjects can be accessed by a variety of clients but the security is centrally
defined allowing ease of maintenance. The users that are allowed to modify these
Wonderware Training

ApplicationObjects at runtime are mapped to the objects by user defined roles. These roles can be
mapped directly to existing groups in a Microsoft Domain or workgroup.
SmartSymbols
SmartSymbols are objects that integrate object-oriented technology with InTouch graphics to
transform them into reusable templates. Changes made to the templates automatically propagate
throughout an application even across multiple networked PC nodes. They are created from a
graphic in an InTouch window that has been made into a cell and converted into a SmartSymbol.
In addition, libraries of SmartSymbols can be exported to other applications and plants, enabling
companies to standardize on graphics throughout the entire organization.
System Management Console (SMC)
The central runtime system administration/management user interface in which all required
runtime administration functions can be accomplished.
System Objects
Objects that represent an Area, Platform or Engine.
TagName
The unique name given to an object. For instance, for a given object, its TagName = V1101 and its
HierarchicalName = Line1.Tank1.InletValve.
Template
An object containing configuration information and software templates used to create new Derived
Templates and/or Instances.
Template Toolbox
The part of the IDE Main Window that hosts template toolsets, which contain object templates. The
Template Toolbox contains a tree view of template categories in the Galaxy.
Toolset
A named collection of Templates displayed together in the IDE Template ToolBox.
User Defined Attributes (UDA)
The purpose of a User Defined Attribute is to allow users to add new functionality to an object. An
attribute which is added to an object at configuration time
UserDefined object
An AutomationObject created from the $UserDefined template. This template does not have any
application-specific attributes or logic. Therefore, the user must define these attributes and
associated logic.
WinPlatform object
An object that represents a single computer in a Galaxy, consisting of a systemwide message
exchange component, a set of basic services, the operating system, and the physical hardware.
This object hosts all AppEngines.
C-9
C-10
Wonderware Training
W O N D E R W A R E
T R A I N I N G
Instructor Notes
Revision C
June 2005
Part Number 05-2056
Industrial
Application Server
2.0 Course
Course Developer
E-mail
Telephone
Dana Lundy
Dana.Lundy@wonderware.com
949-639-8639
Wonderware Training
Note: Important! The only difference in Rev B and Rev C is Appendix A. The Licensing
information was revised.
Instructor Preparation and Class Setup

System Requirements for Industrial Application Server/Galaxy Repository
To run the Application Server, the following hardware and software are recommended.
Software Requirements
FactorySuite A Development seat IDE with Galaxy Repository (Project Database)
z
Microsoft SQL Server 2000 Service Pack 3a and
Microsoft Windows 2000 Advanced Server with Service Pack 4
Important! The Microsoft SQL Server login for BUILTIN\Administrators group must be present
and enabled.
FactorySuite A Development seat IDE with no Galaxy Repository (Project Database)
z
FactorySuite A Application Server Runtime

z
Hardware Requirements
z
PC with 2 gigahertz (GHz) or higher processor clock speed
1 gigabyte (GB) of RAM or higher (512 MB minimum supported; may limit performance
and some features)
8 gigabytes (GB) of available hard disk space
Super VGA (1024 768) or higher-resolution video adapter and monitor
4
z
CD-ROM or DVD drive
Keyboard and Microsoft Mouse or compatible pointing device
Note:
Support for Windows Server 2003
Industrial Application Server 2.0 leverages the Microsoft operating system, Windows Server 2003.
Version 2.0 of Industrial Application Server has been thoroughly tested on this new OS enabling
the user to immediately take advantage of its functionality.
Additional Application Server Node Software Requirements

z
WinZip
Industrial Application Server 2.0
InTouch 9.0SP 2 w/ IAS Training Application for InTouch
Active Factory
Various documents and objects included in the training package
Historian Node Software Requirements

z
Windows 2000 Server w/SP3
MS SQL Server 2000 w/SP2
InSQL 8.0 w/SP1
Control Simulation Node Software Requirements

z
Windows NT or 2000
InControl 7.1 w/SP1
IAS Training Application for InControl
Setup Notes
z
The software must be installed on networked machines
DHCP is recommended
Each student machine is a full App Server node (FactorySuite A Development seat IDE
with Galaxy Repository )
There is only one Historian Node required on the network
The App Server node and the Historian node software must be installed with the same
Admin account
If the OPC proxy DI object is used, DCOMCNFG must be used to set up InControl's server
and OPCEnum on both App Server node and Control Simulation node
New and Enhanced Features (see separate New Features

PowerPoint presentation)
Multiple features and powerful functionality have been added to Industrial Application server 2.0.
The main items incorporated or enhanced include:
Wonderware Training
5
z
High Availability
Performance
Usability
Connectivity
Scalability
High Availability
Migration
The process to upgrade the software and migrate the configuration database is simple and
transparent to the user. It provides minimal downtime when updating current systems to the new
version as it basically consists of two steps:
1. A Software Upgrade From IAS 1.5 [+Patch01] to 2.0
2. A Seamless Galaxy Migration
"From .cab File (Galaxy Backup)
Note: Restore First, then Migrate
"From .aaPKG (Templates/Instances)
Note: Select "Migrate" when Importing
Redundancy
Two key features of the system provide built in Redundancy:
z
Application Execution - Redundant AppEngines
IO Data source - Redundant DI Object
AppEngine Redundancy:
A pair of AppEngines can be configured to provide high availability to the system. The pair consists
of an Active Engine which executes the application and a Standby Engine which takes control of
the application when the Active one fails. Configuration requirements are minimal as the system
automatically creates the redundant pair and in runtime it continually synchronizes data, alarms
and history between the pair.
Redundant DI Objects:
At the IO data level, a Redundant DI object can be configured to have a pair of IO data sources
where one is Active and the other one is in standby mode. If the Active data source fails the
Redundant DI Objects uses the Standby data source to communicate with devices in the field.
Improved Store and Forward functionality

Both IndustrialSQL Server 8.0 SP3 and Industrial Application Server 2.0 incorporate major
enhancements to the performance of the Store and forward capability. This improvement has
important impact on SCADA systems with limited bandwidth and intermittent networks.
6
Connectivity
Industrial Application Server as an OPC Server
The FactorySuite Gateway (FS Gateway) provides support for Industrial Application Server 2.0.
Using FS Gateway a Galaxy becomes an OPC server for an OPC Client that requires access to
Galaxy data.
Additionally FS Gateway allows legacy IO servers to provide data to the Galaxy.
OPC item browsing

A key feature of this release is the ability provided by the OPC Client Object to browse OPC
Servers. The OPC Item Browser allows users to browse the namespace of an OPC Server and
choose items to add to a scan group, block read group, or block write group as long as the OPC
server supports browsing.
Also it is now possible to Import/Export the items list in the DDE\SuiteLink client as well as in the
OPC Client object.
Performance
Support for slow and intermittent networks
Important enhancements have been incorporated in Industrial Application Server 2.0 to support
networks with poor performance caused by low bandwidth and intermittent availability.
MX protocol
Microsoft Message Queue has been replaced by Sockets technology in the protocol to optimize
the data transfer over the network.
User authentication
The mechanism used to authenticate users/groups in a Domain has been enhanced to allow for a
more robust system performance.
Store and Forward capabilities
The Store and Forward functionality has been optimized to improve data storage to the historian.
CPU and Memory utilization
Improvements in the script evaluation mechanism has contributed to the optimization of CPU and
Memory utilization.
Usability
Full support for InTouch SmartSymbols
Industrial Application Server 2.0 seamlessly integrates to InTouch SmartSymbols. It allows
browsing the Template toolbox to simplify linking attributes between both applications. New
instances of an existing Template can be automatically created from the SmartSymbol making
them ready for deployment in the IDE.
Wonderware Training
7
Improvements to Multi-user environment
Various enhancements have been incorporated into the Multi user capability to simplify concurrent
configuration of a Galaxy.
Diagnostics and maintenance

Many new attributes associated with Redundant AppEngines and Redundant DI Objects are
available to monitor the system status and diagnose problems.
Also, more comprehensive information for maintenance purposes is available in this release. The
SMC provides detailed information on operations such as Database restore and Database
Migration, including initializing and completion time.
Documentation
New documents and resources have been created and the existing ones have been updated and
improved to assist users defining and configuring FactorySuite A2 systems.
Getting Started with Industrial Application Server

Presents an overview of Industrial Application Server that walks you through the steps needed to
create a simple working application for a typical plant production facility. This is available as a webbased application at www.wonderware.com
IDE User guide:

On line help documentation is provided with updated information on new functionality, features and
enhancements. This is available on the Wonderware Tech Support Web site and in the Industrial
Application Server Product CD.
FactorySuite A2 Deployment Guide

New and updated best practices and recommendations on configuring and implementing a
FactorySuite A2 system are documented in the latest version of the Deployment Guide.
This is a key resource on providing useful information to users that need to implement SCADA
systems and redundant configurations. This is available on the Wonderware Technical Support
Web Site, under Industrial Application Server Documentation.
Licensing
Galaxy IO count license
New IO count license sizes are available to implement smaller and larger systems. The IO count
scale is available in the following increments: 250, 2500, 4500, 25K, 50K, 100K, 200K, 500K and 1
Million IO. Contact your distributor for ordering information
8
FactorySuite Development license
The FS Development license has also been scaled down to support the implementation of smaller
systems. For the different sizes, please consult your distributor.
Instructor Note References

Page 1-3
Course Introduction
Introduce yourself.
Have students introduce themselves:
z
Company
Current Position
Level of expertise with Wonderware products
Expectations of the course
Give course logistics:

z
Class times
Breaks & lunch
Phones & restrooms
Contacting Wonderware
Go through materials in Training Kits.
Instructor Note
There are a couple of Script files provided with the Instructor Info for this course. After a
discussion of scripting, you may want to provide these Script files to the students to allow them to
enter them into their labs. These scripts are for Lab 10 - Object Reuse and for Lab 11 - Averager.
Module 2
There are no labs in this Module, however, it is of key importance in that it stresses the need for
the creation of the application to be driven by first modeling the Plant. This helps organize the
Areas with the respective objects that represent the Plant components for the particular Areas of
the factory floor. It also prepares the developer for establishing an effective naming convention
which can be vital to future development.
Module 3
Lab 1 - Creating a Galaxy - This lab walks the student through the actual steps of how to create a
galaxy. Ensure they use the initials of their first and last name to preface the name of their galaxy.
Wonderware Training
Lab 2 - Facility Model - This lab is to reinforce the concept of the model view and the importance
of approaching an integration job through the model building paradigm. We are using instances
here because the template concepts have not been introduced yet. When templates have been
covered, the instructor should revisit this lab to discuss the importance of deriving area instances
from derived templates rather than base templates. Area containment is also introduced.
Lab 3 - Create and Deploy a Platform - This lab is to introduce some of the Platform's
functionality as well as the functionality of the Object Viewer. Prior to the lab, the instructor should
discuss message exchange and the platform's use of it.
Lab 4 - Create and Deploy and Engine - This lab is to introduce some of the Engine's
functionality. Some important concepts to discuss before this lab include scan period,
checkpointing and the scheduler. This is a good time to go back to the platform object and discuss
the engine and scheduler tabs on the platform's editor. The difference between Model View and
Deployment View can be explored here.
Module 4
Lab 5 - Device Integration Object - This lab is to introduce some of the functionality of the
DDESuiteLinkProxy object. The ConectionStatus and Reconnect properties should be discussed.
This is a good time to further explore the Object Viewer by describing the Security and Category
columns. A description of the control layer and InControl should precede the lab. The Object
Viewer's Attribute Reference input box can be used to type in a reference to one of the simulated
items in the InControl app (InControl.Tagname.XXX)
Note: There is a csv file provided for use with this lab.
Lab 6 - Analog Devices - This lab is to introduce the Analog device. The student will see for the
first time Appserver's relationship to real IO. The PV.InputSource can not be browsed to at this
point because we have not made any attribute references. It is best to introduce the attribute
reference after the lab.
Lab 7 - DiscreteDevices - Valve Instance - In this lab, the Discrete Device is introduced. This is a
complex device and should be discussed thoroughly. It is necessary to further explore the control
logic and discuss the OLS, CLS and cmdOpen bits in the InControl app before the lab.
Module 5
Lab 8 - Modeling Complex Objects - Templates are introduced in this lab. It's important that the
student thoroughly understand the IO requirements and the tank structure. The student's initials
must be must be placed on the $Valve template. When troubleshooting, the first place to look is
the ReadStatus and WriteStatus properties in Object Viewer.
10
Lab 9 - Change Control and Propagation - The Locked In Parent functionality should be
discussed here as a way to propagate changes to objects instantiated by templates. Explain
unlocking through multiple levels of templates.
Lab 10 - Object Reuse - This lab is intended to show the power of templates. A discussion on how
standards are imposed by good template development is needed. The use of the keywords Me,
MyContainer, MyEngine should precede the lab.
Lab 11 -Averager - This lab illustrates the ability to extend the object's attributes through scripting
by creating an Averager object that calculates the PV average.
Lab 12 - Extensions - This lab uses an extension with an advanced technique. A discussion of
the MXReference data type and reference binding is needed. It will be necessary to demonstrate a
simpler use of extensions before the lab.
Module 6
Lab 13 - Alarming - The importance of this lab is to show how alarming is the responsibility of the
object which is in alarm and how areas are used to filter alarms. It should be stressed that the
Platform is not raising the alarm; rather it is the conduit through which the object alarms are
provided. A discussion of alarm providers and consumers should precede the lab. Explain how
multiple Platforms and Areas affect the network traffic.
Lab 14 - Historization - It is important in this lab, as in the alarm lab, to stress that it is the object
that decides when to historize. The engine is used to pass the value to the historian and to perform
the store and forward functionality.
Note: The instructor will need a separate machine to install InSQL. This machine should be on a
projector so the instructor can show changes made to InSQL as the historized object gets
deployed (or use a remote InSQL Console). Note that the students will not see any data in their
trend if their AppServer is not time-synchronized with the InSQL machine. A description of InSQL
and MDAS should precede the lab.
Module 7
Lab 15 - Application Server Security Settings - The importance of this lab is to show how the
various User Groups and Roles can be used to configure a given application for specific security
by User.
Lab 16 - Authentication - This lab extends the discussion of security to include OS Group based
security.
Wonderware Training
11
Module 8
Lab 17 - Exporting/Importing CSV Files - This lab will illustrate how objects can be exported and
modified externally. Subsequently they can be imported so as to create additional instances of the
objects.
Lab 18 - SMC Operation - This lab will illustrate the functions associated with the System
Management Console. We will look at how to start and stop Platforms and Engines from the
Platform Manager, how to work with the Log Viewer, the DAServer Manager and the Galaxy
Database Manager.
Module 9
Lab 19 - FactorySuite Gateway - This is a new lab to illustrate the new features associated with
the FactorySuite Gateway product. This lab will identify the steps needed to configure two (2)
machines - the Instructor machine and the Student machine for FactorySuite Gateway.
Note: FactorySuite Gateway 1.0 must be previously installed on the Instructor's computer.
Module 10
Lab 20 - Properties Visualization - When using InTouch as the view component for Industrial
AppServer the InTouch application must reside on a node with a Bootstrap and Platform object
deployed. In this configuration InTouch will use the message exchange functionality of the
Platform, enabling Galaxy namespace browsing and increased data communication functionality.
In this lab the students will configure a remote tag source to point to the galaxy, and map the
ApplicationObject properties to InTouch tags for viewing.
Lab 21 - Alarm Connectivity in InTouch - This lab will illustrate how to connect the Galaxy to
Alarm Summary and Alarm Event/Summary in InTouch. Then how to acknowledge those alarms in
Runtime.
Lab 22 - Tank System Visualization - The client abstraction layer used by InTouch to
communicate with the Galaxy exposes several object property dot fields that can be used to build
animation links. The Object.Property.Value will map to a data type in InTouch as described in the
mapping table in this section (e.g. an object Boolean will map to an InTouch discrete). The
Object.Property.#VString will map to a message that represents not only the object value but
diagnostic information also. The Object.Property.#EnumOrdinal will map to an InTouch Integer that
represents one of many states the property can assume. In this lab you will use some of the
property dot fields to build animation links against the App Server objects.
12
This lab also introduces the students to how to create a SmartSymbol in InTouch and configure it
to reference the objects in their Galaxy.
Lab 23 - InTouch Tag Connectivity - In AppServer, we can use a Device Integration Object to
connect to InTouch, browse the Tagname Dictionary and import those tags into our object in the
IDE. This can provide faster connectivity. In this lab we will configure an InTouchProxy Device
Integration object to connect to InTouch, browse the Tagname Dictionary and select a certain one
to connect to through the IDE. We will then use the Object Viewer to verify connectivity.
Module 11
Lab 24 - Redundancy - This is a new lab which describes the steps necessary to configure
redundancy between two nodes. It explains the necessary hardware requirements and
configuration as well as the required IDE configuration.
Lab 25 - Convert to Network Environment - This lab will describe the steps necessary to convert
to a Networked Configuration. In the networked environment a common Galaxy Repository will be
shared between a set of PCs allowing multiple users to simultaneously work on the same
application.
Wonderware Training

Ias 2 0 Revc Gold Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ias 2 0 Revc Gold Manual

Uploaded by

Copyright:

Available Formats

W O N D E R W A R E

INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

Application Planning and the Plant Model ...............................2-1

The Galaxy ...................................................................................3-1

Complex Object Modeling Extending the Objects ................5-1

Alarming and History..................................................................6-1

Securing the Galaxy....................................................................7-1

Industrial Application Server 2.0 Course

Industrial Application Server 2.0 Course

DAServers and DI Objects ......................................................... 9-1

Multi-Node Galaxies ................................................................. 11-1

Appendix A ArchestrA Licensing ..................................................................A-1

Section 3 IAS System Requirements

Section 4 Architectural Overview

Section 5 Installation and Licensing

Be introduced to the FactorySuite Industrial Application Server and understand its

Section 1 Course Introduction

Section 1 Course Introduction

Main Course Objective

Industrial Application Server 2.0 Course

What is Industrial Application Server?

Why use ArchestrA?

Global Name Space(example)

Advanced Communications Capabilities(example)

Pervasive, Flexible Security(example)

True Object Methodology

Single point of configuration(alarms,history,security)

Reuse of engineering effort

Module 2 Application Planning and the Plant Model

The need for a project workflow

understanding area devices

identification of functional requirements

Section 1 Course Introduction

object-oriented tools in manufacturing applications

Plant Model for Developing (IAS) Course Application

Module 3 The Galaxy

What is a Galaxy Repository?

Instructor lead view Galaxy db after create

Single User / Multi User Environment

Lab 1 - Creating a Galaxy

Set User Preferences

Right Click Object Information

Areas as Logical Groupings of Process

Develop device list

Common Devices as Templates

Impose standards at this level

Lab 2 Facility Model

Industrial Application Server 2.0 Course

Creating an Instance (Platform Object)

Check Out/ Check In

Information / Warning Icons

Deploying / Options - User Preferences

Device Integration Properties (OPC & SL Proxy)

Lab 3 Create and Deploy a Platform

Module 4 - Modeling Equipment

Analog Device Properties

Discrete Device Properties

Lab 5 DeviceIntegration Object

Module 5 Complex Object Modeling - Extending the Objects

Area (Alarm Modeling)

Host (Resource Modeling)

Containment (Process Modeling)

Extending & Enhancing Your Object Models

User Defined Attributes