Wonderware System Platform   

Product Orientation – Part I 
Wonderware Application Server 3.1 and Device Integration Products  
Foreword
This is a two-part series of self-study guide with hands-on lab, designed to provide a fundamental
understanding of the basic principles of ArchestrA and supply the knowledge necessary to develop
and support applications for Wonderware System Platform.

In this Part I of the two-part series, the focus is to illustrate the use of ArchestrA tools and services in
the System Platform to develop a project utilizing connectivity to the field, data processing, scripts,
alarms and history, using features and functionality such as Automation Objects, templates, template
instances, ArchestrA Integrated Development Environment and QuickScript .NET.

Part I also provides a fundamental understanding of how to utilize the InTouch Alarm DB Logger for
real-time alarm recording as well as the security settings available for securing the applications.

First of all, before you embark on this self-study guide, please setup a virtual machine (either VPC or
VMWare), loaded with the following operating system and software:

1. Windows Server 2008 Standard Edition (with SP2)

OR Windows Server 2003 R2 Standard Edition (with SP2)
2. Microsoft SQL Server 2008 (with SP2)
OR Microsoft SQL Server 2005 (with SP3)
3. Microsoft Office Enterprise 2007
4. Wonderware Application Server 3.1 with SP2
5. Wonderware InTouch 10.1 with SP2
6. Wonderware Historian Server 10.0
7. WonderwareHistorian Client 10.0
8. Wonderware Information Server 4.0
9. Wonderware InControl 7.11 with SP2

Additional Setup

After you’ve set up your virtual machine, you will need to load the InControl training project, which will
be provided to you. The supplied InControl training project needs to be up and running before
beginning Lab 6, “Connecting to the Field.”

To load and start the InControl training project, please follow the steps explicated on the next page:

 
1. Start InControl by selecting Start / All Programs / Wonderware / InControl.
2. In the InControl – Project Manager select the File / Search menu option.
3. Select the C:\Wonderware Training\InControl A2 Mixer System folder and click OK.
4. Double-click the entry ArchestrA Mixer System Simulation.
5. In the InControl Development Environment select the Runtime / Connect menu option.
6. Select the Runtime / Run Project menu option.
7. Select the Full Restart option and click OK.

Supplied Files
 $SecurityTest.aaPKG: This file contains a $UserDefined derived template pre-configured with
several UDAs. The file is used in Lab 17 – Security.
 InControl Items List.csv: This file contains all the I/O signals from the InControl project for the
heat exchangers and mixers to be used in the class. The file is used in the configuration of the
device integration object created in Lab 6 – Connecting to the Field.
 Lab 14 - Configuring Automatic Reference.txt: This file includes the script text used in Lab 14 –
Configuring Automatic Reference.

Please copy all the files indicated above, to the local directory of your Virtual Machine, under the
C:\Wonderware Training folder. This self-study guide makes reference to this specific location when
giving directions to locate a specific file.

 
Table of Contents
Module 1 Introduction

Section 1 – Course Introduction

Section 2 – Wonderware System Platform

Lab 1 – Creating a Galaxy

Section 3 – The ArchestrA IDE

Section 4 – Automation Objects

Section 5 – System Requirements, Licensing and Support

Section 6 – Application Planning

Lab 2 – Identifying the Mixer

Module 2 Application Infrastructure

Section 1 – The Plant Model

Lab 3 – Creating the Plant Model

Section 2 – The Deployment Model

Lab 4 – Creating the Deployment Model

Section 3 – The Runtime Environment

Lab 5 – Using Object Viewer

Section 4 – Connecting to the Field

Lab 6 – Connecting to the Field

Module 3 Application Objects

Section 1 – Templates and Instances

Section 2 – The $UserDefined Object

Lab 7 – Modeling the Heat Exchanger

Section 3 – Change Control and Propagation

Lab 8 – Configuring Change Control and Propagation

Section 4 – The $AnalogDevice Object

Lab 9 – Modeling a Meter

Section 5 – The $DiscreteDevice Object

Lab 10 – Modeling a Valve, Pump, and Motor

Section 6 – Containment

Lab 11 – Creating the Mixer

Module 4 Extending the Objects
Section 1 – UDAs

Section 2 – Extensions

Lab 12 – Configuring the Motor Speed

Section 3 – Introduction to QuickScript .NET

Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient

Lab 14 – Configuring Automatic Reference

Module 5 Alarms and History

Section 1 – Alarms

Lab 15 – Configuring Alarms

Section 2 – Historization

Lab 16 – Configuring History

Module 6 Security
Section 1 – Security Overview

Lab 17 – Security

Module 7 Galaxy Maintenance

Section 1 – Exporting and Importing Objects

Section 2 – Configuring Instances Through a .CSV File

Section 3 – System Management Console (SMC)

Section 4 – Network Account Utility

Module 8 Device Integration Products

Section 1 – Wonderware I/O Servers

Section 2 – Wonderware Data Access Servers

Section 3 – Device Integration Objects

Module 9 Multi-Node Applications

Section 1 – Application Redundancy

Lab 18 – Configuring Application Redundancy

Section 2 – DI Redundancy

Lab 19 – Configuring the Redundant DI Object

Section 3 – Multi Node Application

Appendix A Wonderware Application Server Glossary

MODULE 1
Introduction
Section 1 – Course Introduction
Section 2 – Wonderware System Platform
Lab 1 – Creating a Galaxy
Section 3 – The ArchestrA IDE
Section 4 – Automation Objects
Section 5 – System Requirements, Licensing and Support
Section 6 – Application Planning
Lab 2 – Identifying the Mixer

OBJECTIVE
 Introduce the Wonderware System Platform and its architecture, environment, and requirements for
installation and licensing.
Section 1 – Course Introduction
Section Objective
This section identifies the objectives and agenda for the System Platform -Part 1 as well as the key basics of
Wonderware Application Server.

This section describes System Platform -Part 1 / Wonderware Application Server 3.1 and Device Integration Products, the
objective of the course, intended audience, prerequisites, and the course agenda. It also includes a description of
Wonderware Products.

Agenda

Module 1 – Introduction
Section 1 – Course Introduction
This section describes System Platform -Part 1 / Wonderware Application Server 3.1 and Device Integration
Products, the objective of the course, intended audience, prerequisites, and the course agenda. It also includes a
description of Wonderware Products.
Section 2 – Wonderware System Platform
This section provides an overview of the Wonderware System Platform and how critical the architecture of ArchestrA
is to plant automation. An overview of the differences between Object-oriented and traditional Tag based HMI and
SCADA products is provided, as well as how these differences apply to Wonderware System Platform applications.
This section will also provide a description of what a Galaxy is, how it relates to the Galaxy Database and the Galaxy
Repository and how a Galaxy is created.
Lab 1 – Creating a Galaxy
Section 3 – The ArchestrA IDE
This section provides an overview of the ArchestrA IDE, the Template Toolbox and Application Views and the object
Check-in/Check-out process.
Section 4 – Automation Objects
This section provides an explanation of the various types of objects utilized in the ArchestrA IDE and an overview of
when and how they are used. Additionally, it describes how to create and configure instances of objects and the
hosting and containment relationships of objects.
Section 5 – System Requirements, Licensing and Support
This section provides a detailed explanation of the system requirements necessary for Wonderware System
Platform, discusses Licensing details and covers Support services.
Section 6 – Application Planning
This section provides an explanation of the need for adequately modeling your plant in order to achieve an application
implementation that will be optimal for efficiency.
Lab 2 – Identifying the Mixer

Module 2 – Application Infrastructure

Section 1 – The Plant Model
This section provides an explanation of the importance of having a model of the plant facility. Additionally, it explains
the concept of how to utilize ArchestrA Application Server to model a specific facility.
Lab 3 – Creating the Plant Model
Section 2 – The Deployment Model
This section provides an explanation of the Deployment Model and demonstrates the structure of the Deployment
Model.
Lab 4 – Creating the Deployment Model
Section 3 – The Runtime Environment
This section provides an explanation of the Runtime environment and explains the use of the Object Viewer in
monitoring the Runtime environment.
Lab 5 – Using Object Viewer
Section 4 – Connecting to the Field
This section provides an understanding of the Device Integration Objects, I/O Server and DA Server. It also provides
an overview of DI Objects.
Lab 6 – Connecting to the Field

Module 3 – Application Objects

Section 1 – Templates and Instances
This section introduces you to the concept of templates and explain how to derive a template.
Section 2 – The $UserDefined Object

This section introduces you to the $UserDefined object and its functionality. Lab 7 – Modeling the Heat Exchanger
Section 3 – Change Control and Propagation
This section presents the concept of attribute locking and provides an illustrations on how locking attributes can
propagate to previously derived instances.
Lab 8 – Configuring Change Control and Propagation
Section 4 – The $AnalogDevice Object

This section introduces you to the concept of the $AnalogDevice object and its functionality. Lab 9 – Modeling a
Meter
Section 5 – The $DiscreteDevice Object

This section introduces you to the concept of the $DiscreteDevice object and its functionality. Lab 10 – Modeling a
Valve, Pump, and Motor
Section 6 – Containment
This section illustrates the concept of containment and how it works with Application Objects and Templates.
Lab 11 – Creating the Mixer

Module 4 – Extending the Objects

Section 1 – UDAs
This section introduces and explains UDAs and how they are configured and used.
Section 2 – Extensions
This section provides describes the Output Functionality for Application Objects in the Extensions environment.
Lab 12 – Configuring the Motor Speed
Section 3 – Introduction to QuickScript .NET
This section introduces and explains the scripting environment and the various scripting configuration attributes of the
ApplicationObject. Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient Lab 14 – Configuring Automatic Reference

Module 5 – Alarms and History

Section 1 – Alarms
This section provides familiarization of the concept of alarms and events and how ArchestrA handles them.
Lab 15 – Configuring Alarms
Section 2 – Historization
This section provides familiarization with the background concept of historization and the details of historizable
configuration.
Lab 16 – Configuring History
Module 6 – Security
Section 1 – Security Overview
This section provides an understanding of Security as it relates to Application Server.
Lab 17 – Security

Module 7 – Galaxy Maintenance

Section 1 – Exporting and Importing Objects
This section provides an understanding of fundamental functions dealing with Galaxy Maintenance. Specifically, it
illustrates how to Export for future use and how to Import a galaxy created previously.
Section 2 – Configuring Instances Through a .CSV File
This section provides an understanding of fundamental functions dealing with Galaxy Maintenance. Specifically, it
illustrates how to Export for future use and how to Import a galaxy created previously.
Section 3 – System Management Console (SMC)
This section provides an understanding of role of the System Management Console and how it can be configured.
Section 4 – Network Account Utility
This section discusses the role of changing the network account and how to use the Change Network Account and
how to configure it.

Module 8 – Device Integration Products

Section 1 – Wonderware I/O Servers
This section will describe the configuration of a Wonderware I/O Server (Modbus).
Section 2 – Wonderware Data Access Servers
This section provides familiarization with Wonderware Data Access Server and its use with Application Server.
Section 3 – Device Integration Objects
This section provides familiarization with DI Objects and their use with Wonderware Application Server.

Module 9 – Multi-Node Applications

Section 1 – Application Redundancy
This section provides an understanding of the concept of redundancy, how it can be configured and key points to
more effectively implement this feature. It also provides an understanding of the concept and functionality of
Redundant DI Objects
Lab 18 – Configuring Application Redundancy
Section 2 – DI Redundancy
This section provides an understanding of the concept of redundancy, how it can be configured and key points to
more effectively implement this feature. It also provides an understanding of the concept and functionality of
Redundant DI Objects
Lab 19 – Configuring the Redundant DI Object
Section 3 – Multi Node Application
This section provides an understanding of how to migrate from a standalone configuration to a network configuration.
At the conclusion of this section you will have an understanding of the steps necessary to migrate to a network
environment.
Lab 20 – Convert to Network Environment
Wonderware software solutions
Wonderware is the leading supplier of real-time operations management industrial software solutions for Manufacturing
Execution Systems (MES), Performance Management, Enterprise Manufacturing Intelligence (EMI), and integration
with asset management, Supervisory HMI, GeoSCADA, Production Management, supply and demand chain, and
Enterprise Resource Planning (ERP) applications.
Wonderware delivers significant cost reductions associated with designing, building, deploying and maintaining secure and
standardized applications for manufacturing and industrial operations. Wonderware software solutions enable companies
to synchronize their production operations with business objectives, obtaining the speed and flexibility to attain sustained
profitability.
Over one-third of the world's plants and facilities run Wonderware software solutions in dozens of industries worldwide,
such as:
• Automotive
• Chemical & Pharmaceutical
• CPG (Food & Beverage)
• Discrete Manufacturing
• Electrical Power
• Facilities Management
• Mining and Metals
• Oil and Gas
• Process Manufacturing
• Water and Wastewater

Wonderware software solutions deliver manufacturing and operational performance improvements that help reduce the
amount of project-specific work required to develop information and automation applications that are integrated across
entire operational enterprises. They can be implemented in the context of existing systems, at a company’s own pace and
to the extent that they choose.
These solutions leverage apowerful, layered software architecture that enables a variety of features and capabilities, 
suchas visualization, optimization and control of plant floor data collection, and data storage and analysis.   

Wonderware offers the following software solutions:

• Manufacturing Execution Systems–Manufacturing Execution Systems (MES) solutions feature a complete set
of functional capabilities for consistent and effective execution of operational activities. Leveraging the ArchestrA software
architecture,Wonderware MES solutions are completely scalable and configurable. This enables a unique, incremental
approachto operational improvements where low-risk deployment of increased application functionality can berealized one
stepatatime. Wonderware MES solutions help tosubstantially reducelead time and manufacturing costs, increase
production throughput and product quality, and reduceefforts involved in compliance and governance.
• Enterprise Manufacturing Intelligence– Enterprise Manufacturing Intelligence (EMI) software solutions
empower companies to analyze theiroverall operational performance using simple yet powerful data analysis andreporting
tools. Production, costs, process capability, equipment downtime, and quality and variancedata can be collected,
aggregated, and displayed usingWonderware EMI software solutions. A powerful yet secure Web interface helps deliver
this informationto the full range of plant workers – tailored to theirspecific information requirements.
• HMI/SCADA – HMI/SCADA solutions often impose complex demands on software architectures. Wonderware
InTouch HMI visualization software, coupledwith the award-winningArchestrAtechnology-based Wonderware System
Platform is uniquely positioned to meet these challenges. The HMI/SCADA software solutions are easy to use, implement
and configure, and offer simplified maintenance, high securityand availability, and virtually unlimited scalability.
• Data Historian – WonderwareHistorian softwareleverages thestate-of-the-art Wonderware System Platform,
industryleading historian technology, Web-basedreporting capabilities, and renowned open data source connectivity
from Wonderware. The resulting historian solution is unlike any other data archiving and reporting solution found in the
market today. With blazing speed, broad scalability, highly efficient data storage and retrieval, high availability and
simple one-click historization setup, the Wonderware Historian software has an industry reputation for low total cost of
ownership. Preconfigured Web-based reports and data analysis capabilities drive immediate value from data captured
by the Wonderware Historian.
• Batch Management – Wonderware batch management solutions perform repeatable and consistent execution of
batching processes across all hybrid industries, whether it is electronic batch records (EBR) systems in regulated
industries, Paper-On-Glass capabilities in paperless production environments, or automated recipe management for
supervisory systems. From simple batch processes, where only the formula changes for different products, to the most
complex batch processes requiring dynamic allocation of shared equipment, Wonderware has a solution. Each of these
solutions ensures reduced lifecycle costs and investment protection by leveraging the ArchestrA architecture.
• Product Quality Management and SPC – Delivering products with high quality – defined as meeting
specifications at the lowest possible cost – is a top priority for manufacturers and industrial operations, and Wonderware
software applications meet these quality needs. InTouch HMI offers real-time data monitoring and alarming; Wonderware
Historian stores voluminous process data for quality analysis; Wonderware QI Analyst software provides enterprise-wide
SPC; Wonderware ActiveFactory software trends data; Operations & Performance software provides spec management,
genealogy, BOM enforcement, OEE and Downtime monitoring; the Wonderware System Platform monitors data levels,
and application templates can help deliver nearly any quality capability; InBatch software collects information on batch
quality and recipe settings; and the list goes on.
• Mobile Solutions – Wonderware mobile solutions feature the industry's leading Mobile Workforce & Decision
Support System. Wonderware IntelaTrac enables the delivery of Best Practices to field workers improving Asset
Management for the leading refiners, chemical manufacturers, and power generators globally.

For more information on Wonderware software solutions and products, visit the Wonderware Web site at
http://www.wonderware.com.
ArchestrA technology
ArchestrA technology, or architecture, helps reduce application engineering effort and deployment, increase efficiency,
provide optimization and standardization, and enable integration of distributed automation systems and applications from
virtually any vendor. Geographically dispersed applications (from a few hundred to one million I/O, and from a single node
to hundreds of stations) can be rapidly and securely implemented.
The ArchestrA architecture leverages advanced software technologies to fill the gap between ERP systems and control
systems. This architecture provides the following:
 Framework which supports common services and a core set of system objects
 Domain Objects which are industry-specific objects
 Object Development Toolkit which enables third parties to create new domain objects customized for specific
needs

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. The ArchestrA Framework supports core services that are required by most of
these different types of supervisory control and manufacturing information systems.
These core services include the following:
 Integrated Development Environment (IDE)
 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
 Reporting and ad-hoc query capability
 Support for industry standards such as OPC and SQL
The ArchestrA architecture consists of the following:
 Configuration and Deployment Related Components that are required for centralized deployment of the
runtime components. These components are installed just like any other Windows application and include the
following:
 Centralized object repository (called Galaxy Repository)
 Integrated Development Environment (IDE)
 Object deployment services (called Bootstrap)
 Runtime Components that are centrally deployed and administered. These components include the following:
 PCs with core infrastructure (called Platforms)
 Key software applications (Engines)
 Objects (Framework Objects) that expose framework related functionality
Wonderware individual software products
Wonderware software solutions offer robust, best-of-breed software components that empower customers to effectively
develop and manage their automation and information applications in continuous, discrete, process, hybrid, and batch
manufacturing environments. All the latest Wonderware software offerings leverage the latest ArchestrA technology and
offer increased functionality and flexibility as well as extensive connectivity.

Wonderware System Platform

Wonderware System Platform provides a single platform for all the SCADA, Supervisory HMI, MES, and EMI software
solutions needs of industrial automation and information personnel. At the center of the Wonderware System Platform is
the “plant model,” which is the logical representation of the physical equipment and processes being controlled and
supervised. Within the System Platform is a high-performance process historian with production history archiving, efficient
data compression, and auto-configuration of historical archiving that helps eliminate duplicate effort, and an industrial Web
information server that dramatically simplifies the organization and delivery of operations information for use across all
functions in an organization.

Wonderware InTouch HMI

Wonderware InTouch software is a human machine interface (HMI) for process visualization and control. It takes
operations management, control, and optimization to a whole new level. The InTouch HMI reputation stands above all the
rest. No other HMI can match InTouch software for industry-leading innovation, architectural integrity, unequaled device
integration and connectivity, uninterrupted software version migration path, and truly legendary ease of use.

Wonderware HMI Reports

Wonderware HMI Reports is an easy-to-use and powerful reporting tool for creating and delivering usable, visually
appealing reports containing real-time process data or information extracted from InTouch HMI, Wonderware Historian,
third-party HMI applications and database systems, or almost any data source that supports OPC, OLE DB, and ODBC
standards. Reports can be generated on-demand or automatically on-event or on a regular schedule. The reports can be
printed or generated as Microsoft Excel, Adobe Acrobat (PDF), and HTML formats and distributed automatically by e-mail,
stored on a network share, or shared over the Internet or intranet through the HMI Reports Web portal.

Wonderware Historian
The Wonderware Historian component of the System Platform is a high-performance, real-time database for historical
information. It combines the power and flexibility of a relational database with the speed and compression of a true process
historian, integrating the office with the factory floor or any industrial operation. The Wonderware Historian is designed to
collect a wide variety of plant data, at full resolution and very high data rates.

Wonderware ActiveFactory
The Wonderware ActiveFactory software provides data-trend analysis, sophisticated numerical-data analysis using
Microsoft Excel, comprehensive data reporting using Microsoft Word, and the capability to publish real-time and historical
plant information to the Web or company intranet site using Wonderware Information Server. Plant knowledge workers
using ActiveFactory information can quickly troubleshoot problems, study potential process inefficiencies, and eliminate
the time-consuming process of locating the data.
Wonderware Information Server
The Wonderware Information Server offers an easy solution for aggregating and presenting plant production and
performance data over the Web or company intranet. Using Wonderware Information Server, large amounts of process
data can be aggregated into highly informative production reports tailored to the information needs of plant personnel.
Content from the Wonderware Information Server can be incorporated into other Web portals, helping to make existing
corporate IT portals more informative and valuable.

Wonderware Operations Software

Wonderware Operations Software provides a scalable and configurable Manufacturing Execution System (MES) designed
to improve operational efficiency, manufacturing responsiveness, and brand integrity. It provides an incremental, low-risk
approach to building Manufacturing Execution systems that can be implemented in steps, from basic MES functionality
including bill of materials, specifications, data collections, and traceability to enhanced capabilities such as inventory
management, certifications, labor, and production steps.

Wonderware Performance Software

Wonderware Performance Software provides a highly scalable and functionally rich solution for collecting, tracking, and
communicating real-time equipment performance information. It helps deliver critical equipment downtime and efficiency
information to operators and decision-makers who can take immediate action to improve plant performance. The software
is highly configurable and leverages the Wonderware System Platform, which offers many benefits as a result of the
underlying ArchestrA technology.

Wonderware QI Analyst
Wonderware QI Analyst Statistical Process Control (SPC) software is an important part of any quality management
program. Performing both online and historical SPC, QI Analyst supports real-time process monitoring and alarms, as well
as historical reports to view process “health” over any period of time. Real-time SPC, analysis, and reporting are equally
easy. By storing process data in the QI Analyst database and linking to external data sources, users can leverage
enterprise-wide SPC to reduce variation, reduce costs of manufacturing, and increase productivity.

Wonderware InBatch Software

Wonderware InBatch flexible batch management software optimizes the management of any batch process. InBatch
software automates recipe management using a graphical procedure environment featuring Sequential Function Charts
(SFC). Consistent with the ISA S88 flexible batching standard, InBatch software offers comprehensive batch execution
and equipment history, material genealogy, stringent security, Web-based reporting, and the ability to facilitate the design
and implementation of systems that are compliant with FDA 21 CFR Part 11 regulations.

Wonderware Equipment Operations Module

Wonderware Equipment Operations Module helps manufacturers capture complete “as-built” records for rapid response
to unforeseen production events such as product recalls. Leveraging the ISA-95 standard, it enables consistent
execution of unit/line operations, improved reliability, and repeatability of equipment setup.
Wonderware Manufacturing Execution Module
Wonderware Manufacturing Execution Module empowers Wonderware customers to define logical manufacturing models
in terms of routes, operations, resources, and bills of materials – as well as their relationship. It enables the operational
execution of production plans with accurate tracking and control of work-in-process (WIP) information related to inventories,
resource utilization, and conformance to specifications.

Wonderware SCADAlarm
SCADAlarm alarm and event-notification software provides a telecommunications link to industrial automation software
systems. It seamlessly integrates with the comprehensive Wonderware product family and has built-in browsers to enable
fast configuration of information from Wonderware System Platform and InTouch HMI software.

Wonderware Toolkits
Wonderware Toolkits provide powerful extensibility to InTouch HMI and System Platform applications by enabling
developers to extend the capabilities of Wonderware products to meet specific system integration needs. The Toolkits
promote adherence to industry standards, provide additional customization and intellectual property protection, and
enhance the ability to interface Wonderware products with other software and hardware.
Wonderware offers the following Toolkits:

Toolkit Enables developers to:

DAServer Toolkit Build custom device integration servers more easily
ArchestrA Object Toolkit Extend the ArchestrA architecture with objects that provide specific application
or device integration functionality
Historian Toolkit Create high-value industrial applications that integrate with data sources from
the System Platform and other data sources
Alarm Toolkit Produce custom distributed alarm providers and consumers
Wizard Toolkit Produce their own Wizards for inclusion in InTouch HMI
Script Toolkit Develop custom InTouch scripts
GRAccess Toolkit Create programmatic access to and interaction with System Platform Galaxy
configuration data
MXAccess Toolkit Create programmatic access to runtime data in a System Platform Galaxy

Wonderware Device Integration Servers

Device Integration Objects (DI Objects) within the Wonderware System Platform provide seamless connectivity to any data
source, and the DAServer Toolkit allows developers to create custom connectivity servers. In collaboration with more than
100 third-party interface developers, Wonderware provides the largest selection of connectivity options to hundreds of
control systems and other hardware devices. Wonderware has also fully embraced the openness of OPC technology,
exposing data via OPC from Wonderware products as an OPC Client and also providing the means to connect to any third
party OPC Server.
Wonderware Enterprise Integration Application
Wonderware offers powerful capabilities to complete the manufacturing supply chain by linking the manufacturing system
to business applications like ERP, PLM, SCM, and LIMS systems. Wonderware Enterprise Integration Application provides
a scalable and configurable solution designed to accommodate even the most complex requirements for tightly aligning
business and manufacturing systems.

Wonderware IntelaTrac
Wonderware IntelaTrac is a suite of configurable software and ruggedized mobile hardware products that provides
workflow management, procedural and general task management capabilities typically focused around plant operations,
maintenance management, and production tracking and compliance applications to mobile field workers.

Wonderware System Platform 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:
• 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:
• ArchestrA IDE
• 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
• Reporting and ad-hoc query capability
• Support for industry standards such as OPC and SQL

The ArchestrA Framework consists of:

 Configuration and Deployment Related Components: which include the centralized object repository (called
Galaxy Repository), ArchestrA 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 application 
(Engines) and objects (Framework Objects) that expose framework related functionality. These components are 
centrally deployed and administered.   
Section 2 – Wonderware System Platform
Section Objectives
• Introduce the concept of ArchestrA and how it relates to the manufacturing environment
• Describe the benefits of migrating to an ArchestrA architectural environment
• Clarify how Object Oriented tag-based products relates to SCADA
• Explain the difference between Object Oriented development process and Tag Based development process
• Explain what a Galaxy is and how it relates to the Galaxy Database and the Galaxy Repository
• Demonstrate how a Galaxy is created

This section provides an overview of the Wonderware System Platform and how critical the architecture of
ArchestrA is to plant automation. An overview of the differences between Object-oriented and traditional Tag
based HMI and SCADA products is provided, as well as how these differences apply to Wonderware System
Platform applications. This section will also provide a description of what a Galaxy is, how it relates to the
Galaxy Database and the Galaxy Repository and how a Galaxy is created.

System Platform
The Wonderware System Platform provides a single platform for all the SCADA, Supervisory HMI, and
Production and Performance Management needs of industrial automation and information personnel. It
provides a common and strategic industrial application services platform on top of virtually any existing system,
and is built upon the industry-standards based, ArchestrA real-time SOA technology.
The Wonderware System Platform is designed to make it easier for manufacturers to adjust to the
ever-changing needs of customers and the overall market. Its diverse functionality extends Wonderware
customers’ software investments and encourages flexibility in application development.
It supports consistent and reliable operations across industrial operations and manufacturing facilities as well as
promotes sustainable production and operational performance improvements.
The Wonderware System Platform contains an integral core set of capabilities and services to support
sustainable production and operations performance improvement via a comprehensive set of six capability
areas:
• Industrial domain services
• Software and device connectivity services
• Information and data management services
• Information-delivery and visualization services
• Application development services
• System management and extensibility services
Industrial Domain Services
The Wonderware System Platform offers industrial domain services that are not provided by commercial operating
systems or generic IT products. It provides a powerful infrastructure that enables Wonderware customers to leverage
lower-cost commercial PC hardware and operating systems in industrial applications.
Application functions are quickly customized. Whether you have no knowledge of computer programming or consider
yourself an expert software engineer, the System Platform can empower you to conveniently interact with process systems
from any remote location. The result is a reduction of personnel costs and improved response times because the software
continuously monitors and deploys messages, 24/7.
Industrial Domain Services provide:
• Real-time, peer-to-peer communications and messaging, enabling instant responses
• High computing availability and redundancy for critical applications
• Centralized alarm- and event-monitoring for operational conditions
• Data-level security to protect plant equipment
• Audit logging and extended security protection for developers and system-maintenance personnel
• Pager, mobile phone, PA system and e-mail alerts for unattended operational monitoring
• A single global Namespace to access data elements anywhere, without tag limitations
• Plant information and supervisory functions to script special behavior and responses
• Support for slow and/or intermittent data networks

Software and Device Connectivity Services

The Wonderware System Platform enables cost-effective communication to virtually any plant information source.
Unifying diverse systems can improve operations and information management. Integrating business and
manufacturing activities can also increase plant profitability.
Software and Device Connectivity Services provide:
• Integration of manufacturing and business systems
• Easy importing and migration of legacy systems and external system configurations
• Conversion of non-structured device communication models into structured systems to increase the
maintainability of applications and systems
• Connectors and communication servers for control devices, applications and systems including:
 Automation devices, control systems and HMIs
 Historians and relational databases
 Quality and maintenance systems
 Enterprise resource management (ERP) and business systems
 Manufacturing execution systems (MES)
Information and Data Management Services
Furthermore, the Wonderware System Platform facilitates the management of all real-time and historical
information — including data transformation and storage. This information management capability can increase
a plant’s profitability because it enables immediate access to key performance indicators (KPIs); SPC,
downtime and OEE information; live data calculations; event and alarm notifications; and historical data.
More effective information and content management can also improve production management and enhance
plant performance. For instance, the reliable information that the Wonderware System Platform enables not
only data visualization, but actionable control. The platform also enhances batch management, real-time
production monitoring and access to MES data.
Information and Data Management Services provide:
• Content management tools
• Streaming real-time data (available to all authorized users)
• A high-performance process historian and production database that offer:
 A production history archive for a single production line, an entire facility or the complete enterprise
 Data compression, which reduces disk storage and makes more data available online
 An historical archive that’s auto-configured, eliminating duplicate work
• Off-line and late data handling for:
 Manual data
 Labs and quality systems
 Remote terminal unit (RTU) environments
• Correlation of events and alarms with production history
• Data transformation and normalization
• Data Buffering and Store & Forward features
• Simple and fast configuration with powerful process event monitoring
Information-Delivery and Visualization Services
Delivering the right information, to the right user, at the right time, and in the form in which they expect it is a key service
provided by the Wonderware System Platform. Wonderware customers can concurrently visualize manufacturing and
business information, and dynamically implement changes to reach their business objectives.
Quickly access real-time and historical information using the open and easy-to-use HMI solution that seamlessly integrates
with legacy and new plant systems. Proactively enhance your plants profitability by taking action on information in real time,
obtaining real-time and historical data from beyond the boundaries of the secured process network. Create queries and run
reports, even if you have no SQL database knowledge. The Wonderware System Platform can even help you achieve
regulatory compliance with simple and accurate automated reports.

Capabilities
• Multiple client interfaces [i.e., Thick, Terminal Services Edition (TSE) or Web Client]
• Visualization and HMI
 Expansive graphical user interface (GUI)
 Access-level Windows authentication and data security, as well as enhanced password encryption
 Comprehensive alarm troubleshooting tools
• Information Analysis and Reporting
 Integration with trending tools and Microsoft Office products
 Production, SPC, downtime and batch analysis tools
• Automatic data retrieval calculations - reduction and aggregate methods
• Open SQL access, enabling simplified data queries with powerful retrieval modes
• Secure access across firewalls
• Multi-language client support
Application Development Services
The Wonderware System Platform and its underlying ArchestrA technology provide easy and intuitive
development of modular industrial software solutions, which can be easily changed to meet Wonderware
customers’ future needs. As a result, you can drive standards by developing applications once and using them
everywhere. The result is a decrease in the amount of time and costs associated with creating, modifying,
deploying, maintaining and standardizing software applications.
Application Development Services provide:
• Flexible, comprehensive software development capabilities for HMI and/or MES applications
• Advanced ArchestrA technology, which facilitates the assembly of applications that are component-based and
generated from standard templates
• SmartSymbol technology, enabling the creation of re-usable graphics
• Different development views, which show:
 How the application is related to the facility or plant
 How the application is distributed across the network
 Parent-child relationships for templates and runtime components
• Multi-Developer Environment for concurrent development
• Modeling -Applications can be structured based on a plant model; are self-documenting; and offer common
security, validation and audit trails
• Unification with Microsoft products including:
 Microsoft Windows operating systems
 The Visual Studio development system
 SQL Server, BizTalk server
 SharePoint services
 Microsoft Office
 Internet Explorer internet browser
System Management and Extensibility Services
Furthermore, the Wonderware System Platform facilitates the easy management, expansion and modification of
applications or the host computing architecture. These services provide a range of architectural choices, both during the
initial system design phase and throughout the lifetime of an installed system.
Leverage the flexible and scalable ArchestrA software architecture for small and large systems — systems that can be
easily expanded to meet future requirements. Improve system troubleshooting. Leverage Wonderware’s technological
evolution and increased protection for operating systems and databases. Decrease lifecycle costs for plant IT solutions.
Change and expand your system as a whole without disruption.
System Management and Extensibility Services provide:
• The ability to re-architect systems at any time to support different system topologies (i.e., Single Node,
Client/Server, Peer-to-Peer or Web-centric
• Easy redistribution of server load
• Remote application installation and administration
• An online configuration database that centrally maintains software
• Remote change propagation
• Centralized computer diagnostics and distributed PC network management

In essence, the Wonderware System Platform facilitates consistent and reliable operations across manufacturing and
industrial operations to protect brand integrity. It empowers Wonderware customers to extend their systems in virtually any
direction to meet their current and future needs.

ArchestrA
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 today’s global business spaces. Again, as these markets grow ever more economically
efficient, the choice for manufacturers is between agility and finality.
That’s 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.
Unfortunately, even today, in most plants these systems operate independently. This hinders a plant manager’s
ability to synchronize and control production and business processes in a real-time 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 ever-increasing 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 manager’s
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 plant’s 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.

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:
 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 yesterday’s automation and information systems are beginning to show
their age, failing to offer the agility or rapid response that today’s producers require. Acting as a massive anchor,
they actually impede the organization’s 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
Today’s 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. Today’s 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.
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:
• 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 plant’s 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
company’s process. Incorporating ArchestrA will considerably reduce the cost and time involved in executing strategic
change.

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:
• 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.
Scalability
Wonderware 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.
Wonderware 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.

Object Oriented vs. Tag Based Supervisory Control

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 Propagated 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. 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:
• Alarm Monitoring
• Animation Scripts
• Security Scripts
• Supervisory Scripts
• Historical data storage
• Integration with other applications and Databases
• 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.

Using object-oriented tools in manufacturing applications

Manufacturing applications typically have a lot of common components. These include common types of:
• 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 object-oriented 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:
• 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

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 tag-based 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
Wonderware Application Server and the ArchestrA 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 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.
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 ArchestrA 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 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 ArchestrA 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 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.
What is a Galaxy?
It’s important to understand what a Galaxy is before one is created. A Galaxy is the entire application, the complete
ArchestrA system consisting of a single logical name space and a collection of WinPlatforms, AppEngines and objects.
One or more networked PC’s 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 ArchestrA IDE session requires connection to a specified Galaxy. In other words, the ArchestrA IDE cannot
be started in a Galaxy-neutral state. When you attempt to start the ArchestrA IDE, the Connect to Galaxy dialog
box is displayed.

This dialog box is comprised of three groups of options:

• 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

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 ArchestrA 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). When creating a new Galaxy, you
must select the appropriate Galaxy type:
Default Galaxy: Creates a Galaxy that includes all objects needed for a System Platform application. It also creates a
backup file (.cab) at the end of the process and makes it available to this list.
Base_Application_Server.cab: Same as Default Galaxy, but uses the backup file (.cab) to create the galaxy. It does
not creates a backup at the end, making the process faster.
Base_InTouch.cab: Creates a Galaxy that includes only the object needed for tag-based Managed InTouch
applications.
Reactor_Demo_Application_Server.cab: Creates a Galaxy with the Reactor Demo based on a System Platform
application.
Reactor_Demo_InTouch.cab: Creates a Galaxy with the Reactor Demo based on a tag-based Managed InTouch
application.
If you previously created one Galaxy on the GR node shown, the Galaxy’s name is automatically shown. Click
Connect to start the ArchestrA 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 ArchestrA IDE and to connect to that Galaxy.
Lab 1 – Creating a Galaxy
Introduction
This lab illustrates the steps necessary to create a Galaxy and connect to it with the ArchestrA IDE.
Throughout this class you will use this Galaxy to develop a sample application.

Objectives
Upon completion of this lab you will be able to:
• Create a Galaxy
• Use the ArchestrA IDE to connect to your Galaxy

Summary Lab Instructions

Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Create and Connect to a new Galaxy

a. Create a new Galaxy named TrainingGalaxy.
b. Connect to TrainingGalaxy.

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Create a Galaxy
1. Start the ArchestrA IDE by selecting Start / All Programs / Wonderware / ArchestrA IDE. This will display the
Connect To Galaxy dialog box.
The GR node name field will reflect the name of the local computer.
The Galaxy name drop-down list is initially empty since there are no Galaxies created in this node.

2. Click the New Galaxy button to create a new Galaxy.

3. The New Galaxy dialog box is displayed.

4. Enter TrainingGalaxy in the Galaxy name field.
5. Verify Base_Application_Server.cab is selected in the Galaxy Type field.
6. Click the Create button to continue.

 
At the Connect To Galaxy dialog box the name of the newly created Galaxy, TrainingGalaxy, is displayed in the Galaxy 
name drop‐down list.   

8. Click the Connect button.

This closes the Connect To Galaxy dialog box and displays the ArchestrA IDE.
Section 3 – The ArchestrA IDE
Section Objectives
• Discuss ArchestrA IDE
• Introduce the Template Toolbox and Application Views
• Discuss the object Check-in/Check-out process.

This section provides an overview of the ArchestrA IDE, the Template Toolbox and Application Views and the object
Check-in/Check-out process.

The ArchestrA IDE User Interface

The ArchestrA 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 ArchestrA 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
ArchestrA IDEs.
The ArchestrA IDE can be installed on any PC that has ArchestrA’s Bootstrap software installed.
Key Functions of the ArchestrA 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.

• 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 object’s configuration errors/warnings
 Upload runtime changes to Galaxy database
• IDE Configuration
 Set user preferences
 Create a Tool Box

As the main aspects of the ArchestrA IDE Main View (for example, Menu options, Toolbars, Template Toolbar and
Application Views, etc.) are identified and discussed, they are elaborated on in greater detail as to how these Key
Functions can be used
The ArchestrA IDE User Interface Main View

The Main Window of the ArchestrA IDE is composed of the following components:
• Title bar
• Menu bar
• Toolbar
• Template Toolbox
• Application Views
• Object Editor Area
• Operations View
• Status bar

When you first log in to the ArchestrA 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.
The Title Bar displays the name of the utility. The other elements of the Main Window are described on the next
page.
Menu Bar
The ArchestrA 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 object’s 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.
 Export – For exporting Automation Objects, All Automation Objects, Script Function Libraries, and a Galaxy
Dump.
Save – For saving the currently-opened object’s 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 object’s 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 ArchestrA IDE, this command opens the ArchestrA 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 ArchestrA 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 ArchestrA IDE settings. This menu includes the following commands:

 Model – For bringing focus to the Model view of the Main Window.   
 Deployment – For bringing focus to the Deployment view of the Main Window.
 Derivation – For bringing focus to the Derivation view of the Main Window.
 Template Toolbox – For bringing focus to the Template Toolbox of the Main Window.
 Graphic Toolbox – For bringing focus to the Graphic Toolbox 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.
 Synchronize Views – For specifying that a selected object stay selected as you move through the views.
 Reset Layout – For resetting everything back to its original default locations.
 Toolbars – For toggling on/off the Toolbar of the Main Window.
 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 object’s 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” for additional information regarding this feature.

 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.
 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 object’s 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 object’s
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 object’s 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 ArchestrA IDE Help menu includes the following commands:

 Help Topics – Standard Help command, used for opening the ArchestrA IDE’s 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.

 
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

 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 object’s 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 object’s 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 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 object’s 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 object’s 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 object’s
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 object’s 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 ArchestrA 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 ArchestrA 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.
Toolbar
The ArchestrA 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 object’s 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 object’s 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 object’s change log. Changes you made to
the object when it was checked out are backed out. An error message is displayed when the object’s configuration editor is
open.

Properties – For accessing the properties of the object in focus.

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:
 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 ArchestrA IDE is first started. Subsequent ArchestrA IDE sessions
retain the user’s last setting.

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:

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.
The top of the tree is the GalaxyObject, This is 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
Note: More detail of the Deployment View is discussed in Module 2, Section 2, “The Deployment Model”.

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 AppEngine. Also, an AppEngine 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.
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 contains all templates and instances. The tree is displayed in alphabetical order at each level within the tree.
The base templates created within the ApplicationObject Toolkit is on the left, as all other templates and instances
are derived from these an extra level will be added to the tree.
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.
Graphic Toolbox
The Graphic Toolbox contains the global ArchestrA graphics that can be used in the Galaxy. It lets you organize your
symbols in special folders, called Toolsets. The Graphics Toolbox shows a treeview of toolsets which contains ArchestrA
Symbols and Client Controls.
It allows you to define graphics as a standard that you can re-use, such as a generic valve symbol. Symbols in the Graphic
Toolbox can later be used by Automation templates and instances. You can store ArchestrA Symbols here, if you only
want to use them in InTouch and not in any other Automation object content.
An example of a Graphic Toolbox is as follows:

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:
 deployment status (for instances only)
 configuration status (for templates and instances)
 redundancy status (for instances only).
Deployment status indicators include:

Configuration status indicators include:

Redundancy status indicators include:

InTouch status indicator:

Checking Out/Checking In Objects
Users of the ArchestrA 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 ArchestrA 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 appears 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 object’s revision history. A check mark is shown next to an object’s icon in the ArchestrA IDE.
To check out unreserved objects
a. Select them in the Template Toolbox or Application Views.
b. On the Object menu, click Check Out.

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 object’s 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.

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 object’s
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.
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:
 Comment: Use this box to enter your comments about configuration changes made to the object.
 Don’t 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 ArchestrA IDE commands related to the concept of check out and check in include:
 Undo Check Out: Use this command to change an object’s 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 object’s
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 object’s
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 object’s editor is
currently open, the override function fails.
Object Viewer
Note: The Object Viewer is explained in more detail when the Runtime Environment is discussed in Module 2, Section 3,
“The Runtime Environment”.

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.

Determining Galaxy Status

You can see an overview of the condition of your Galaxy before you deploy. This lets you know if you have objects that
are in warning or error status.
To determine the status of a Galaxy
a. Connect to the Galaxy.
b. On the Galaxy menu, click Galaxy Status. The Galaxy Status dialog box appears:

You see information about total instances, total templates, deployed instances with changes, undeployed instances with
changes, objects that have an error or warning state, objects that are checked out, and object you have checked out.
c. Click OK.
Section 4 – Automation Objects
Section Objectives
• Introduce the various objects in the ArchestrA IDE
• Identify when and how they are used
• Explain how to create and configure instances of objects
• Introduce and explain the hosting and containment relationships of objects

This section provides an explanation of the various types of objects utilized in the ArchestrA IDE and an
overview of when and how they are used. Additionally, it describes how to create and configure instances of
objects and the hosting and containment relationships of objects.

Objects

Automation Objects
An automation object allows the encapsulation of all configuration elements of each piece of your system, such
as I/O definitions, logic (scripting), history configuration, alarm/event configuration, security/access control and
graphics. This self-contained approach dramatically reduces the engineering time associated with the initial
creation and maintenance of objects. By keeping all object configuration tightly related and contained within
the object itself, there is no need to use multiple editors to make sure that the alarming, I/O definitions, scripting,
history, and security are consistent for an object.
There are Template objects, and Instance objects:
 Template objects: these are high-level definitions of the objects: equipment, devices, constructs or simply system
parts of the Galaxy
 Instance objects: these are the runtime objects and represent the specific items in the environment, like
processes, valves, holding tanks, and so on

There are Domain objects and System objects:

 Domain objects:
 Application objects: represent the physical equipment or logical constructs in the Galaxy
 Device Integration objects: represent the communication with the external devices
 System objects: represent the parts of a Galaxy and not the domain they are monitoring and/or controlling

Attributes and Attribute References

Every piece of configuration and data available within an object is called an attribute. Interaction with objects,
in configuration or runtime, is done through the attributes of the specific object.
Attribute references refer to data within an object's attributes; it consists of an object's reference string plus an
attribute's reference string, separated by a dot ("."):
ObjectName.AttributeName

An object reference cannot exceed 32 characters (including the $ character used in template names) and
must contain at least one non-numeric character.
You should avoid assigning objects and attributes the same names because this may result in an attribute reference can
refer to two different things. For example, if you have two objects, A1 and B2, where A1 is the container of B2, and object
A1 has an attribute named B2, the reference string A1.B2 could either refer to the B2 attribute within A1, or the B2 object
contained in A1.

Object Categories
Within the Template Toolbox there are three main categories of objects. These are:
 Application objects
 AnalogDevice
 Boolean
 DiscreteDevice
 Double
 FieldReference
 Float
 Integer
 Sequencer
 SQLData
 String
 Switch
 UserDefined
 Device Integration objects
 DDESuiteLinkClient
 InTouchProxy
 OPCClient
 RedundantDIObject
 System objects
 AppEngine
 Area
 InTouchViewApp
 ViewEngine
 WinPlatform

 
Application Objects

Application Objects are used to create devices in your Galaxy. These devices represent real objects in your
environment.
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:
• 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:
 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 negative-slope 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.
 Initial Control 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.

Boolean Object
The Boolean object is derived from the FieldReference object and is used for evaluations that result in either of the
truth values of ‘true’ of ‘false’, often coded 1 and 0 respectively.
 
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 (for
example 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:
 Input and Output states of the DiscreteDevice object are totally independent of each other and can be configured
as required by the user’s 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).

Double Object
The Double object is derived from the FieldReference object.
FieldReference Object
The FieldReference 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:   

• ReadOnly – Input object

• ReadWrite – Output object with scanned Feedback
• WriteOnly – Output

This object is very simple; it only allows the value to be historized.

Float Object
The Float object is derived from the FieldReference object.
Integer Object
The Integer object is derived from the FieldReference object.
Sequencer Object
The Sequencer object allows you to configure, execute, and manipulate a sequence of operations associated
with ArchestrA attributes within a Wonderware Application Server application.
You can use it to automate:
• repetitive manufacturing procedures with a finite number of steps
• supervisory processes with a finite number of steps

 
SQLData
The SQLData Object is an ArchestrA application object that can be used to store data to, and retrieve data from a SQL
Server database. The SQLData Object provides the means to map data in a SQL database to attributes in a Galaxy.
String Object
The String object is derived from the FieldReference object.
Switch Object
The Switch 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:
• 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:
 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 ArchestrA 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.

 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.

 
Device Integration Objects

A DeviceIntegration object (DIObjects) is an AutomationObject that represents 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.
A more detailed discussion of the Device Integration Objects will take place later in this course in Module 2, “Application
Infrastructure”, Section 4, “Connecting to the Field”.

System Objects

System objects are used to define system instances.

AppEngine Object
The AppEngine Object must have a Platform on which to run. The key functionality of this object includes:
• hosting application objects, device integration objects and areas
• containing the logic to setup and initialize objects, when they’re deployed.
• containing the logic to remove objects from the engine, when they’re 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.
This object is very simple; it only allows the value of three attributes to be historized:
• Active alarm counter
• Unacknowledged alarm counter
• Disabled (or silenced) alarm counter

InTouchViewApp Object
The InTouchViewApp object represents an InTouch for System Platform application. The InTouchVewApp object
manages the check-in, check-out, and deployment of an InTouch application.
When you create an InTouchViewApp for a new InTouch application, WindowMaker is started by the ArchestrA IDE. You
then create the application the same way you would if WindowMaker had been started from the InTouch Application
Manager.
ViewEngine Object
The ViewEngine object is used to host InTouchViewApp objects. The ViewEngine object supports common engine
features such as deployment, undeployment, startup and shutdown. One ViewEngine object can handle several
InTouchViewApp objects.
 
WinPlatform Object
The WinPlatform platform object is a key base object. The key functionality of this object includes:
 Calculating various statistics related to the node it’s deployed to. These statistics are published in attributes.
 Monitoring various statistics related to the node it’s 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 engine’s restart attribute) restart the engine.

There is a special instance of the platform object called the galaxy platform. This platform instance:
 Exists on the galaxy node.
 Is used by message exchange to bind unresolved attribute references

Templates and Instances

Templates
Templates are high-level definitions of the devices in your environment. Templates are like a cookie cutter from which
you can make many identical cookies.
You define a template for an object, such as a valve, one time and then use that template when you need to define another
instance of that item. Template names have a dollar sign ($) as the first character of their name.
A template can specify application logic, alarms, security, and historical data for an object.
A template can also define an area of your environment. You can extend and customize a template by adding User
Defined Attributes (UDAs), scripts, or extensions to meet the specific needs of your environment. Objects inherit
attributes from their parents.
Wonderware Application Server comes with predefined templates, called base templates. You cannot change these
templates. All templates you create are derived from base templates.
You can also nest templates, or contain them. Contained templates consist of nested object templates that represent
complex devices consisting of smaller, simpler devices, including valves. A reactor is a good candidate of containment.
Templates exist only in the development environment.
Using the Diaphragm valve template, you can quickly create an Diaphragm valve instance when you need another
Diaphragm valve in your application.

Creating a Template
Right-click on the appropriate type of object, and select New / Derived Template. For example, use the $UserDefined
object to create a $Mixer template as a container for the mixer’s various components (agitator, inlet valves, pumps, and
so on).

Instances
Instances are the run-time objects created from templates in Wonderware Application Server. Instances are the specific
things in your environment like processes, valves, conveyer belts, holding tanks, and sensors. Instances can get
information from sensors on the real-world device or from application logic in Wonderware Application Server. Instances
exist during run time.
In your environment, you may have a few instances or several thousand. Many of these instances may be similar or
identical, such as valves or holding tanks. Creating a new valve object from scratch when you have several thousand
identical valves is time-consuming. That's where templates come in.

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 - Method 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
Once the instance has been created it displays as follows:

It can now be renamed using then appropriate naming convention.

Creating an Instance - Method 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.
Section 5 – System Requirements, Licensing and Support
Section Objectives
• Describe the necessary system requirements for a successful installation
• Discuss Licensing requirements
• Discuss Support services

This section provides a detailed explanation of the system requirements necessary for Wonderware
System Platform, discusses Licensing details and covers Support services.

System Requirements for Wonderware Application Server/Galaxy Repository

Minimum Hardware Requirements

The following list shows the minimum computer hardware requirements to host Application Server version 3.1
components.
 Galaxy Repository (GR) node
 2 gigahertz (GHz) or faster dual core processor, or a 3 GHz or faster single core processor. A dual core processor
is strongly recommended for optimal performance
 Minimum of 2 gigabytes (GB) RAM. For Galaxies with more than 500 objects, 4 GB RAM is recommended in the
GR node
 30 GB of available disk space
 Super VGA (1024 x 768) or higher resolution video adapter and monitor.
 Network interface card
 CD-ROM or DVD drive
 Keyboard
 Mouse or a compatible pointing device

Development and Application nodes

 2 GHz or faster processor
 Minimum 1 gigabyte (GB) RAM. For improved performance 4 GB RAM is strongly recommended
 30 GB of available disk space
 Super VGA (1024 x 768) or higher resolution video adapter and monitor
 Network interface card
 CD-ROM or DVD drive
 Keyboard
 Mouse or compatible pointing device

The hardware requirements for using the Alarm Client and Trend Client at run time are the same as for the
InTouch HMI version 10.1 run time.
The Windows Vista operating system imposes hardware requirements that may exceed the minimum
requirements for Application Server version 3.1. If you intend to install Application Server
3.1 on a computer running Windows Vista, see the following Microsoft web site for hardware requirements:
www.microsoft.com/windows/products/windowsvista/editions/systemrequirements.mspx
Software Requirements
This section describes the operating system, database, and other software requirements to install Application Server
version 3.1.
 Operating Systems
 SQL Server Database Requirements
 Other Software Requirements

Operating Systems
 Windows Server 2003 Standard Edition SP2 is the recommended operating system for computers running server
components.
 Windows XP SP3 is the supported XP version for this release.
 Windows XP Professional SP3 is the recommended operating system for computers running client components.

The following table lists the supported operating systems that can be installed on computers running as Application
Server development, application, and GR nodes. Development and application nodes are considered to be clients of
the server GR node.

Operating Systems Wonderware Application Server Components

ArchestrA IDE ArchestrA Run Galaxy
(Development Time Repository
Node) (Application (GR Node)
Node)
Windows Vista Business (See Vista Restrictions) x x x
Windows Vista Business SP1 (See Vista Restrictions) x x x
Windows Vista Enterprise (See Vista Restrictions) x x x
Windows Vista Enterprise SP1 (See Vista Restrictions) x x x
Windows Vista Ultimate (See Vista Restrictions) x x x
Windows Vista Ultimate SP1 (See Vista Restrictions) x x x
Windows Server 2003 Standard Edition SP2 x x x
Windows Server 2003 Enterprise Edition SP2 x x x
Windows Server 2003 Standard Edition R2 SP2 x x x
Windows Server 2003 Enterprise Edition R2 SP2 x x x
Windows XP Professional SP3. See Note 2. x x See Note 2
Windows XP Tablet x
 
Notes:
1 The Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server operating systems
are not supported for Application Server version 3.1. An error occurs if you attempt to install or upgrade Application Server
version 3.1 on a computer running any edition of the Windows 2000 operating system.
2 The computer designated as the Galaxy Repository node can run on Windows XP Pro only as a single-node
configuration of Application Server. Windows Server 2003 is the recommended operating system for the GR node.
3 You can run Application Server only on computers running a 32-bit operating system. You cannot run Application
Server on a computer running a 64-bit operating system.
4 The Bootstrap, IDE, and Galaxy Repository are supported by the following language versions of Microsoft
operating systems: English, Japanese, Chinese, German, and French. The Galaxy Repository is also supported by the
English, Japanese, Chinese, German, and French versions of Microsoft SQL Server 2005.
SQL Server Database Requirements
Microsoft SQL Server 2005 with SP2 is the only database supported by Application Server version
3.1. You must use the Standard or Enterprise editions of SQL Server 2005. Neither the Compact, Express, nor
the Workgroup editions of SQL Server 2005 can be used as the Galaxy Repository.
 SQL Server 2005 SP2 must be installed on the computer designated as the ArchestrA Galaxy Repository node
prior to installing Application Server.
 You also cannot install and use Application Server on a computer that has both Microsoft SQL Server 2000 and
Microsoft SQL Server 2005 installed.
 The Galaxy Repository locks the SQL Server maximum memory usage to 65% of the computer's physical
memory.
 TCP/IP must be enabled on the computer hosting a SQL Server 2005 database. The TCP/ IP protocol setting can
be verified from the SQL Server 2005 Network Configuration under SQL Server Configuration Manager.
 The Microsoft SQL Server 2005 login for BUILTIN\Administrators group must be present and enabled.

Other Software Requirements

The following list describes other third-party software required for Application Server version 3.1.

Microsoft .NET Framework 3.5

 Microsoft .NET Framework 3.5 must be installed on every computer that hosts an Application Server version 3.1
component. The Application Server installation program halts if .NET Framework 3.5 is not installed on the target
computer. A dialog box appears requesting that you install .NET Framework 3.5. If you click Install Prerequisites,
the installation program automatically installs .NET Framework 3.5.
Microsoft Visual Studio 2005
 Microsoft Visual Studio 2005 is required only by the MXAccess and GRAccess toolkits distributed with Application
Server.

Alarm Client and Trend Client Requirements

The software requirements for using the Alarm Client and Trend Client at run time are the same as for the InTouch HMI
version 10.1 run time. If you want to trend data from the Wonderware Historian (formally known as IndustrialSQL Server),
version 9.0 or later is required.
The Trend Client is compatible with the following Wonderware products:
 InTouch 10.1
 Wonderware Application Server 3.1
 Wonderware Historian 9.0
 ActiveFactory 9.2
 QI Analyst 8.1

Using Application Server with Windows Vista

This section describes specific restrictions when using the Windows Vista operating system with Application Server and
how to configure multiple Network Information Cards on a computer running Windows Vista.
Vista Restrictions
 Application Server version 3.1 can run under Windows Vista SP1, Windows Vista Enterprise SP1, Windows Vista
Business SP1, or Windows Vista Ultimate SP1. The Windows Vista Home Basic and Home Premium editions are
not supported. The Windows Vista Business Edition is recommended for use with Application Server.
 You must log on as a Windows Vista administrator to run Application Server version 3.1. You cannot run
Application Server as a Windows Vista standard user or power user.
 The Windows Vista User Account Control (UAC) must be disabled when running Application Server. Refer to
Microsoft Windows Vista documentation for instructions to disable UAC.
 When you disable Windows Vista UAC, you must restart the computer before attempting to install the ArchestrA
IDE or Wonderware Application Server. A Galaxy connection error occurs if you attempt to install the ArchestrA
IDE or Wonderware Application Server and you did not restart the computer after you disabled the UAC.
 Windows Vista does not support a traditional Application Server single-node configuration that includes
Wonderware Historian (formerly IndustrialSQL Server).
 The Galaxy Repository is supported on Vista only for a single-node configuration of Application Server. For
multiple-node Galaxies, Windows Server 2003 is the recommended operating system for the Galaxy Repository
node.
 If the computer that hosts the Galaxy Repository runs on Windows Vista, SP2 must be applied to SQL Server 2005
installed on the same computer.
 A computer running on Vista cannot be configured to be an alarm provider and also have InTouch WindowViewer
on the same computer configured to generate alarms. Only one of the two will function properly as an alarm
provider.
 Windows Vista does not support NetDDE. ArchestrA Symbols that use the client layer when accessing InTouch
tags, and appear as a third-party client trying to access WindowViewer as a data server. As a result, ArchestrA
symbols cannot communicate with InTouch tags. Windows Server 2003 and Windows XP Pro still support
NetDDE.
 Windows Vista security prevents started Windows services from interacting with desktop objects. When
Application Server 3.1 is installed on a computer running Vista, scripts do not run correctly if they include the
InTouch ActivateApp() and SendKeys() functions. Windows Vista prevents these functions from interacting with
desktop objects to start Windows programs or send keystrokes to these programs.

Using Multiple Network Interface Cards with Windows Vista

If you are using multiple network interface cards (NICs), you must configure certain settings for the firewall or else a remote
Vista node cannot connect to the Galaxy Repository node.
A connection in Vista is a term used to define a network interface card (NIC), its settings and the settings of whatever the
NIC is connected to. Under certain circumstances, the connection on your computer can change if, for example, the IP
address on the computer to which you are connected changes. Your computer's connection can be affected by external
factors. During computer startup, and each time a connection changes, Vista goes through an "Identifying" process to
determine which profile should be assigned to the connection.
A profile is a collection of firewall settings that can be applied to a connection. There are three profiles currently defined
in Vista: "Domain", "Public" and "Private".
 The Domain profile is assigned automatically to a connection if a domain controller for the domain to which the
computer is a member is found on the connection.
 The Public profile is designed to keep the computer from being visible to other computers on the network. Network
discovery is turned off for the Public profile.
 The Private profile is used for a more trusted environment. Network discovery is turned on for a Private profile. 
Firewall exceptions and rules can be created on any or all of these profiles.   

This is important because the OS Configuration utility and the Vista Firewall utility apply their firewall
exceptions to the Domain and Private profiles only.
As previously noted, you can specify which profile you want assigned to a connection as long as that connection
is not a Domain connection. This is done through the "Network and Sharing Center". Click on the Network icon
in the right side of the task bar and then click on one of the networks that is shown. You can change a
connection from a Public profile to a Private profile. The firewall calls these settings "Profiles" but the network
calls them "Location types."
On computers using dual NICs, the first NIC is normally connected to the domain and is assigned the Domain
profile automatically. The second NIC is typically assigned the Public profile.
The first issue is that your entire computer (all connections) is restricted to the most restrictive of the profiles
assigned to any connection. So if the second connection was assigned a profile of Public, none of the firewall
exceptions set by the OS Configuration or Vista Firewall utilities will be allowed. The exceptions were set for
Domain and Private only, not Public. You must set the second connection to the Private profile for any of the
firewall exceptions to work.
The second issue is that it appears that a restart of your computer, or even a restart of a computer to which you
are connected, can change your connection back to the Public profile. Once again the firewall exceptions will
not be effective. You'll have to change the connection back to the Private profile after each restart or a restart of
the connected computer.
To avoid these NIC issues and prevent the "Identifying" process from taking place on a connection and
changing the assigned profile, certain items must be present in the definition of the connection. Follow the rules
below:
1. If you have only one NIC, no action is required. The profiles and firewall rules are automatic.
2. If you have two NICs follow the actions below:
 If the second NIC is not physically connected to anything (that means no wire in it), no action is required. The
profiles and firewall rules are automatic.
 If the second NIC is connected, it MUST be configured. Follow the rules for configuring a normal redundancy setup.
Vista will identify this NIC and assign it a Private profile. If the NIC is not configured, Vista will assign a profile of
Public to this NIC and cause all of the Wonderware product firewall exceptions to be deactivated on all NICs. For
the NIC to be configured properly, give it an IP address, sub net mask and gateway address. The gateway address
can be the same as the IP address. Usually these addresses will be the internal, non-routable addresses like
192.168.0.x or the 10.x.x.x range.
 If you have more than two NICs, make sure all connected NICs are configured with an IP address and default
gateway address and have been assigned a profile of private.
Wonderware System Platform Licensing

Licensing To calculate the licenses needed to implement an application based on the Wonderware System Platform, it
is necessary that you understand and gather the following information:
Application Server IO Count Number of I/O points accessed by the Galaxy.
Application Server Platform Count Number of dedicated Application Object Server nodes in the
application.
Historian Server Count Number of Historian Server nodes in the application.
Information Server and Clients Count Number of Information Server nodes in the application and
number of nodes that are going to access the servers
remotely.
Device Integration Server Count Number of Device Integration Server nodes in the
application.
InTouch for System Platform Count Number of visualization nodes required in the application.
Number of dedicated ActiveFactory nodes in the
ActiveFactory Count
application.
Development Studio Count Number of development workstations in the application.
 

Wonderware System Platform

The Wonderware System Platform is licensed as a single product that includes the following individual features:
• 1 Application Server license sized by IO-count
• 1 Historian Server Standard Edition license sized by Tag-count
• 1 Information Server license
• 1 Information Server Advanced Client license
• 1 Device Integration Server license
• n Application Server Platform licenses (where n is 2, 3 or 4) for the purpose of hosting:
• an Application Object Server
• the Historian Server
• the Device Integration Server
• the Information Server

Note: Note: An Application Server Platform for a dedicated Galaxy Repository node is not included.

The Wonderware System Platform license is available in different sizes, each one offered as a unique combination of the
following:
• Application Server IO-count
• Historian Server Tag-count
• the number of Application Server Platforms included
Wonderware System Platform Options licenses, listed below, are added to this license as needed,
depending on the size of the system and requirements:
• additional Historian Servers with Platform available at different Tag-counts
• additional Information Servers with Platform
• additional Device Integration Servers
• additional Application Server Platforms

Wonderware Clients
In addition to the Wonderware System Platform, one or more of the following Wonderware Clients are
usually required:
• InTouch for System Platform (also available as Terminal Services Edition if needed)
• Information Server Client
• ActiveFactory

The InTouch for System Platform license includes an Application Server Platform and is available in
different flavors, as follows:
• InTouch for System Platform with Trend/Analysis*
• InTouch for System Platform without Trend/Analysis*
• InTouch for System Platform Read-only with Trend/Analysis*

* Trend/Analysis refers to an ActiveFactory license.

The Information Server Client license is available in two different versions:

• Information Server Advanced Client
• Information Server Standard Client; which lacks InTouch Write Back, InBatch and QI Analyst integration.

The ActiveFactory license supports Terminal Services Server applications (except with a Per Device license).

Wonderware Development Studio

To develop applications for the Wonderware System Platform one or more Wonderware Development Studio
licenses are required. The Wonderware Development Studio license includes a single-node license to run the
following products:
• ArchestrA Integrated Development Environment (IDE)
• Application Server sized by IO-count
• Application Server Platform for testing System Platform-based applications
• InTouch Development and Runtime
• Device Integration Products
• Historian Server Standard Edition limited to 24 hour data retrieval and sized by Tag-count
• Microsoft SQL Server

An Unlimited version of the Wonderware Development Studio license includes all the above products, plus:   

• Information Server
• Information Server Client
• ActiveFactory
• InControl

The Wonderware Development Studio license is available in different sizes, each one offering a unique combination of:
• Application Server IO-count
• InTouch Tag-count
• Historian Server Tag-count
Installation
For instructions on installing Wonderware Performance Software, see the installation document located in the
root folder of the installation CD.
Additionally, refer to the “Wonderware Software Installation” series of online seminars where a session
corresponding to Wonderware Performance Software 3.5 may be available.
Wonderware eLearning training options are located at http://www.wonderware.com/training

Product support
Wonderware provides responsive, award-winning teams of specialists committed to delivering world-class
customer support, training, and consulting services. For information on the various customer support
programs, contact your local distributor or access the Wonderware Technical Support site online at
http://www.wonderware.com/support/mmi/
You will find a variety of information on the Technical Support site including the Wonderware Developer
Network (WDN) Library, Documentation, FAQs, Tech Alerts, Tech Articles, Tech Notes, and Tech Support
Forums. When you first enter the site, you will have limited access. To gain access to the different areas and
services, you must first register.
Also on the Technical Support site is the Technical Support Policies, Terms & Conditions guide which
provides information on how to contact Technical Support, information on the support policies and
procedures, and much more.
Section 6 – Application Planning
Section Objectives
• Explain a project workflow and area devices and why they are needed
• Identify functional requirements and naming conventions
• Expand on the concept of ArchestrA and how it relates to the manufacturing environment.
• Explain the benefits of migrating to an ArchestrA architectural environment.

This section provides an explanation of the need for adequately modeling your plant in order to achieve an application
implementation that will be optimal for efficiency.

Introduction
In order to successfully implement a project for the Wonderware System Platform 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

2
Just as there are many different criteria for Wonderware A projects, there are many different ways to design and
implement a supervisory and control system. The suggested project workflow is designed to help plan and implement
projects. By providing this workflow, the work flows more smoothly enabling completion of the project to be accomplished
much easier. You may develop your own workflow for implementing projects based on your experiences.
The following flow chart summarizes the logical steps to project completion.
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:   

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:
 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:
 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:

For ArchestrA IDE, references are created using this naming convention:   
<objectname>.<attributename>
For example:
YY123XV456.OLS
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 Discharge 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 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:
 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 plant-related 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.

Planning 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 ArchestrA IDE to create instances from templates.
Additional information on how to actually develop objects using templates is covered in Module 3, “Planning for
Object Templates”.
 

The next two steps, defining the security model, and defining the deployment model, are done once the initial Plant 
Model is in place. These are steps are detailed in subsequent modules in this training course. Please refer to additional 
information which is available in the Wonderware A2 Deployment Guide.   

Define Security Model: Each attribute of an AutomationObject is given a security classification. This provides the ability
to define who can write to attributes of an object.
Define Deployment Model: The Deployment Model view shows which objects instances reside on which computers. In
the ArchestrA environment, the physical location of object instances is not required to approximate the real-world
environment it models. The Deployment view does not need to reflect your physical plant environment.
Lab 2 – Identifying the Mixer
Introduction
This lab provides several detailed diagrams which identify components of a simulated factory layout for this
training scenario, as well as the main pieces of equipment that you will model and develop during this course.
The following diagrams provided in this lab will be used as references:
• Factory Layout
• Heat Exchanger: Process Diagram & Field I/O Signals
• Mixer: Process Diagram & Field I/O Signals

In this lab, for the student number XX, you can use your initials for example YZ, in order to create the unique identifiers for
each heat exchanger and mixer assigned. This lab will help familiarize you with the plant processes on which the
remaining labs are based.

Objectives
Upon completion of this lab you will be able to:
• Collect the proper information needed before proceeding to develop a Galaxy
• Use the naming convention and device structure defined for this class in subsequent labs

Summary Lab Instructions

Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.
This lab contains several intricate parts that are not easily summarized. Please refer to the Detailed
Lab Instructions on the next page.

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions,
please refer to the Summary Lab Instructions on the previous page.

Identify the Sample Application

This lab is does not have specific steps. In this lab you will study and try to understand the process flow of a factory through
the diagrams on the following pages.

In this lab, for the student number XX, you can use your initials for example YZ, in order to create the unique identifiers for
each heat exchanger and mixer assigned.

Description of the Mixer System

The mixer system consists of the following devices and functionality:
3 valves:
 Inlet 1: Inlet 1, which is used in conjunction with Pump 1 adds the first material into the tank
 Inlet 2: Inlet 2, which is used in conjunction with Pump 2, adds the second material into the tank
 Outlet: drains the tank
2 pumps:
 Pump 1: Pump 1, which is used in conjunction with Inlet 1 adds the first material into the tank
 Pump 2: Pump 2, which is used in conjunction with Inlet 2, adds the second material into the tank

1 motor:
 Agitator: Mixes the materials in the tank
2 meters
 LIT: Current level of the tank
 TT: Current temperature of the tank
Description of the Process
In this class a simulated mixer system process continuously executes batches (runs) with the following steps:
1 Add first material to the tank
2 Add second material to the tank
3 Mix the material in the tank
4 Drain the tank
Specifically, the devices of the mixer system are automatically operated by the simulation to perform the steps indicated
previously through the following sequence:

Throughout the execution of each batch, the LIT and TT devices will continuously indicate the current level and
temperature of the tank respectively. The temperature is in direct proportion with the level of the tank: the higher the level,
the higher the temperature, and vice versa; and it fluctuates from 35% to 90%, within the actual range.

Note: The simulation uses randomization to ensure the LIT and TT meter values differ from batch to batch.
   
 
 
MODULE 2
Application Infrastructure
Section 1 – The Plant Model
Lab 3 – Creating the Plant Model
Section 2 – The Deployment Model
Lab 4 – Creating the Deployment Model
Section 3 – The Runtime Environment
Lab 5 – Using Object Viewer
Section 4 – Connecting to the Field
Lab 6 – Connecting to the Field
 

Module Objective   
 Explain the concept and describe the need of developing a Plant Model before configuring the Wonderware
Application Server
 Identify key factors necessary for building successful applications.
 Explain Galaxies and introduce you to the ArchestrA IDE
 Explain Plant Modeling as it relates to Objects and Object Instances
Section 1 – The Plant Model
Section Objectives
• Explain the importance of having a model of the plant facility
• Examine the concept of how to utilize ArchestrA Application Server to model a specific facility

This section provides an explanation of the importance of having a model of the plant facility. Additionally, it explains
the concept of how to utilize ArchestrA Application Server to model a specific facility.

Modeling of the Facility

With the Wonderware 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:

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:
• 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.
 

Reporting Alarms Based on Area Model

When an alarm is detected, or an event occurs, the condition is reported to its alarm and event distributor, which is
running on the same AppEngine. These alarm and event distributors include:

 Area AutomationObjects All AutomationObjects and Area objects report detected alarms through the Area, which
distributes them to alarm and event clients.
 WinPlatform AutomationObjects Report their own alarms and events
 AppEngine AutomationObjects Report their own alarms and events
 Device IntegrationObjects Report their own alarms and events

WinPlatforms, AppEngines and Device Integration objects do not report their alarms and events to Area
AutomationObjects even though they belong to Areas. This allows alarm clients to receive alarm notifications without any
dependencies on Area AutomationObjects. For example, a deployed and running WinPlatform can report alarms even
though its Area is not deployed and running.
Using the Area model will become a filtering mechanism for alarms when we cover the Module on Alarms and History.
Lab 3 – Creating the Plant Model
Introduction
This lab illustrates the steps necessary to create the plant model for the Galaxy based on the information
gathered in Lab 2, “Identifying the Mixer”. You will create an additional $Area instance named ControlSystem to
accommodate future system objects created throughout the rest of this class.
To help organize the templates, you will develop a custom toolset named Training to hold the templates
created in the class.

Objectives
Upon completion of this lab you will be able to:
• Create new template toolsets
• Create derived templates
• Create instances
• Use the $Area object to create a plant model for the Galaxy

Summary Lab Instructions

Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.
Create a Template Toolset
1 Create a new Template Toolset named Training under the Galaxy.

Create the Plant Model

2 Create a derived template from the $Area object named $tArea and assign it to the Training template toolset.
3 Create the following instances out of the new $tArea template:
• Discharge
• Intake
• Production
• Line1
• Line2
• ControlSystem
4 Arrange the new $tArea instances to model the factory layout defined in Lab 2.

See the next page for Detailed Lab Instructions

 Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Create a Template Toolset

1 In the Template Toolbox, right-click on the Galaxy and select New Template Toolset.

   
2 A new template toolset is created. Name the new template toolset Training.   

Create the Plant Model

3 In the Template Toolbox, expand System / $Area to create a derived template of the $Area object by right-clicking
the $Area template and selecting New / Derived Template.

 
4 A new template is created. Name the new template $tArea.

5 Move the $tArea object into the Training template toolset.

6 Ensure that the Model view is selected.

 
7 Create a new instance of the $tArea template by dragging and dropping the $tArea object from the Template
Toolbox to the Model view.

8 Name the new instance Discharge.

9 Repeat the previous 2 lab steps to create the following Areas:
• ControlSystem
• Intake
• Line1
• Line2
• Production

The ControlSystem Area will be used in this example to accommodate future system objects created throughout the 
rest of this class.   

 
10 Drag‐and‐drop the newly created objects to assign areas Line1 and Line2 to the Production area. The final plant 
model should look like the following illustration:   

 
Section 2 – The Deployment Model
Section Objectives
• Explain the concept of the Deployment Model.
• Demonstrate the structure and organizational execution of the Deployment Model.

This section provides an explanation of the Deployment Model and demonstrates the structure of the
Deployment Model.

Deploying the Galaxy

You can deploy and test your objects at any time during development. When you are ready to test or move the
application into production, it's time to deploy the Galaxy.

Planning for Deployment

Deploying your Galaxy copies the objects from the development environment to the run-time environment.
This makes your objects "live" and functional.
Until you deploy your ArchestrA IDE configuration environment to the run-time environment, changes you
make in the ArchestrA IDE do not appear in the run-time environment. To see runtime data associated with
your objects, use Object Viewer or InTouch.
Objects deploy from the configuration environment to the run-time environment as follows:

deploys Object Viewer, Run-time environment

IDE Configuration Environment
    to
Galaxy database : [Does not exist in run-time environment]
Templates
  : [Does not exist in run-time environment]
Instance Objects : Instance objects [Run-time configuration and
behavior]
Security: General permissions : [Does not exist in run-time environment]
Security: Operational permissions : Run-time permissions to acknowledge alarms and
modify attributes
Scripts configuration : Scripts execution
Alarms configuration : Alarms generate and acknowledge
History configuration : History Logs [Wonderware Historian]
Deploying Objects
You deploy object instances for three reasons:
 Testing
 Place the application into production to process field data
 Update an existing application with changes you made

When you are ready to deploy, make sure the following conditions are met:
 Bootstrap software is installed on the target computer(s)
 The objects being deployed are not in an error state in the Galaxy database
 You created, configured, and checked in objects to the Galaxy
 Objects are assigned to a host
 The object's host is already deployed. A cascade deploy operation, which deploys a hierarchy of objects, deploys
all objects in the correct order. This deploys an object's host before the object is deployed.

Redeploying Objects
Redeploying is similar to deployment. While you are testing, you frequently redeploy your application to see changes
you make. The redeploying process undeploys the object and then deploys it back.
You may have an object whose deployment state is Pending Update. That means the object changed since it last
deployment. When you deploy those changes, the new object is marked as the last deployed version in the Galaxy.

Undeploying Objects
You may need to undeploy one of more objects. Undeploying removes one or more objects from the run-time
environment.
Before you start, you need to select the object or objects you want to undeploy in the ArchestrA IDE.
Before you delete or restore a Galaxy, undeploy all objects in the Galaxy.

Note: Undeploying can fail if the target object has objects assigned to it. Make sure you select Cascade Undeploy in the
Undeploy dialog box.
Lab 4 – Creating the Deployment Model
Introduction
This lab illustrates the steps necessary to create a deployment model for the Galaxy based on a standalone
setup and a single $AppEngine. You will begin by organizing the system objects using the plant model created
in the previous lab. Then, after creating the deployment model, you will send the complete Galaxy to the runtime
environment by deploying all objects.

Objectives
Upon completion of this lab you will be able to:
• Use the $WinPlatform, $AppEngine and $Area objects to create a deployment model for the Galaxy
• Deploy instances to the runtime environment

Summary Lab Instructions

Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Create the WinPlatform Object

a. Create a derived template from the $WinPlatform object named $tWinPlatform and assign it to the Training template
toolset.
b. Create an instance of the $tWinPlatform template named GRPlatform and assign it to the ControlSystem area.

Create the AppEngine Object

c. Create a derived template from the $AppEngine object named $tAppEngine and assign it to the Training template
toolset.
d. Create an instance of the $tAppEngine template named AppEngine and assign it to the ControlSystem area.

Create the Deployment Model

e. Using the Deployment view, host the AppEngine object on the GRPlatform object and all areas on the AppEngine
object.

Deploy the Objects

f. Cascade deploy the GRPlatform.

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the 
Summary Lab Instructions on the previous page(s).   

Create the WinPlatform Object

1 In the Template Toolbox, create a derived template of the $WinPlatform object by right-clicking the $WinPlatform
template and selecting New / Derived Template.

2 A new template is created. Name it $tWinPlatform.

3 Move the $tWinPlatform object to your Training template toolset.

   
4 Using the Template Toolbox and the Model view, create a new instance of the $tWinPlatform template by dragging 
the $tWinPlatform template to the Model view.   

 
Create the AppEngine Object
7 In the Template Toolbox, create a derived template of the $AppEngine object by right-clicking the $AppEngine
template and selecting New / Derived Template.

8 A new template is created. Name the new template $tAppEngine.

9 Move the $tAppEngine template to the Training template toolset.

10 Using the Template Toolbox and the Model view, create a new instance of the $tAppEngine template.

 
11. Name the new instance AppEngine.   

 
 
 
12. In the Model view, assign the AppEngine instance to the ControlSystem area.

 
Create the Deployment Model
13 Select the Deployment view.

14 Assign the AppEngine instance to the GRPlatform.

 
15 Assign all remaining areas to the AppEngine instance.   

Deploy the Objects

16. In Deployment view, right-click the GRPlatform instance and select Deploy.

The Deploy dialog box displays. By default the system will perform a Cascade Deploy with a Deploy Object Count of 8
instances, and it will set all instances On Scan as soon as the objects are deployed.

 
17. Leave the default settings and click OK. This will display a second Deploy dialog box indicating the deployment 
progress.   

 
 
As soon as the process is complete, the Close button is enabled.

18. Click Close to return to the ArchestrA IDE.

The Deployment and Model views now display the instances in their deployed state:

 
Section 3 – The Runtime Environment
Section Objectives
• Explain the concept of the Runtime Environment
• Illustrate the differences in the Development environment and the Runtime environment
• Explain the use of the Object Viewer in monitoring the Runtime environment

This section provides an explanation of the Runtime environment and explains the use of the Object Viewer in
monitoring the Runtime environment.

Runtime Environment
The previous workflow task defined the deployment model that specifies where objects are deployed. In other words,
the deployment model defines which nodes will host the various AutomationObjects.
The objects deployed on particular platforms and engines define the objects' “load” on the platform. The load is based
on the number of I/O points, the number of user-defined attributes (UDAs), and so on. The more complex the object,
the higher the load required to run it.
After deployment, the Runtime environment facilitates the activity generated by the objects. In Application Server the
Object Viewer is used to monitor the Runtime environment. The Object Viewer is used to check communications between
nodes and determine if the system is running optimally. For example, a node may be executing more objects than it can
easily handle, and it will be necessary to deploy one or more objects to another computer.
To view the activity in the Runtime database the Object Viewer is used. It displays the current value of all of the objects
and object attributes in the database. In order to create the Runtime database, Application Server requires information
about all of the variables being created. As object and object attribute values change (for example created, value
change, configuration change), the changes are reflected in Runtime and monitored via the Object Viewer.

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, right-click the attribute from the Attribute Name panel and select Add to
Watch.
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 by right-clicking on the Watch window and selecting Save. A previously
saved Watch window can also be loaded to monitor previously saved attributes. You can also add a second Watch window
that shows as a separate tab in the bottom of the Viewer.
Uploading Run-time Configuration
You can upload run-time configuration changes to the Galaxy database. This lets you keep any attribute values that
changed during run time.
The values of certain attributes can be set in the configuration environment, but they can also be changed by the user at
run time. As a result, the values of these attributes can differ between the run-time and configuration environments.
For example. you create an object with a UDA myInteger. In the Object Editor, you specify an initial value of 30.
Then you deploy the object. At run time, you write a new value to myInteger of 31. If you redeploy this object, the original
value of 30 overwrites any value assigned during run time.
If you want to upload run-time changes to the Galaxy, make sure the selected objects are:
• Not edited and checked in since last deployment or upload
• Not in Pending Update state
• Checked in

Objects whose configuration are successfully uploaded have a new version number and a change log entry for the upload
operation. The run-time object’s version number also has a new version number. That version number matches the version
in the configuration database.
If you select an object that is currently checked out to you, a warning appears during run-time upload. If you 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 run-time attributes are copied to the Galaxy database.

Note: You cannot upload run-time changes for objects checked out to other users.

To upload run-time changes to the Galaxy

a. Select one or more objects in the Model view or Deployment view. For example, you could select an entire hierarchy
from AppEngine down.
b. In the Object menu, click Upload Runtime Changes. The run-time attributes of the selected objects are copied over
those in the Galaxy database.
Lab 5 – Using Object Viewer
Introduction
This lab illustrates the steps necessary to use Object Viewer to monitor live data from your Galaxy’s runtime
environment. Different watch windows are added to organize the attributes to be monitored. The watch windows
are then saved in a single file for future use.

Objectives
Upon completion of this lab you will be able to:
• Open Object Viewer from the ArchestrA IDE
• Add attributes to watch windows to get a live feed
• Create and rename watch windows within Object Viewer
• Save watch windows to disk

Summary Lab Instructions

Following is a summary of the general steps you will complete for this lab. For detailed instructions,
please refer to the Detailed Lab Instructions on subsequent pages.

Using ObjectViewer
a. Open Object Viewer from within the ArchestrA IDE.
b. Rename the default watch window to Platform Info and add the following attribute references:

Instance Attribute Name

GRPlatform CPULoad
GRPlatform DiskSpaceFree[1]
GRPlatform RAMAvailableAvg
 

c. Create a new watch window called Engine Info and add the following attribute references:
Instance Attribute Name
AppEngine Scheduler.ScanPeriod
AppEngine ScanState
AppEngine ScanStateCmd
 

d. Save the watch list to your training folder (C:\Wonderware Training) with the name My Watch Windows.

See the next page for Detailed Lab Instructions

 Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Using ObjectViewer
1. In Model view, open Object Viewer by right-clicking the GRPlatform instance and selecting View in
Object Viewer.

 
The Object Viewer application opens displaying the attributes of the selected object on the right panel.   

2. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the default Watch
List 1 tab.

 
3. The Rename Tab dialog box is displayed. Enter Platform Info for the Tab Name field.

4. Click OK.
5. The tab is now labeled Platform Info.

 
6. On the Attribute List (right section of Object Viewer) locate and right-click on the CPULoad attribute and select Add
to Watch to add the attribute to the watch list.

Note: You can sort the Attribute Name column by clicking the Attribute Name column heading.   

 
7. Repeat the previous step for the following attributes:   

• DiskSpaceFree
When prompted, enter 1 as the array index which represents drive C

• RAMAvailableAvg

8. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add a new tab to
the watch list.
9. Right-click in the new Watch List 1 and select Rename Tab to rename the default Watch List 1 tab.
10. The Rename Tab dialog box displays. Enter Engine Info for the Tab Name field and click OK.
11. On the Object List (left section of Object Viewer) select the AppEngine object to display its attributes.
12. On the Attribute List (right section of Object Viewer) locate the following attributes, right-click on them,
and select Add to Watch to add them to the watch list. You can also multiple-select by holding the Ctrl
key and clicking each one.
• Scheduler.ScanPeriod
• ScanState
• ScanStateCmd

13. Right-click in the Watch List (bottom section of Object Viewer) and select Save As to save the watch list to disk.

   
The Save As dialog box displays.
14. Navigate to the C:\Wonderware Training folder and enter My Watch Windows in the File name field.

15. Click Save to save the watch list to the selected location.
Section 4 – Connecting to the Field
Section Objectives
• Become familiar with Device Integration Objects, I/O Server and Data Access Server
• Overview of DI Objects

This section provides an understanding of the Device Integration Objects, I/O Server and DA Server. It also
provides an overview of DI Objects.

Introduction
The server application provides the data and accepts requests from any other application interested in its
data. Requesting applications are called clients. Some applications such as InTouch and Microsoft Excel
can simultaneously be both a client and a server.

Dynamic Data Exchange (DDE)

Dynamic Data Exchange (DDE) is a communication protocol developed by Microsoft to allow applications in the
Windows environment to send/receive data and instructions to/from each other. It implements a client-server
relationship between two concurrently running applications.

Note: NetDDE, an older protocol previously used for communication over the network to Wonderware and
non-Wonderware sources, is strongly discouraged and has been phased out by Microsoft. SuiteLink is the recommended
communication protocol for use with Wonderware sources.
Wonderware SuiteLink
Wonderware SuiteLink uses a TCP/IP-based protocol. SuiteLink is designed specifically to meet industrial needs, such as
data integrity, high-throughput, and easier diagnostics. This protocol standard is supported for Windows 2000, Windows
2003 Server, and Windows XP.
SuiteLink is Not a Replacement for DDE. Wonderware recommends that DDE be used for internal client
communication, and SuiteLink for communication over the network.
Each connection between a client and a server depends on your network situation.
SuiteLink provides the following benefits:
 Consistent high data volumes can be maintained between applications, regardless of whether the applications are
on a single node or distributed over a large node count.
 Value Time Quality (VTQ) places a time stamp and quality indicator on all data values delivered to VTQ-aware
clients.
 Extensive diagnostics of the data throughput, server loading, computer resource consumption, and network
®
transport are made accessible through the Microsoft Windows NT operating system performance monitor. This
feature is critical for the scheme and maintenance of distributed industrial networks.
 The network transport protocol is TCP/IP using Microsoft’s standard Winsock interface. To use the SuiteLink
Communication Protocol, the following conditions must be satisfied.
 You must have Microsoft TCP/IP configured and working properly.
 You must use computer names (Node Names) of no more than 15 characters. For more information on
installing and configuring Microsoft TCP/IP, see your Microsoft Windows operating system's documentation.
 Wonderware SuiteLink must be running as a service. If for some reason SuiteLink has been stopped, you will
need to start it again. (SuiteLink is automatically installed as a Common Component when you install InTouch.
It is configured to startup automatically as a Windows Service).

DDE and SuiteLink I/O Addressing

DDE and SuiteLink identifies an element of data in an I/O data source program by using a three-part naming convention
that includes the application name, topic name and item name. To obtain data from another application, the client program
opens a communication channel to the server program by specifying these three items. Additionally, if the communication
channel is between applications running in different computers, a node name must be specified too.
Node: Name of the computer the I/O data source program or service is running on.
Application: Name of the source program or service that provides I/O data to the client
application. This is the name of the executable file without the extension.
Topic: It's an application-specific sub-group of data elements.
Item: Name of the actual individual data point to be access once the communication channel is opened.
For example, in the case of Excel as a server program, the application name is "Excel", the topic name is the name of the
specific spreadsheet that contains the data and the item name is the identification of the cell on the spreadsheet to/from
which the data is to be read/written.
OPC
OPC is open connectivity in industrial automation and the enterprise systems that support industry. Interoperability is
assured through the creation and maintenance of open standards specifications.
The first standard (originally called simply the OPC Specification and now called the Data Access Specification) resulted
from the collaboration of a number of leading worldwide automation suppliers working in cooperation with Microsoft.
Originally based on Microsoft's OLE COM (component object model) and DCOM (distributed component object model)
technologies, the specification defined a standard set of objects, interfaces and methods for use in process control and
manufacturing automation applications to facilitate interoperability. The COM/DCOM technologies provided the framework
for software products to be developed. There are now hundreds of OPC Data Access servers and clients.
A typical analogy for needing the original Data Access Specification is printer drivers in DOS and then in Windows. Under
DOS the developer of each application had to also write a printer driver for every printer. So AutoCAD wrote the AutoCAD
application and the printer drivers. And WordPerfect wrote the WordPerfect application and the printer drivers. They had to
write a separate printer driver for every printer they wanted to support: one for an Epson FX-80 and one for the H-P
LaserJet, and on and on. In the industrial automation world, one industrial device manufacturer wrote their Human
Machine Interface (HMI) software and a proprietary driver to each industrial device (including every PLC brand). Another
industrial device manufacturer wrote their HMI and a proprietary driver to each industrial device (including every PLC
brand, not just their own).
Windows solved the printer driver problem by incorporating printer support into the operating system. Now one printer
driver served all the applications! And these were printer drivers that the printer manufacturer wrote (not the application
developer). Windows provided the infrastructure to allow the industrial device driver's solution as well. Adding the OPC
specification to Microsoft's OLE technology in Windows allowed standardization. Now the industrial devices' manufacturers
could write the OPC DA Servers and the software (like HMIs) could become OPC Clients.
The resulting selfish benefit to the software suppliers was the ability to reduce their expenditures for connectivity and focus
them on the core features of the software. For the users, the benefit was flexibility. They could now choose software
suppliers based on features instead of "Do they have the driver to my unique device?" They don't have to create a custom
interface that they must bear the full cost of creating and upgrading through operating system or device vendor changes.
Users were also assured of better quality connectivity as the OPC DA Specification codified the connection mechanism
and compliance testing. OPC interface products are built once and reused many times; hence, they undergo continuous
quality control and improvement.
The user's project cycle is shorter using standardized software components. And their cost is lower. These benefits are
real and tangible. Because the OPC standards are based in turn upon computer industry standards, technical reliability is
assured.
The original specification standardized the acquisition of process data. It was quickly realized that communicating other
types of data could benefit from standardization. Standards for Alarms & Events, Historical Data, and Batch data were
launched.
 
Device Integration Objects

A DeviceIntegration object (DIObjects) is an AutomationObject that represents 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.

DDESuiteLinkClient
The DDESuiteLinkClient object is a key member of the core set of AutomationObjects within the ArchestrA system
infrastructure. The DDESuiteLinkClient object is a DeviceIntegration object that allows access to a running I/O Server. A
DDE or SuiteLink I/O Server can provide data points to Galaxy application objects through the DDESuiteLinkClient object.

Note: The DDESuiteLinkClient object is compatible with all Wonderware I/O Servers and components.

There is a one-to-one relationship between an instance of the DDESuiteLinkClient object and a running I/O Server. If you
want to reference data points in more than one I/O Server, you must configure and deploy more than one
DDESuiteLinkClient object. For example, you would need to configure one DDESuiteLinkClient object to communicate to
an TCP I/O Server and another one to talk to the GEHCS I/O Server.
When you configure the DDESuiteLinkClient object, you can specify one or more I/O Server topics to which access is
required. At run time, all items that the Galaxy application requires for a specified topic are updated with the latest values
from the I/O Server. The rate at which the values are updated depends on how the topics were configured within the target
I/O Server.
If you want to connect to a DDE I/O Server, specify login information that the DDESuiteLinkClient object uses to connect to
the I/O Server.

From other objects and from scripts, you can reference the topics you configured for the DDESuiteLinkClient object. For
example, you might configure the input source for a FieldReference object to reference an item for one of the topics. Thus,
the FieldReference object input source is receiving data from an I/O Server through the DDESuiteLinkClient object.
To aid in rapid application development, you can create a list of topic items that appear in the ArchestrA Attribute Browser.
To do this, specify the item address and associate it with a user-defined attribute name (alias). Creating the item list is not
required in order to reference data from the I/O Server.
The reference syntax for a DDESuiteLinkClient object data point is:
<objectname>.<topicname>.<itemname>

OR
<objectname>.<topicname>.<attributename>

The <objectname> is the name that you choose to give to the DDESuiteLinkClient object.
Each I/O topic for a DDESuiteLinkClient object is also known as a "scan group." Run-time object attributes allow you to
monitor errors related to the data quality for item values in a scan group.

InTouchProxy
The InTouchProxy Object is a gateway between Galaxy application objects and data that is available through an
InTouch application. The InTouchProxy object allows you to browse a selected InTouch application tagname dictionary,
add selected tags as attributes in the Galaxy application, then read these attributes from the InTouch application at run
time.

Note: Before using the tagname browser to browse for tags, make sure that InTouch WindowMaker is not running on the
InTouch node. WindowViewer, however, can be running. Also, be sure that you have given share permission of Read to
the InTouch folder that contains the Tagname.X file.

The InTouchProxy object is a key member of the core set of AutomationObjects within the ArchestrA system infrastructure.
The InTouchProxy object is a DeviceIntegration object that represents a running InTouch node. The InTouch node
effectively serves as the data provider (supporting the SuiteLink communication protocol) by providing data points to
Galaxy application objects through the InTouchProxy object.

Note: This object is compatible with InTouch v7.11 and later applications.

There is a one-to-one relationship between an instance of the InTouchProxy object and a running InTouch node. An
InTouch "node" is a unique combination of the computer name and InTouch application. If you want to reference data
points in more than one InTouch node, you must configure and deploy more than one InTouchProxy object. For example,
you would need to configure one InTouchProxy object to get data from an InTouch application running on Computer1 and
another one to get data from an InTouch application running on Computer2.
When you configure the InTouchProxy object, you might want to specify one or more existing InTouch tagnames (items) to
use as object attributes. At run time, if these attributes are added in the client (for example, the Object Viewer watch
window), they are updated with the latest values from the InTouch items. InTouch sends a new data value for an item to
the InTouchProxy object each time the value changes. Any items that you configure for an InTouchProxy object
automatically becomes available within the ArchestrA Attribute Browser.
From other objects and from scripts, you can reference the attributes you created for InTouch items. For example, you
might configure the input source for a FieldReference object to reference one of these InTouchProxy object attributes.
Thus, the FieldReference object's input source would be receiving data from a tag in an InTouch node through the
InTouchProxy object. The reference syntax for an InTouchProxy object data point is:

<objectname>.<InTouchTagName>

The <objectname> is the name that you choose to give to the InTouchProxy object.
The group of specified InTouch items for an InTouchProxy object is also known as the "scan group." Only one scan group
exists in the InTouchProxy object. Run-time object attributes within the scan group allow you to monitor errors related to
the data quality for InTouch item values in a scan group.
 
OPCClient
The OPCClient object is a key member of the core set of AutomationObjects within the ArchestrA system infrastructure.
The OPCClient object is a DeviceIntegration (DI) object that allows access to a running OPC Data Access (DA) Server. A
third-party OPC DA Server can provide data points to Galaxy application objects through the OPCClient object.

Note: The OPCClient object is compatible with all OPC Servers that are compliant with OPC Data Access v2.05 or later
standards.

There is a one-to-one relationship between an instance of the OPCClient object and a running OPC DA Server. If you want
to reference data points in more than one OPC DA Server, you must configure and deploy more than one OPCClient
object. For example, you would need to configure one OPCClient object to communicate to an TCP OPC Server and
another one to talk to the CIP OPC Server.
An OPCClient object supports the following operations on I/O points for the OPC DA Server:
 Subscriptions, which are implemented via scan groups. Read transactions, which are implemented via block
reads.
 Write transactions, which are implemented via block writes.

Note: If you are using this object to communicate with an OPC DA Server, you must properly configure the OPC DA
Server before deploying this object.

RedundantDIObject
The RedundantDIObject provides you with the ability to configure a single object with connections to two different data
sources (proxy objects or DIDevice objects). In the event of a failure of the active data source, this object automatically
switches to the standby data source.
This capability allows clients to configure redundant connections to a field device.
The RedundantDIObject is a DeviceIntegration object that makes redundant connections to a field device possible. If one
of the source objects is unable to provide connection to the field device, the RedundantDIObject automatically switches to
the other source object for continued data acquisition.
The way the RedundantDIObject determines that a data source is in Bad state by monitoring the ConnectionStatus
attribute common to all DIObjects, the ProtocolFailureReasonCode attribute that reflects a failure in communication by a
DAS DIObject with a field device, and the ScanState attribute common to all ApplicationObjects. When those attributes are,
respectively, Disconnected, non-zero, or Offscan, the status of the corresponding data source object is changed and a
switchover attempt is made to the other data source.
There is a one-to-two relationship between an instance of a RedundantDIObject and a pair of source DeviceIntegration
objects.

The RedundantDIObject supports the following operations on I/O points from field devices:
 Subscriptions, which are implemented via scan groups. Read transactions, which are implemented via block reads
(when available in the source DIObject). Write transactions, which are implemented via block writes (when
available in the source DIObject).

Note: Most ApplicationObjects in the ArchestrA environment write only the last data received in a scan cycle.
DeviceIntegrationObjects, including the RedundantDIObject, operate differently. They queue all data received in a scan
cycle and write them all in the order received.

The two source DIObjects do not have to be the same type. But they must support the same type of DAGroups and must
have the same item address space.

Note: The RedundantDIObject checks the state of its source DIObjects on every scan cycle.
 
Note: During configuration, one DIObject is set as the Primary DI source and the other is set as Backup DI source. These
are just the starting points. During runtime, the terms Active and Standby apply, the configured Primary object initially
being the Active object (if able to provide connection to the field device) and the configured Backup object initially being the
Standby. If the connection to the Active object fails, then the Standby becomes the Active one and the other becomes the
Standby. This switching between Active and Standby objects can be repeated multiple times depending on the configured
switch attributes.

For complete redundancy coverage, the RedundantDIObject must be configured to have the DAGroups that are common
to both source DIObjects. When the connection fails to the Active DIObject, all items are unsubscribed from the Active
DIObject and new subscriptions are made to the Standby DIObject. If either DIObject has unique DAGroups, it is important
that the RedundantDIObject should not be configured to use those uncommon DAGroups.
RedundantDIObjects belong to a family of objects called DINetwork objects.

Time and Quality Propagation

When a dynamic attribute is poked, the time stamp is updated to the timestamp passed in with the value if available, or the
current time provided by the hosting AppEngine is used. If the data provider passes in a Value, Time, Quality (VTQ) triplet
of data in the callback, the time stamp is associated with the value and quality used to update the attribute.

Scan Mode
The scanning mode for the scan group, either ActiveOnDemand, Active, or ActiveAll. For the ActiveOnDemand mode,
attributes that are not actively being referenced by any client or object are not scanned. For the Active mode, an attribute is
always in the active scanning state. When the last reference to the attribute is unregistered (unadvised), the attribute is
deleted. For ActiveAll, an attribute is always in the active scanning state, but when the last reference to the attribute is
unregistered (unadvised), the attribute is not deleted.
To enable Advanced Communication Management, you must:
 Select Advanced Communication Management for your Galaxy.
 Set the scan mode for each scan group that belongs to your device integration objects within the Galaxy.   

I/O Server
Different I/O data sources have different requirements. Two main groups are identified:
 Legacy I/O Server applications (SuiteLink, DDE, and OPC Servers) do not require a platform on the node on which
they run. They can reside on either a standalone or workstation node. However, the DI Objects used to
communicate with those data sources such as the DDESuiteLinkClient object, OPCClient object, and
InTouchProxy objects must be deployed to an AppEngine on a Platform. Although it is not required that these DI
Objects be installed on the same node as the data server(s) they communicate with, it is highly recommended in
order to optimize communication throughput.
 For Device Integration objects like CIP and TCP DINetwork objects, both the DAServer and the corresponding DI
Objects must reside on the same computer hosting an AppEngine.

I/O Servers can run on Workstations, provided the requirements for visualization processing, data processing, and I/O
read-writes can be easily handled by the computer. Run the I/O Server and the corresponding DI Object on the same node
where most or all of the object instances (that obtain data from that DI Object) are deployed.
This implementation expedites the data transfer between the two components (the I/O Server and the object instance),
since they both reside on the same node. This implementation also minimizes network traffic and increases reliability.
However, it is good practice to evaluate the overhead necessary to run each

 
Data Access Server (DA Server)
DAServers, are designed to provide simultaneous connectivity between plant floor devices and modern DDE, SuiteLink
and/or OPC based client applications. DAServers support the OPC Data Access 2.05 specification and offer additional
features beyond the standard, including powerful diagnostics and remote configuration capabilities. They offer enhanced
communication diagnostics and performance.
Each DAServer is designed to provide simultaneous connectivity between client applications based on Wonderware
SuiteLink, OPC and DDE protocols that run on Microsoft's Windows® operating systems and the data devices
supported by the specific protocol being translated.
Several standard features are available with each DA Server, including:
• 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 DA

Servers support connectivity to numerous protocols and products. Wonderware's current DA Servers offering also
includes support for:
• 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

The DAServer is like a driver: it can receive data from different controllers simultaneously. For example, a DAServer might
use OPC to access data remotely in one machine, and use InTouch to communicate with another machine. When a
DAServer transfers data, it also transfers a timestamp and quality codes.
The DAServer is flexible enough to be used in a variety of topologies, but some topologies are more efficient than
others.
For example, the DAServer can connect to the OPC Server directly across the network, or FactorySuite Gateway can be
placed on the same machine as the OPC DAServer and SuiteLink can be used to link the server to devices. Of the two
topologies, using FactorySuite Gateway is more efficient than connecting the DAServer directly to the OPC Server.
OPC DAServer technology also has drawbacks; for instance, data may be lost briefly without the user realizing the loss
has occurred.

 
   
Lab 6 – Connecting to the Field
Introduction
In this lab the $DDESuiteLinkClient object is used to create a connection to an InControl application
running the simulation that will feed your Galaxy for the rest of this class.
The InControl application effectively simulates the functionality of a regular IO Server or DA Server connected
to a real PLC.

Objectives
Upon completion of this lab you will be able to:
 Create and configure a $DDESuiteLinkClient object to connect to an IO Server or DA Server using SuiteLink as
the communication protocol
 Monitor the connection status of the $DDESuiteLinkClient object on runtime
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Create the Device Integration object

a. Derived a new template from the $DDESuiteLinkClient object, name it $tDDESuiteLinkClient, and assign it to the
Training template toolset.
b. Create an instance of the $tDDESuiteLinkClient template and name it InControl.
c. Configure the General tab of the new instance as follows:
• Server node: ComputerName of your Virtual Machine that you’ve set up
• Server name: RTEngine
• Communication protocol: SuiteLink

d. On the Topic tab, add a topic called tagname and import the InControl Items List.csv file from the C:\Wonderware
Training folder.
e. In Model view, assign the InControl instance to the ControlSystem area.

Deploy the Object

f. In Deployment view, assign the InControl instance to the AppEngine object and deploy the object.

Verify the Connection on Runtime

g. Open Object Viewer from within the ArchestrA IDE.
h. Using the watch list created in Lab 5, create a new watch window called InControl and add the following attribute
references from the InControl instance:
• ConnectionStatus
• Reconnect
• ServerNode
• ServerName
• CommunicationProtocol
• ScanGroupList (enter 1 as the array index)
i. Save the watch list.

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Create the Device Integration object

1 Expand the Device Integration toolset.
2 In the Template Toolbox, create a derived template of the $DDESuiteLinkClient object by right-clicking the
$DDESuiteLinkClient template and selecting New / Derived Template.

3 Name the new template $tDDESuiteLinkClient.

4 Move the $tDDESuiteLinkClient object to your Training toolset.

5. Using the Template Toolbox and the Model view, create an instance of the $tDDESuiteLinkClient template. Name the
new instance InControl.

Configure the Instance

6. Double-click on the InControl instance to open its configuration editor.
7. In the General tab, configure the object as follows:
• Server node: <ComputerName of your Virtual Machine>. The following figure uses ‘TRAININGPC’ as an
example.
• Server name: RTEngine
• Communication protocol: SuiteLink

8. Select the Topic tab.

9. In the Available topics section, click the Add button , type tagname as the Topic name and press the
Enter key.

 
10. With the topic tagname selected, click the Import button in the Associated attributes

for tagname section.

The Open dialog box displays.

11. Navigate to the C:\Wonderware Training folder, select the InControl Items List.csv file.

12. Click the Open button.

13. The content of the CSV file is loaded within the InControl object.

14. Click the Save and Close button and check in the object.

 
15. The Check In dialog box appears. Enter Initial configuration and setup in the Comment field.

16. Click the OK button.

17. In the Model view, assign the InControl instance to the ControlSystem area.

Deploy the Object

18. Select the Deployment view.
19. Assign the InControl instance to the AppEngine object.

 
20. Right‐click the InControl instance and select Deploy.   

 
 

 
 
21. The Deploy dialog box is displayed. By default the system will set the instance On Scan as soon as the object is
deployed.

22. Leave the default settings and click the OK button. This will display a second Deploy dialog box indicating the
deployment progress.
As soon as the process is complete, the Close button will enable.

23. Click the Close button to return to the ArchestrA IDE. The different views now display the instance in its
deployed state.
Verify Connection in Runtime
24. In Model view, open Object Viewer by right-clicking the InControl instance and selecting View in Object Viewer.

Note: If Object Viewer is already open and you switch to it without selecting the context menu item View in Object Viewer,
new instances may not display. Always select View in Object Viewer in the context menu to refresh and reload of instances
in Object Viewer.

25. The Object Viewer application opens to display the attributes of the selected object in the right panel.
26. If you closed Object Viewer, open your watch list by right-clicking the Watch List (bottom section of Object Viewer)
and select Open to open the My Watch Windows file.
27. Right-click in the Watch List and select Add Watch Window to add a new tab to the watch list.
28. Right-click in the Watch List and select Rename Tab to rename the default Watch List 1 tab.
29. The Rename Tab dialog box is displayed. Name the new tab InControl.

30. Click OK.

 
31. In the Attribute List (right section of Object Viewer) locate the following attributes, right-click on them, and select Add
to Watch to add them to the watch list. You may also click and drag each attribute to the InControl watch list.
• ConnectionStatus
• CommunicationProtocol
• Reconnect
• ServerName
• ServerNode
• ScanGroupList (enter 1 as the array index)

Verify that the InControl.ConnectionStatus Value is Connected.

32. Right-click in the Watch List (bottom section of Object Viewer) and select Save to save the watch list.

 
MODULE 3
Application Objects
Section 1 – Templates and Instances
Section 2 – The $UserDefined Object
Lab 7 – Modeling the Heat Exchanger
Section 3 – Change Control and Propagation
Lab 8 – Configuring Change Control and Propagation
Section 4 – The $AnalogDevice Object
Lab 9 – Modeling a Meter
Section 5 – The $DiscreteDevice Object
Lab 10 – Modeling a Valve, Pump, and Motor
Section 6 – Containment
Lab 11 – Creating the Mixer
 

Module Objectives
Be able to
 Identify and work with templates
 Derive and configure templates
Section 1 – Templates and Instances
Section Objectives
This section:
 Introduces you to the concept of templates and explain how to derive a template.

This section introduces you to the concept of templates and explain how to derive a template.

Templates
One of the major benefits of 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 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.

Templates are high-level definitions of the devices in your environment. Templates are like a cookie cutter from which
you can make many identical cookies.
You define a template for an object, like a valve, one time and then use that template when you need to define another
instance of that item. Template names have a dollar sign ($) as the first character of their name.
A template can specify application logic, alarms, security, and historical data for an object.
A template can also define an area of your environment. You can extend and customize a template by adding User
Defined Attributes (UDAs), scripts, or extensions to meet the specific needs of your environment. Objects inherit
attributes from their parents.
Wonderware Application Server comes with predefined templates, called base templates. You cannot change these
templates. All templates you create are derived from base templates.
You can also nest templates, or contain them. Contained templates consist of nested object templates that represent
complex devices consisting of smaller, simpler devices, including valves. A reactor is a good candidate for containment.
Templates only exist in the development environment.
Using the Diaphragm valve template, you can quickly create an Diaphragm valve instance when you need another
Diaphragm valve in your application.

Instances
Instances are the run-time objects created from templates in Wonderware Application Server. Instances are the specific
things in your environment like processes, valves, conveyer belts, holding tanks, and sensors. Instances can get
information from sensors on the real-world device or from application logic in Wonderware Application Server. Instances
exist during run time.
In your environment, you may have a few instances or several thousand. Many of these instances may be similar or
identical, such as valves or holding tanks. Creating a new valve object from scratch when you have several thousand
identical valves is time-consuming. That's where templates come in.

Propagation
If you need to change something about all diaphragm valves, you can change the template for the diaphragm valve and all
diaphragm valves in your application inherit the changes, assuming the attributes are locked in the parent template. This
makes it easy to maintain and update your application.
Planning for Object Templates
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 ArchestrA IDE to create instances from templates.

Wonderware 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.
Leveraging of Template Instances
To derive a Template from another one, do the following:
a. Select the Template in the ArchestrA IDE the new Template is to be derived from.
b. 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.
c. 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.
Section 2 – The $UserDefined Object
Section Objectives
This section:
 Introduces you to the $UserDefined object and its functionality.

This section introduces you to the $UserDefined object and its functionality.

$UserDefined Object
The UserDefined object provides the basic functionality you need to develop an ArchestrA supervisory
application. The UserDefined object provides this functionality as Field Attributes, scripts, User Defined
Attributes (UDAs), and attribute extensions.
You can configure Field Attributes as an Analog or Discrete type with one of the following access modes:
 Input. The Field Attribute only accepts input. The Field Attribute is updated based on the value that is read from
the configured input address.
 InputOutput. The Field Attribute accepts input and sends output. The output destination can optionally differ from
the input source address. The InputOutput mode supports the User writeable and Object writeable attribute
categories.
 Output. The Field Attribute only sends output. The Field Attribute writes to the specified output destination. The
Output mode supports the following categories:
 Calculated
 Calculated retentive
 User writeable
 Object writeable

Note: We recommend you do not extend the Field Attribute value with an Input, InputOutput, or Output extension. If the
value is extended, unstable behavior with the Field Attribute value will occur.

The Analog Field Attribute supports the following data types:

• Integer
• Float
• Double

The Analog Field Attribute provides the enabling and configuration for the following functionality:
• Scaling of Input and Output values
• History
• HiHi, Hi, Lo and LoLo Limit Alarms
• Rate of Change Alarms
• Target Deviation Alarms
• Bad Value Alarm
• Statistics
The Discrete Field Attribute provides the enabling and configuration for the following functionality:
• State Labels
• History
• State Alarm
• Bad Value Alarm
• Statistics

The UserDefined object is an object that you can use to create customized objects. You can use the UserDefined object
as a template, or as a container.
As a template
Use the UserDefined object as a template containing Field Attributes associated to multiple variables in a system.
In this case, the object provides a simple and manageable structure as all the variables are contained in the same
object.
For example, you might create a UserDefined object called “Tank” and configure Field
Attributes that represent variables associated to the tank system:
 LT100 - Analog Field Attribute - Input from a level transmitter configured with options such as: Scaling, Limit
alarms and Statistics (Min/Max/Avg).
 TT100 - Analog Field Attribute - Input from a temperature transmitter configured with options such as Rate of
Change alarm and Statistics (Min/Max/Avg).
 SW100a -Discrete Field Attribute -Input from a limit switch configured with options such as State Labels and
State alarm.
 SW100b -Discrete Field Attribute -Input from a limit switch configured with options such as State Labels and
State alarm.
 XV100a - Discrete Field Attribute - InputOutput to a solenoid valve configured with options such as State
Labels, State alarm, and Statistics (Open/Close time).
 XV100b - Discrete Field Attribute - InputOutput to a solenoid valve configured with options such as State
Labels, State alarm, Statistics (Open/Close time).

References between attributes in the object can be accomplished by using relative reference, for example:
The “Tank” can be customized to raise an alarm when both XV100a and XV100b valves are open. For example,
you can add a Boolean UDA called “ValueOpenAlarm”, extend it with an Alarm Extension, and then add the
following OnExecute script:
IF me.XV100a == "Open" AND me.XV100b == "Open" THEN me.ValueOpenAlarm
= true;
ELSE me.ValueOpenAlarm = false;
ENDIF;

As a “container”
Use the UserDefined object 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.
Lab 7 – Modeling the Heat Exchanger
Introduction
In this lab the $UserDefined object is used to model the heat exchanger device identified in Lab 2. The
InControl object created in the previous lab provides the connection to the live values for the four temperature
transmitters within the heat exchanger.

Objectives
Upon completion of this lab you will be able to:
• Configure and use object templates to create instances that will inherit configurations
• Use the Field Attributes functionality provided by the $UserDefined object
• Use the Galaxy Browser to build references to instance attributes within the Galaxy
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Create the Heat Exchanger Template

a. Derived a new template from the $UserDefined object, name it $HeatEx, and assign it to the Training template toolset.
b. Add to the $HeatEx template four analog field attributes named T1, T2, T3 and T4. Configure each field attribute as
follows:

Create and deploy a Heat Exchanger Instance

c. Create an instance of the $HeatEx template (leave the default name) and assign it to the Intake area.
d. Configure the Input source of each one of the four field attribute references, where XX is your student number:

e. Deploy the object.

View the Heat Exchanger Data in Runtime

f. Open Object Viewer from within the ArchestrA IDE.
g. Using the watch list created in Lab 5, add a new watch window named HeatEx with the following attributes from the
HeatEx_001 instance:
• T1
• T2
• T3
• T4
h. Save the watch list.

See the next page for Detailed Lab Instructions   
 
Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Create the Heat Exchanger Template

1. In the Template Toolbox, expand the Application toolset.
2. Create a derived template of the $UserDefined object by right-clicking the $UserDefined template and selecting
New / Derived Template.

3. A new template is created. Name it $HeatEx.

 4. Move the $HeatEx object to your Training template toolset.

5. Double-click on the $HeatEx template to open its configuration editor.

   
6. In the Field Attributes tab, click on the Add Analog button                  to add a new analog field attribute. 

7. Configure the new field attribute as follows:

Name: T1
Access mode: Input
Data type: Float
Engineering units: Deg F
Enable I/O scaling: checked
Raw value: Maximum: 4095.0
EU value: Maximum: 250.0
EU range value: Minimum: -5.0
EU range value: Maximum: 255.0
8. Repeat steps 5 and 6 to add three more field attributes, using the same configuration as T1. Name the attributes
T2, T3 and T4.

9. Click the Save and Close button to check in the object.

10. The Check In dialog box appears. Enter Initial configuration and setup in the Comment field.

11. Click OK.

A second Check In dialog box is displayed indicating the progress of the operation. As soon as the process is
complete, the Close button will be enabled.

12. Click the Close button.

Create a Heat Exchanger Instance
13. Using the Template Toolbox and the Model view, create an instance of the $HeatEx template using the default
name of HeatEx_001.
14. Assign the instance to the Intake area.

15. Double-click on the HeatEx_001 instance to open its configuration editor.

16. In the Inherited field attributes section, select the T1 attribute.
17. In the I/O section, click on the Input source ellipsis button to assign a reference using the Galaxy Browser.

18. The Galaxy Browser window appears.

19. In the Instances panel (left) select the InControl object.

20. In the InControl panel (right) select tagname.HE1XX_TC1 where XX is your student number. In this example, the
student number is 00.
 21. Click OK.
The Input source attribute contains the selected reference:

22. Repeat steps 17 through 22 to configure the Input source for attributes T2, T3 and T4 using the
tagname.HE1XX_TC2, tagname.HE1XX_TC3 and tagname.HE1XX_TC4 attributes.

23. Click the Save and Close button

24. The Check In dialog box appears. Enter Initial configuration and setup in the Comment field.

25. Click OK.

 
Deploy the Object   
Notice that the HeatEx_001 instance icon includes a yellow square. This indicates the object is not deployed.

27. Select the Deployment view, right-click the HeatEx_001 instance and select Deploy.

   
The Deploy dialog box appears. By default the system will set the instance On Scan as soon as the object is deployed.   

28. Click OK to accept the default settings.

A second Deploy dialog box appears indicating the object deployment progress.

29. Click Close when the deployment is complete.

 
Notice that the HeatEx_001 icon changes (the yellow box is removed) to indicate its successful deployment:   

   
View the Heat Exchanger Data in Runtime   
30. Right-click the HeatEx_001 instance and select View in Object Viewer to show the HeatEx_001 object and its
attributes in Object Viewer.
31. The Object Viewer application opens displaying the attributes of the selected object. If you closed Object Viewer, click
File / Load Watch List to open the watch list file you saved earlier.

32. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add a new tab to
the watch list.

33. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the default Watch
List 1 tab.
The Rename Tab dialog box is displayed.

34. Enter HeatEx for the Tab Name field and click OK.

 
35. In the Attribute List (right section of Object Viewer) locate the following attributes, right‐click on them, and select 
Add to Watch to add them to the watch list:   

• T1
• T2
• T3
• T4

You will observe the attribute values changing in real time. The Quality attribute should reflect Good data.

36. Right-click in the Watch List (bottom section of Object Viewer) and select Save to save the watch list.
Section 3 – Change Control and Propagation

Section Objectives
 Introduce the concept of attribute locking, and
 Explain how locking attributes can propagate to previously derived instances.

This section presents the concept of attribute locking and provides an illustrations on 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:

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 don’t 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

To lock a Template attribute, do the following:

a. Select the desired Template in the ArchestrA IDE and start its editor.
b. Enter a value in an attribute field in the object’s editor.
c. 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 object’s editor.
d. 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 object’s editor.
The locked attribute is unavailable for editing.

Unlocking an Attribute
To unlock a Template attribute, do the following:
a. Select the desired Template in the ArchestrA IDE and start its editor.
b. Select the locking mechanism for the locked attribute in the object’s editor. Some editors may have lock icons
associated with certain edit fields, but this possibility is within the scope of the developer of the object’s editor.
c. 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 still Locked (in me). The previously locked attribute in any
instances of derived templates remain in Locked in Parent.
Lab 8 – Configuring Change Control and Propagation
Introduction
This lab illustrates how to modify the template for the heat exchanger to change the engineering units from ‘Deg
F’ to ‘Celsius’, locking the attribute so the changes are propagated to the existing instance. It also illustrates that
by locking the scaling configuration of the object it cannot be changed on derived objects.

Objectives
Upon completion of this lab you will be able to:
• Lock attributes in templates to control the changes that can be made on derived objects
• Propagate changes from templates to derived object by modifying the value of locked attributes

Summary Lab Instructions

Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Lock the Attributes

a. In the $HeatEx template, modify the configuration of the four field attributes as follows:

Engineering units: ‘Celsius’ and locked Scaling section: locked

Verify the Changes to the Existing Instance

b. Open the configuration editor for the HeatEx_001 instance to verify the changes made in the template.

Redeploy the Object

c. Redeploy the object.

See the next page for Detailed Lab Instructions Detailed Lab Instructions

 
Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the 
Summary Lab Instructions on the previous page(s).   

Lock the Attributes

1. In the Training template toolset, double-click on the $HeatEx template to open its configuration
editor.

   
2. In the Field attributes section, select the T1 attribute and change the configuration as follows:

Engineering units: ‘Celsius’ and locked

Scaling section: locked

Note: You may need to expand the Enable I/O scaling section. Click the button to expand the section.

3. Repeat step 2 for field attributes T2, T3 and T4.

4. Click the Save and Close button and check in the object.

 
The icon in front of the existing HeatEX_001 instance indicates that a change has been made to its
configuration since it was last deployed.

Verify the Changes to the Existing Instance

5. Double-click the HeatEx_001 instance to open its configuration editor and verify the changes.
6. Select the T1 field attribute and expand the Enable I/O scaling section and verify the changes.

7. Save and Close the editor.

 
Redeploy the Object
Notice that the HeatEx_001 instance icon has changed; a square that is shaded with a black triangular shape has been
added to indicate the object configuration has changed in the deployed object, but the change is not deployed.
8. Select the Deployment view, right-click the HeatEx_001 instance and select Deploy.

The Deploy dialog box appears. Notice by default Deploy Changes is selected, indicating only the objects with changes
will be deployed.

9. Leave the default settings and click OK.

 
A second Deploy dialog box appears indicating the progress on deploying the object. As soon as the process is
complete, the Close button will enable.

10. Click Close.

 
Section 4 – The $AnalogDevice Object
Section Objectives
This section:
 Introduces you to the concept of the $AnalogDevice object and its functionality.

This section introduces you to the concept of the $AnalogDevice object and its functionality.

$AnalogDevice Object
The AnalogDevice object is an ApplicationObject that can be configured as either a basic analog device, or an
analog regulator device. When configured as a basic analog device, the AnalogDevice object follows the
traditional model of a basic analog input/output object with alarming and history. When configured as an analog
regulator device, the AnalogDevice object provides an external model of a PID controller that exists in a field
device, in addition to providing the traditional analog alarming and history capabilities.
• AnalogDevice Object as a Basic Analog Input/Output Object
• AnalogDevice Object as an Analog Regulator Object

AnalogDevice Object as a Basic Analog Input/Output Object

When configured as a basic analog device, this object provides a means for reading and optionally writing
analog signals from the field or from another object. The basic I/O characteristics are:
 The process value (PV) is read from the field (except when the AnalogDevice object is configured to be in Manual
mode).
 You can configure the AnalogDevice object to enable or disable analog output. If you enable output, you can
configure the output destination address to be the same (default) or different from the input source address.
Commands to change the PV will result in an output to field. For data integrity, the value of PV represents the
value read from the external controller (except when the AnalogDevice object is in Manual mode), not the
requested PV that is output to the external controller.
 The input and outputs can be optionally scaled between raw counts and engineering unit values using either linear
or square-root conversions.

The AnalogDevice object supports alarming for PV conditions, such as when the PV:
 Exceeds level limits, such as Lo, Hi, LoLo, and HiHi.
 Exceeds rate-of-change limits, for both positive and negative directions.
 Exceeds major and minor deviations from a target value.
 Has a quality value of BAD.

In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV value. If you
enable the PV override, then you can use the PV.Mode attribute to place the AnalogDevice object into either
Auto or Manual mode. When the AnalogDevice object is in Auto mode, the PV is updated from the field and
matches the value and quality of the PVAuto attribute. When the AnalogDevice object is in Manual mode, the
PVAuto attribute continues to be updated from the field, but the PV value does not. Instead, the PV can be set
by a user write or a script, and the quality is always set to UNCERTAIN.
Finally, you can configure the AnalogDevice object to historize key variables, including PV and PV.Mode.
AnalogDevice Object as an Analog Regulator Object
When configured as an analog regulator device, the AnalogDevice object provides a means for reading and optionally
writing two separate analog signals from the field or from another object: one PV value and one setpoint (SP) value. The
basic I/O characteristics are:
 The process value (PV) is read from the field (except when the AnalogDevice object is configured to be in Manual
mode), but is never written.
 The SP value is both read from the field and written to the field. You can configure the SP output destination
address to be the same (default) or different from the input source address. Commands to change SP result in an
output to field. 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.
 The PV and SP can be optionally scaled between raw counts and engineering unit values using either linear or
square-root conversions.

The AnalogDevice object supports alarming for PV conditions, including when the PV:
 Exceeds level limits, such as Lo, Hi, LoLo, and HiHi.
 Exceeds rate-of-change limits, for both positive and negative directions.
 Exceeds major and minor deviations from the SP value.
 Has a quality value of BAD.

In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV value. If you enable the
PV override, then you can use the PV.Mode attribute to place the AnalogDevice object into either Auto or Manual mode.
When the AnalogDevice object is in Auto mode, the PV is updated from the field and matches the value and quality of the
PVAuto attribute. When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated from the
field, but the PV value does not. Instead, the PV can be set by a user write or a script, and the quality is always set to
UNCERTAIN.
Other controller-oriented features that can be configured for an AnalogDevice object of type analog regulator
include:
 Controller mode (CtrlMode attribute). You can use the controller mode to govern what types of writes are allowed
to the SP value within the system. Controller mode options are Manual, Cascade, and None. When the object is in
Manual mode, only end users are allowed to command a change in the value of SP. In Cascade mode, only scripts
or other supervisory objects are allowed to command a change to SP. Finally, if None is specified for the controller
mode, any type of write is allowed for the SP.
 Control tracking. A Boolean control track flag can be read from an external device or object. When tracking is on,
the external controller "owns" the value of the SP; the SP is purely read-only and cannot be commanded to be
changed and output to the field.
Lab 9 – Modeling a Meter
Introduction
This lab illustrates how to use the $AnalogDevice object to model a meter template which will be used later to
create the objects for the mixer level and temperature transmitters identified in Lab 2.
The template created in this lab will be integrated later with other templates to form the mixer object;
because of this, no instances will be created yet for this object.

Objectives
Upon completion of this lab you will be able to:
 Configure an $AnalogDevice object
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Create the Meter template

a. Derive a new template from the $AnalogDevice object, name it $Meter, and assign it to the Training
template toolset.

b. Configure the object as follows:

Type: Analog (locked)

Enable analog output: Unchecked (locked)
Enable PV override: Unchecked (locked)
Enable I/O scaling: checked (locked)
Raw value Minimum: 0.0 (locked)
Raw value Maximum: 4095.0 (locked)
Conversion mode: Linear (locked)
Clamp input to EU range: unchecked (locked)

See the next page for Detailed Lab Instructions

 Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the
Summary Lab Instructions on the previous page(s).

Create the Meter Template

1. In the Training template toolset, right-click the $AnalogDevice template and select New / Derived
Template to create a derived template of the $AnalogDevice object.

2. Name the new template $Meter and move it to the Training template toolset.

3. Double-click the new $Meter template to open its configuration editor.

 
4. Configure the General tab as follows:
Type: Analog (locked)
Enable analog output: Unchecked (locked)
Enable PV override: Unchecked (locked)
Enable I/O scaling: checked (locked)
Raw value Minimum: 0.0 (locked)
Raw value Maximum: 4095.0 (locked)
Conversion mode: Linear (locked)
Clamp input to EU range: unchecked (locked)

5. Click the Save and Close button and check in the object.
Section 5 – The $DiscreteDevice Object
Section Objectives
This section:
 Introduces you to the concept of the $DiscreteDevice object and its functionality.

This section introduces you to the concept of the $DiscreteDevice object and its functionality.

$DiscreteDevice Object
The DiscreteDevice object is a general purpose ApplicationObject that represents a large class of physical
equipment common in manufacturing, such as pumps, valves, motors, and conveyors. These devices have two
or more discrete physical states (for example, Open, Closed, and Moving). The actual state of a device is
monitored using a combination of discrete inputs, and a device can be optionally controlled using a combination
of discrete outputs.
The state names are configurable and are mapped to both input and output Boolean combinations in truth-table
form. The meaning of the states depends on the type of discrete device. For a pump, the states might be
configured as "Off" and "On," while for a valve they might be configured as "Open," "Closed," and "Moving."
Note that a control valve has a continuous position represented by an analog signal of 0 to 100% and is not
properly represented with a discrete device. Control valves are best represented with the AnalogDevice object.
When a DiscreteDevice object is commanded to a new state, it sets the configured combination of discrete
outputs for that state. When one or more of its monitored discrete inputs change, the DiscreteDevice object
determines the new actual state of the equipment and sets the process value (PV) appropriately.
Input and output states are totally independent of each other and can be configured as required by your
application; however, the input and output states can be linked by alarms. This allows the object to detect a
command timeout and uncommanded change alarms when devices unexpectedly change, or fail to change
when commanded to do so.
Historization of key attributes including the current state (PV) and commanded state (Cmd) can also be
configured.
Finally, the DiscreteDevice object supports a rich set of statistics reporting that you can enable during
configuration.

DiscreteDevice Object States

The DiscreteDevice object has two key attributes that represent the current state (PV) and the commanded
state (Cmd). Both of these are enumerations. The DiscreteDevice object can have up to five states that can be
configured with state names that are appropriate to the equipment being monitored. The actual meanings of the
states are dependent on the equipment:

 Passive
The passive state represents the state of the discrete device when it is idle, stopped, or closed (the typical
non-running position). For example, the passive state for a motor might be "Off."

 First Active
The first active state (Active1) represents the state of the discrete device when it is considered to be
running. For example, the active state for a motor might be "Forward." You can use outputs to control
the first active state.

 Second Active
(Optional) Some discrete devices have more than one active state. For example, a motor might have a second
active state of "Backward." You can use outputs to control the second active state (Active2).

 Transition
(Optional) The discrete device is in a transition state any time it is changing from one valid state to another. For
example, if you have a valve with a passive state of "Off" and an active state of "On," the transition state might be
"Moving."

 Fault
The fault state occurs when the feedback that is coming from the field is incorrect or impossible based on how the
discrete device works. For example, a fault would occur if the Hi and Lo limit is being reached at the same time for
a single device. Examples of fault state names are "Error," "Bad," or "Broken."
Monitoring a Discrete Device through Inputs
If you configure the DiscreteDevice object to have inputs (feedback) from the field, the input values are used to update the
overall state of the device. A DiscreteDevice object can have up to four inputs. After defining the inputs, map the different
input combinations to the possible states for the device.
For example, you might have a valve on your discrete device that can be either opened or closed. You have defined the
passive state of the device as Closed, the first active state as Opened, and the fault state as Bad. You would then create
references for two field inputs: one for the open position (Valve_Open), and one for the closed position (Valve_Close). You
then would map the inputs to the defined states. For example:

Valve_Open Valve_Close Mapped State

0 0 Transition
0 1 Closed
1 0 Opened
1 1 Bad
where:
1=TRUE
0=FALSE

By default, when the monitored discrete inputs change, the DiscreteDevice object determines the new actual state of the
equipment and updates the value of the process value (PV) appropriately.
You can configure the DiscreteDevice object to allow or disallow overriding of the PV value. If you enable the PV override,
then the object can be placed in Auto, Manual, or Simulate modes using the PVMode attribute.
 When the object is in Auto mode, the PV updates from the field and matches the value and quality of PVAuto.
 When the object is in Manual mode, PVAuto continues to update from the field but the PV does not. Instead, the
PV can be set by a user or script and the quality is always marked as UNCERTAIN.
 When the object is in Simulate mode, the PV value is set equal to the Cmd value, rather than read from the field.

   
Controlling a Discrete Device through Outputs
You can control (command) the passive, first active, and second active states of the discrete device using the Cmd
attribute. The transition and fault states are not commandable. When a DiscreteDevice object is commanded to a new
state, it sets an appropriate combination of discrete outputs for that state.
For example, you might map the first active state of "Open" to a discrete device output reference that will turn a valve to the
open position. When you set the Cmd attribute to "Open," the valve is "commanded" to be opened. If inputs (feedback) are
configured for the DiscreteDevice object, the object could then detect when the valve is actually open or closed.
Commanding a discrete device to a new state does not directly change the PV unless you have the PVMode set to
"Simulate."
Controller-oriented features for the DiscreteDevice object include:
 A configurable control mode. The control mode (Manual or Cascade) determines what types of writes are allowed
to the Cmd value within the system. Manual indicates that only users (operators) are allowed to request a change
to Cmd, whereas Cascade indicates that only scripts or other supervisory objects are allowed to request a change
to Cmd.
 Control tracking. A Boolean control track flag can be read from an external device or object. When tracking is on,
the external controller "owns" the value of the Cmd; the Cmd is purely read-only and is set to the value of PV.

Alarm Capabilities
The DiscreteDevice object provides sophisticated alarming capabilities, including:
 Command timeout alarm, which indicates that the PV state did not change to match the Cmd state within a
configurable timeout period.
 Uncommanded change alarm, which indicates that the PV state changed from the expected Cmd state to some
other state and the quality of PV is GOOD or UNCERTAIN (not BAD).
 Individual alarms for each of Active1, Active2, and Fault state conditions.
 Duration alarms for each of Active1 and Active2 states, indicating the discrete device has been in the state for too
long of a time period.

Statistical Features
The DiscreteDevice object offers advanced built-in state tracking calculations that can be used for equipment monitoring
and time-in-use tracking, including:
 The most recent time durations of the Active1, Active2 and Passive states.
 The total accumulated time durations of the Active1, Active2 and Passive states, with optional alarming on the
Active1 and Active2 total durations.
 The number of transitions into the Active1, Active2 and Passive states.
 A commandable reset of all statistics.
Lab 10 – Modeling a Valve, Pump, and Motor
Introduction
This lab illustrates how to use the $DiscreteDevice object to model a valve, a pump and a motor template which will be
used later to create the mixer’s inlet and outlet valves, as well as the transfer pumps and agitator identified in Lab 2.
Initially, the templates for the pump and the motor are quite similar. Later, you will extend the motor template to handle
the speed associated with the mixer’s agitator.
The templates to be created in this lab will be integrated later with other templates to form the mixer object; because of
this, no instances will be created for these objects at this time.

Objectives
Upon completion of this lab you will be able to:
 Configure a $DiscreteDevice object
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Create the Valve Template

a. Derive a new template from the $DiscreteDevice object, name it $Valve, and assign it to the Training template
toolset.

b. Configure the object’s General tab as follows:

Enable inputs: Checked (locked)
Enable outputs: Checked (locked)

c. Configure the object’s States tab as follows:

Enable second active state: Unchecked (locked)
Enable transition state: Checked (locked)
State names: (locked)
Passive state: Closed
First Active state: Open
Transition state: Traveling
Fault state: Fault

d. Configure the object’s Inputs tab as follows:

Number of Inputs: 2 (locked)
Input Name: (locked)
Input 2 Input Name: CLS
Input 1 Input Name: OLS
Input to PV Map: (locked)
0 0: Traveling
0 1: Open
1 0: Closed
1 1: Fault
PV override: (locked)

e. Configure the object’s Outputs tab as follows:

Number of outputs: 1 (locked)
Output Name: (locked)
Output 1 Output Name: CmdOpen
Closed: Unchecked (locked)
Open: Checked (locked)
Initial control mode: Manual (locked)
Control tracking: (locked)
Create the Pump Template

f. Derived a new template from the $DiscreteDevice object, name it $Pump, and assign it to the Training template
toolset.

g. Configure the object’s General tab as follows:

Enable inputs: Checked (locked)
Enable outputs: Checked (locked)

h. Configure the object’s States tab as follows:

Enable second active state: Unchecked (locked)
Enable transition state: Unchecked (locked)
State names: (locked)
Passive state: Stopped
First Active state: Running
Fault state: Fault

i. Configure the object’s Inputs tab as follows:

Number of Inputs: 1 (locked)
Input Name: (locked)
Input 1 Input Name: FlowSwitch
Input to PV Map: (locked)
0: Stopped
1: Running
PV override: (locked)

j. Configure the object’s Outputs tab as follows:

Number of outputs: 1 (locked)
Output Name: (locked)
Output 1 Output Name: CmdStart
Stopped: Unchecked (locked)
Running: Checked (locked)
Initial control mode: Manual (locked)
Control tracking: (locked)

 
Create the Motor Template
k. Derived a new template from the $DiscreteDevice object, name it $Motor, and assign it to the Training template
toolset.

l. Configure the object’s General tab as follows:

Enable inputs: Checked (locked)
Enable outputs: Checked (locked)

m. Configure the object’s States tab as follows:

Enable second active state: Unchecked (locked)
Enable transition state: Unchecked (locked)
State names: (locked)
Passive state: Stopped
First Active state: Running
Fault state: Fault

n. Configure the object’s Inputs tab as follows:

Number of Inputs: 1 (locked)
Input Name: (locked)
Input 1 Input Name: AuxContact
Input to PV Map: (locked)
0: Stopped
1: Running
PV override: (locked)

o. Configure the object’s Outputs tab as follows:

Number of outputs: 1 (locked)
Output Name: (locked)
Output 1 Output Name: CmdStart
Stopped: Unchecked (locked)
Running: Checked (locked)
Initial control mode: Manual (locked)
Control tracking: (locked)

See the next page for Detailed Lab Instructions

 Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the
Summary Lab Instructions on the previous page(s).

Create the Valve Template

1 Expand the Application toolset in the Template Toolbox.

2 Right-click the $DiscreteDevice template and select New / Derived Template to create a derived template of the
$DiscreteDevice object.

3 Name the new template $Valve and move it to the Training template toolset.

4 Double-click the $Valve template to open its configuration editor.

5 Configure the General tab as follows: Enable inputs: Checked (locked) Enable outputs: Checked (locked)

 
6. Configure the States tab as follows:   
Enable second active state: Unchecked (locked)
Enable transition state: Checked (locked)
State names: (locked)
Passive state: Closed
First Active state: Open
Transition state: Traveling
Fault state: Fault

 
7. Configure the Inputs tab as follows:   

Number of Inputs: 2 (locked)

Input Name: (locked)
Input 2 Input CLS
Name:
Input 1 Input OLS
Name:
Input to PV Map: (locked)
0 0: Traveling
0 1: Open
1 0: Closed
1 1: Fault
PV override: (locked)
 
8. Configure the Outputs tab as follows:

Number of outputs: 1 (locked)

Output Name: (locked)
Output 1 Output Name: CmdOpen
Closed: Unchecked (locked)
Open: Checked (locked)
Initial control mode: Manual (locked)
Control tracking: (locked)

9. Click the Save and Close button and check in the object.

 
Create the Pump Template
10. Right-click the $DiscreteDevice template in the Template Toolbox and select New / Derived Template to create a
derived template of the $DiscreteDevice object.

11. Name the new template $Pump and move it to the Training template toolset.

12. Double-click on the $Pump template to open its configuration editor.

13. Configure the General tab as follows:

Enable inputs: Checked (locked)
Enable outputs: Checked (locked)

 
14. Configure the States tab as follows:
Enable second active state: Unchecked (locked)
Enable transition state: Unchecked (locked)
State names: (locked)
Passive state: Stopped
First Active state: Running
Fault state: Fault

15. Configure the Inputs tab as follows:

Number of Inputs: 1 (locked)
Input Name: (locked)
Input 1: Input Name: FlowSwitch
Input to PV Map: (locked)
0: Stopped
1: Running
PV override: (locked)

 
16. Configure the Outputs tab as follows:
Number of outputs: 1 (locked)
Output Name: (locked)
Output 1 Output Name: CmdStart
Stopped: Unchecked (locked)
Running: Checked (locked)
Initial control mode: Manual (locked)
Control tracking: (locked)

17. Click the Save and Close button and check in the object.
Create the Motor Template
18. Right-click the $DiscreteDevice template in the Template Toolbox and select New / Derived Template to create
a derived template of the $DiscreteDevice object.
19. Name the new template $Motor and move it to the Training template toolset.

20. Double-click on the $Motor template to open its configuration editor.

21. Configure the General tab as follows:
Enable inputs: Checked (locked)
Enable outputs: Checked (locked)

 
22. Configure the States tab as follows:
Enable second active state: Unchecked (locked)
Enable transition state: Unchecked (locked)
State names: (locked)
Passive state: Stopped
First Active state: Running
Fault state: Fault

23. Configure the Inputs tab as follows:

Number of Inputs: 1 (locked)
Input Name: (locked)
Input 1 Input Name: AuxContact
Input to PV Map: (locked)
0: Stopped
1: Running
PV override: (locked)

 
24. Configure the Outputs tab as follows:

Number of outputs: 1 (locked)

Output Name: (locked)
Output 1 Output Name: CmdStart
Stopped: Unchecked (locked)
Running: Checked (locked)
Initial control mode: Manual (locked)
Control tracking: (locked)

25. Click the Save and Close button and check in the $Motor template.
Section 6 – Containment
Section Objectives
This section illustrates the concept of containment and how it works with Application Objects and Templates.

This section illustrates the concept of containment and how it works with Application Objects and Templates.

Creating Contained Templates

Containment is the relationship in which one object includes another. Containment relationships organize objects in a
hierarchy. You can build objects that represent complex devices consisting of smaller, simpler devices.
In scripts, these objects can be referred to by the name that derives from the containment relationship. This name
is called a hierarchical name.
An object can have three kinds of names, depending on if it is contained by another object. The three names include:
 Tagnames
 Contained Name
 Hierarchical Name

Name Description
Tagname The unique name of the individual object. For example, Valve1.
Contained Name The name of the object within the context of its container object. For example, the
object whose Tagname is Valve1 may also be referred to as Tank1.Outlet, if Tank1
contains it and it has the contained name "Outlet".
Hierarchical Name Hierarchical names that are fully-qualified names of a contained object include the
name of the objects that contain it.

Since the object that contains it may also be contained, there are potentially multiple
hierarchical names that refer to the same object.

For example, if:

“Reactor1” contains Tank1 (also known within Reactor1 by its contained name
“SurgeTank”).

"Tank1" contains Valve1 (also known within Tank1 by its contained name "Outlet").

Valve1 could be referred to as:

"Valve1"
"Tank1.Outlet"
"Reactor1.SurgeTank.Outlet".
For example, an instance of a $Tank is named Tank01. An instance of $Valve called Valve01 is contained within the
instance of $Tank.
Change the contained name of Valve01 to InletValve. Now Valve01 can also be referred to by its hierarchical name
Reactor1.InletValve. The name of the contained object can be changed, though, within the scope of the hierarchy.
Contained names can be up to 32 alphanumeric or special characters. The second character cannot be $ and the name
must include at least one letter. You cannot use spaces.

Note: Base templates cannot be contained by another template, either as the container or as the template being contained.
You can only use containment with derived templates.

Higher level objects contain lower level objects. This allows you to more closely model complex plant equipment, like tank
systems. You can nest templates to 10 levels.

Note: Objects can only contain objects like themselves. For example, ApplicationObjects can only be contained by other
ApplicationObjects. Areas can only contain other Areas.

ApplicationObject Containment
ApplicationObjects can be contained by other ApplicationObjects. This provides context for the contained object and a
naming hierarchy that provides a powerful tool for referencing objects.

Note: Base templates cannot be contained by another template, either as the container or as the template being contained.
You can only use containment with derived templates.
An example of a containment hierarchy is a tank that contains the following objects:
 Inlet Valve
 Agitator
 Outlet Valve
 Level
To enable referencing and flexibility within scripting, these objects can be referenced in several different ways. Each object
has a unique Tagname, such as:
 Inlet Valve = InletValve01
 Agitator = Agitator01
 Outlet Valve = OutletValve01
 Level = Level01
Within the context of each hierarchy, the contained names are unique, in that the names only refer to this tank system and
the contained objects.
So if the tank is named Tank01, the contained names are:
 Tank01.Inlet
 Tank01.Agitator
 Tank01.Outlet
 Tank01.Level

Additionally, you can use containment references in scripts such as:

 Me.Outlet: Allows a script running within the parent object to generically reference its child outlet instance.
 MyContainer.Inlet: Allows a script running in any of the children instances to reference another child instance
named Inlet that belongs to the same parent.
Renaming Contained Objects
Before you rename a contained name of an object, make sure that the object is not checked out to another user or
currently deployed.
The new contained name must comply with naming restrictions. Template names can be up to 32 alphanumeric or special
characters, including the required $ as the first character. The second character cannot be $ and the name must include at
least one letter. You cannot use spaces.
Contained names also cannot be the same contained name as an existing contained object within the same level of
hierarchy in the containment relationship.

Note: Be careful renaming contained objects. References from other objects to the object being renamed are not
automatically updated with the new name. You must update the references. Objects with broken references receive bad
quality data at run-time.

To rename an object's contained name

1. Select the object in an Application view.
2. On the Edit menu, click Rename Contained Name.
3. Type a new contained name. All IDEs connected to the Galaxy show the object's new contained name.

Containment and the Derivation View

The Derivation View does not show containment relationships. It shows templates and instances with regard to
containment in the follow ways:
 Non-contained instances show their tagnames.
 Contained instances show their tagnames and hierarchical names.
 Non-contained templates show their object name.
 Contained templates show their hierarchical name.

Containment of instances is limited to Areas containing other Areas and AppObjects containing other AppObjects.
Renaming can be done on an instance's tagname and contained name. A template only has a template name.
Lab 11 – Creating the Mixer
Introduction
This lab uses the templates created in Labs 9 and 10 to create dedicated templates for each of the Mixer’s
components identified in Lab 2. Using the $UserDefined template to create a template for the mixer itself, you
will use object containment to integrate all the pieces together and build the “mixer system”.

Objectives
Upon completion of this lab you will be able to:
 Create and configure a containment relationship between objects.
 Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Create the Mixer template

a. Derived a new template from the $UserDefined object, name it $Mixer, and assign it to the Training template toolset.

Create the Mixer’s Valves Templates

b. Derived three new templates from the $Valve object, name them $Inlet1, $Inlet2 and $Outlet, and assign them to the
$Mixer template.

Create the Mixer’s Pumps and Agitator templates

c. Derived two new templates from the $Pump object, name them $Pump1 and $Pump2, and assign them to the $Mixer
template.
d. Derived a new templates from the $Motor object, name it $Agitator, and assign it to the $Mixer template.

Create the Level and Temperature Meter Templates

e. Derived a new template from the $Meter object, name it $LIT, and assign it to the $Mixer template. Configure the
object as follows:
Engineering units: Liters (locked)
EU value Minimum: 0.0 (locked)
EU value Maximum: 100.0 (locked)
EU range value Minimum: -5.0 (locked)
EU range value Maximum: 105.0 (locked)

f. Derived a new template from the $Meter object, name it $TT, and assign it to the $Mixer template. Configure the
object as follows:
Engineering units: Celsius (locked)
EU value Minimum: 0.0 (locked)
EU value Maximum: 250.0 (locked)
EU range value Minimum: -5.0 (locked)
EU range value Maximum: 255.0 (locked)

Create a Mixer Instance

g. Create an instance of the $Mixer template (leave the default name) and assign it to the Line1 area.

 
h. Configure the input and output references for the contained objects as follows
where XX is your student number.

i. Deploy the object.

 
View the Mixer Data in Runtime
j. Open Object Viewer from within the ArchestrA IDE and, using the watch list created previously, add a new watch
window called Mixer and add the following attribute references:

k. Save the watch list.

See the next page for Detailed Lab Instructions

 Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Create the Mixer Template

1. Expand the Application toolset in the Template Toolbox.
2. Right-click the $UserDefined object and select New / Derived Template to create a derived template of the
$UserDefined object.
3. Name the new template $Mixer and move it to the Training template toolset.

Create the Mixer’s Valves Templates

4. Right-click the $Valve object in the Training template toolset and select New / Derived Template to create a derived
template of the $Valve object.
5. Name the new template $Inlet1.
6. Move $Inlet1 to the $Mixer template to contain it within the $Mixer object.
Notice the $ in $Inlet1 is automatically removed, indicating it is a template contained within another template.

7. Right-click the $Valve object in the Training template toolset and select New / Derived Template to create a derived
template of the $Valve object.

 
8. Name the new template $Inlet2.
9. Move $Inlet2 to the $Mixer template to contain it within the $Mixer object.
10. Create a new derived template of the $Valve object and name it $Outlet.
11. Move $Outlet to the $Mixer template to contain it within the $Mixer object.

The Training template toolbox should now look like the following:

Create the Mixer’s Pumps and Agitator templates

12. Derive the following templates from the $Pump object, containing them within the $Mixer object:
 Pump1
 Pump2

The Training template toolbox should now look like the following:

13. Derive the following template from the $Motor object, containing it within the $Mixer object:
 Agitator

 
The Training template toolbox should now look like the following:

Create the Level and Temperature Meter Templates

14. Derive the following template from the $Meter object, containing it within the $Mixer object:
 LIT

The Training template toolbox should now look like the following:

15. Double-click the $Mixer.LIT template to open its configuration editor.

 
16. Configure the General tab as follows:
Engineering units: Liters (locked)
EU value Minimum: 0.0 (locked)
EU value Maximum: 100.0 (locked)
EU range value Minimum: -5.0 (locked)
EU range value Maximum: 105.0 (locked)

17. Click the Save and Close button and check in the object.

18. Derive the following template from the $Meter object, containing it within the $Mixer object:
 TT

19. Double-click the $Mixer.TT template to open its configuration editor.

 
   
20. Configure the General tab as follows:

Engineering units: Celsius (locked)

EU value Minimum: 0.0 (locked)
EU value Maximum: 250.0 (locked)
EU range value Minimum: -5.0 (locked)
EU range value Maximum: 255.0 (locked)

21. Click the Save and Close button and check in the object.
Create a Mixer Instance
22. Using the Template Toolbox and the Model view, create an instance of the $Mixer template using the default
name of Mixer_001.

23. Assign the instance to the Line1 area.

Configure the Agitator

24. Double-click the Agitator_001 instance.

The Agitator_001 configuration editor appears.

25. Select the Inputs tab.
26. Click the Browse Galaxy button after Input Source Reference.

 
27. From the InControl Instance, select the tagname.T1XX_AG_AuxContact attribute, where XX is your
student number.
00 is used in the following examples.

28. Click OK.

29. Select the Outputs tab.

30. Click the ellipsis to configure the Output Destination Reference.

31. From the InControl Instance, select the tagname.T1XX_AG_CmdStart attribute, where XX is your student
number.

32. Click OK.

The attribute reference appears in the Output Destination Reference:

33. Click the Save and Close button and check in the object.
Configure Inlet1
34. Double-click the Inlet1_001 instance to open its configuration editor.
35. Select the Inputs tab and configure the Input Source Reference as follows, where XX is your student
number.

Input Name Instance Attribute

Input 2: CLS InControl tagname.T1XX_IV1_CLS
Input 1: OLS InControl tagname.T1XX_IV1_OLS

 
36. Select the Outputs tab and configure the Output Destination Reference as follows, where XX is your
student number.

Output Name Instance Attribute

Output 1: CmdOpen InControl tagname.T1XX_IV1_CmdOpen

37. Click the Save and Close button and check in the object.
Configure Inlet2
38. Double-click on the Inlet2_001 instance to open its configuration editor.
39. Select the Inputs tab and configure the Input Source Reference as follows, where XX is your student
number.

Input Name Instance Attribute

Input 2 : CLS InControl tagname.T1XX_IV2_CLS
Input 1: OLS InControl tagname.T1XX_IV2_OLS
40. Select the Outputs tab and configure the Output Destination Reference as follows, where XX is your
student number.

Output Name Instance Attribute

Output 1: CmdOpen InControl tagname.T1XX_IV2_CmdOpen

41. Click the Save and Close button and check in the object.
Configure LIT
42. Double-click the LIT_001 instance to open its configuration editor.
43. Select the I/O tab and configure the PV input source as follows, where XX is your student number.

Instance Attribute
InControl tagname.T1XX_LT_PV

44. Click the Save and Close button and check in the object.
Configure Outlet
45. Double-click on the Outlet_001 instance to open its configuration editor.
46. Select the Inputs tab and configure the Input Source Reference as follows, where XX is your student
number.

Input Name Instance Attribute

  Input 2: CLS InControl tagname.T1XX_OV_CLS
  Input 1: OLS InControl tagname.T1XX_OV_OLS
 

 
47. Select the Outputs tab and configure the Output Destination Reference as follows, where XX is your
student number.

Output Name Instance Attribute

Output 1: CmdOpen InControl tagname.T1XX_OV_CmdOpen

48. Click the Save and Close button and check in the object.
Configure Pump1
49. Double-click on the Pump1_001 instance to open its configuration editor.
50. Select the Inputs tab and configure the Input Source Reference as follows, where XX is your student number.

Input Name Instance Attribute

Input 1: FlowSwitch InControl tagname.T1XX_TP1_FlowSwitch
51. Select the Outputs tab and configure the Output Destination Reference as follows, where XX is your
student number.

Output Name Instance Attribute

Output 1: CmdStart InControl tagname.T1XX_TP1_CmdStart

52. Click the Save and Close button and check in the object.
Configure Pump2
53. Double-click on the Pump2_001 instance to open its configuration editor.
54. Select the Inputs tab and configure the Input Source Reference as follows, where XX is your student
number.

Input Name Instance Attribute

Input 1: FlowSwitch InControl tagname.T1XX_TP2_FlowSwitch
55. Select the Outputs tab and configure the Output Destination Reference as follows, where XX is your
student number.

Output Name Instance Attribute

Output 1: CmdStart InControl tagname.T1XX_TP2_CmdStart

56. Click the Save and Close button and check in the object.
Configure TT
57. Double-click on the TT_001 instance to open its configuration editor.
58. Select the I/O tab and configure the PV input source as follows, where XX is your student number.

Instance Attribute
InControl tagname.T1XX_TT_PV

59. Click the Save and Close button and check in the object.

Deploy the Object

60. Select the Deployment view, right-click the Mixer_001 instance and select Deploy.
The Deploy dialog box displays. By default the system will Cascade Deploy 9 objects in the containment
relationships and set all instances On Scan as soon as the objects are deployed.

61. Leave the default settings and click OK.

A second Deploy dialog box displays indicating the progress on deploying all 9 objects. As soon as the process
is complete, the Close button will be enabled.

62. Click Close.

View the Mixer Data in Runtime

63. Right-click on the Mixer_001 instance and select View in Object Viewer. If you closed Object Viewer
before, you can use File / Load Watch List to open the file you saved earlier.

64. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add
a new tab to the watch list.

65. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the
watch list to Mixer.
66. Using the Object List (left section of Object Viewer) and the Attribute List (right section of Object
Viewer), locate and add the following attributes to the selected watch list by right-clicking on each
attribute and selecting Add to Watch:

Object List Attribute List

Agitator_001 Cmd
PV
Inlet1_001 Cmd
PV
Inlet2_001 Cmd
PV
LIT_001 PV
Outlet_001 Cmd
PV
Pump1_001 Cmd
PV
Pump2_001 Cmd
PV
TT_001 PV

67. Right-click in the Watch List (bottom section of Object Viewer) and select Save to save the watch list.
MODULE 4
Extending the Objects

Section 1 – UDAs
Section 2 – Extensions
Lab 12 – Configuring the Motor Speed
Section 3 – Introduction to QuickScript .NET
Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient
Lab 14 – Configuring Automatic Reference

Module Objectives
 Be able to work with extending the objects and configuring them for additional functionality.
Section 1 – UDAs
Section Objective
This section introduces and explains UDAs and how they are configured and used.

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:
• 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: 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.
You can add UDAs to a template or an instance. When you add a UDA to a template, the UDA, its data type, and category
are automatically locked in the child instances.
If UDA parameters such as initial values and security classifications are locked in the template, they cannot be changed in
child instances. If these parameters are unlocked in the template, the initial value and security are editable and lockable in
derived templates. When unlocked in either the base or derived template, the value is editable in instances.
After you add an attribute to an instance, it appears in the Attribute Browser list for use with the scripting and attribute
extension functions.
The UDAs page is comprised of three main functional areas and a set of function buttons. These are described
below.

The main areas of the UDAs page include:

 UDAs list: Lists all UDAs currently associated with the object. Click the Add button to add a new UDA.
 Inherited UDAs list: Lists all UDAs associated with the object's parent. The object automatically
includes these UDAs. They can only be edited by modifying the parent template.
 Data type list: Shows the data type options for configuring the selected UDA.

Select from the data types Boolean, Integer, Float, Double, String, Time, ElapsedTime or
InternationalizedString.
Allowed categories are Calculated, Calculated retentive, Object writable and User writeable. You can lock
writable attributes. If you select Calculated for an attribute, only scripts running on the same object can write to
the attribute.
You can create an array for each data type except InternationalizedString. Select This is an array and
specify the array's length in the Number of elements box.
The Value parameter specifies the initial setting for the attribute when the object is deployed. Enter value data
for each data type. In the case of a non-arrayed Boolean, select the True/False check box to use a True value.
Clear the check box to use a False value. For an arrayed Boolean, select the desired element and provide a
default value by typing either true or false.
When using UDAs in scripting, note the following:
 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.
Section 2 – Extensions

Section Objective
This section describes the Output Functionality for Application Objects in the Extensions environment.

Extensions
The Extensions page is comprised of seven main functional areas, described next.

The main functional areas of the Extensions page include:

 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.
 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.
 Boolean Label Extension: Specify custom text strings for the False state and the True state. These
custom text strings appear in the Active alarm state list in the Alarm extension area for you to select.
If you are using the InTouch HMI, you can see these custom text strings in InTouch.

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 clicking the
attribute browser button at right. Use the Attribute Browser dialog box to search 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 clicking
the attribute browser button at right. Use the Attribute Browser dialog box to search 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. For Boolean Extensions, 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.

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.

In other words, for Boolean data types and User sets, the following examples apply:

Previous Scan Scan Cycle Set Next Value to be

Value to be Sent
Cycle Value Sent Requests Sent
0 1,0,0,1,1 1 none
1 1,0,0,1,1 0 1
0 1,1,0,0 1 0
1 1,1,0,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.
Lab 12 – Configuring the Motor Speed
Introduction
In Lab 2, you identified that the motors, such as the agitator in the mixer, have a signal that indicates the speed
of the motor when it is running, and that this speed has a setpoint associated with it to specify the desired speed
for the process.
When you created the $Motor template in Lab 10 using the $DiscreteDevice, it was explained that this object
does not include, by default, attributes that can be used to indicate the speed of the motor.
In this lab the $Motor template is modified by adding the attributes and functionality necessary to include the
speed data (and its setpoint) as identified in Lab 2.

Objectives
Upon completion of this lab you will be able to:
• Add and configure UDAs to your objects
• Extend attributes with input and output functionality
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please
refer to the Detailed Lab Instructions on subsequent pages.

Add and Extend the UDAs

a. Add two Float UDAs to the $Motor template: one Object writeable named Speed, and another one User
writeable named SpeedSP.
b. Extend the Speed attribute with an Input extension and configure its Source as ---.---.
c. Extend the SpeedSP attribute with an InputOutput extension and configure its Source as ---.---. Leave
Output destination differs from input source unchecked and lock it.

Configure the Agitator Instance

d. Configure the newly added UDAs in the Agitator_001 object as follows:

Extendable Attribute Instance Attribute

Speed.InputSource InControl tagname.T1XX_AG_Speed
SpeedSP.InputSource InControl tagname.T1XX_AG_SpeedSP

View the Agitator Speed Data in Runtime

e. Deploy the object and open Object Viewer from within the ArchestrA IDE.
f. Using the watch list created in Lab 5, add a new watch window named Extensions with the following
attributes from the Agitator_001 instance:
 PV
 Cmd
 Speed
 SpeedSP
g. Set the SpeedSP attribute to any valid float value to test it.
h. Save the watch list.

See the next page for Detailed Lab Instructions

 Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the
Summary Lab Instructions on the previous page(s).

Add and Extend the UDAs

1. Double-click the $Motor template to open its configuration editor.

2. Select the UDAs tab.

3. Click the button to add a UDA to the object.

4. Name the UDA Speed and press Enter.

5. Configure the Speed UDA as follows:

Data type: Float

Category: Object writeable

 
6. Click the button to add another UDA named SpeedSP to the object and configure it as follows:

Data Type: Float

Category: User writeable

7. Select the Extensions tab.

8. Select the Speed attribute.
9. Configure the Speed Attribute Input extension as follows, where XX is your student number. 00 is used in
the following examples.

Input extension: checked Source: ---.---

10. Select the SpeedSP attribute.
11. Configure the SpeedSP Attribute Input extension as follows, where XX is your student number. 00 is
used in the following examples.

InputOutput extension: checked

Source: ---.---
 
Output destination differs unchecked (locked)
  from input source:
 

 
 

12. Click the Save and Close button and check in the object.
Configure the Agitator Instance
13. Double-click on the Agitator_001 instance to open its configuration editor.
14. Select the Extensions tab.
15. Select the Speed attribute.
16. Configure the Speed Attribute Input extension as follows, where XX is your student number. 00 is used
in the following examples.
17. Select the SpeedSP attribute
18. Configure the InputOutput extension for the SpeedSP attribute as follows, where XX is your student
number.

19. Click the Save and Close button and check in the object.

View the Agitator Speed Data in Runtime

20. Deploy the Agitator_001 object, using the default settings in the Deploy window.
21. Open Object Viewer by right-clicking the Agitator_001 instance and selecting View in Object Viewer.
If you closed Object Viewer before, you can use File / Load Watch List to open the file you saved
earlier.
22. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add
a new tab to the watch list.
23. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the
watch list to Extensions.

24. Add the following Agitator_001 attributes to the watch list:

 Cmd
 PV
 Speed
 SpeedSP

25. Double-click the SpeedSP attribute to open the Modify Numeric Value window.

26. Set the SpeedSP attribute to any valid float value. In this example, 50 is used.

When the Agitator_001 is running the Speed attribute will indicate the actual speed of the motor around the
SpeedSP (speed setpoint).
27. Save the watch list.
Section 3 – Introduction to QuickScript .NET

Section Objective
This section introduces and explains the scripting environment and the various scripting configuration attributes of the
ApplicationObject.

 
Scripts Page
The Scripts page has six areas.
The main areas of the Scripts page include:
 Scripts list: Shows all scripts currently associated with the object. The columns indicate which kind of
trigger the script uses: Startup, On Scan, Execute, Off Scan and Shutdown. Click the Add button to add
a new script.
 Inherited scripts name list: Shows all scripts associated with the object's parent. The columns indicate
which kind of trigger the script uses: Startup, On Scan, Execute, Off Scan and Shutdown.
 Configure Execution Order: Sets the execution order of multiple scripts (inherited and local)
associated with this object.
 Aliases area: Lets you create and modify aliases that apply to the script you are working on. Aliases are
logically descriptive names for typically long ArchestrA reference strings that you can use in the script to
make the script more readable.
 Declarations area: Provides a place to add variable declaration statements, such as DIM MyArray[1] as
FLOAT;. These declared variables live from the startup to the shutdown of the object and can be used to
hold values that persist from one execution of the script to the next. They apply only to the script in
which they are declared.
 Basics area: Provides a location in which you set the expression, triggering conditions, and other
settings that run the script in the run-time environment. This area includes:
 Script State: Select to send the state of the script to a Wonderware Historian Server historian, the
ArchestrA historian.
 Script Editor box: Shows the script you are writing.

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 off-engine 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.
Similar to browsing for script functions, the user can also browse for .NET / COM objects that have
been imported using the ArchestrA IDE.

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.

 
Script Execution Types
A script is added to an Object (template or instance) using the ArchestrA IDE. The script related information is
edited via the script editor. The editor exposes five script types:

Startup
Called when the object is loaded into memory (deployment, platform or engine start). This script method is
intended to be used to instantiate COM objects and .NET objects. Depending on load and other factors, it may
be possible that sets to object attributes from this script method may fail. Attributes that reside off-object are not
available to this script method. Therefore it is not recommended to use this script method for any scripting
beyond its intended use.
OnScan
Called the first time an AppEngine calls this object to execute after the object scan state is changed to OnScan.
This script method is intended to be used to initiate local object attribute values, or to provide more flexibility in
the creation of .NET or COM objects. Attributes that are off-engine are not available to this script method. It is
not recommended to use this script method for any scripting beyond its intended use.
Execute
Called every time the AppEngine performs a scan and the object is OnScan.
The execute script method is the workhorse of the scripting methods. This is the place that runtime scripting
should be done to ensure that all attributes and values are available to the script. This script method in
analogous to the InTouch scripts with the following conditional trigger types:
 On True: Executes if the expression validates from a false on one scan to a true on the next scan.¹
 On False: Executes if the expression validates from a true on one scan to a false on the next scan.¹
 While True: Executes scan to scan as long as the expression validates as true at the beginning of the
scan.¹,²
 While False: Executes scan to scan as long as the expression validates as false at the beginning of the
scan. ¹,²
 Periodic: Executes whenever the elapsed time evaluates as true.
 Data Change: Executes when there is a change in data from one scan to the next.

¹ Data changes between each scan are not evaluated, only the value at the beginning of each script is used for
evaluation purposes, in other words if a boolean attribute were to change from True to False to True again during
1 scan cycle, this change would not be evaluated as a data change as the value is True at the beginning of each
scan cycle.
² Time-based script considerations (a trigger period of 0 means that the script execute every scan).
 Time-based scripts, WhileTrue, WhileFalse, and Periodic are evaluated and executed based on the
elapsed time from a timestamp generated from the previous execution, not on an elapsed time counter.
Because of this it is possible that a change in the system clock can result in the interval between
execution of these script to be off.
For example, a periodic script is set to run every 60 minutes. The script executes at 11:13 am, therefore
we would expect it to execute 60 minutes later at 12:13 PM. However, let's assume that a time sync
event has occurred and the node's time is adjusted from 11:33 am to 11:30 am. The script will still
execute when the system time reaches 12:13 PM. But because of the time change the actual (True)
time period that has elapsed between executions is 63 minutes.

Quality changes
When the DataChange Trigger type is selected, the Quality changes checkbox enables. Select this box to
trigger the script to run when the Quality of the Expression value changes. In this configuration the script will
run whether or not the Expression value changes.
Deadband
When the DataChange Trigger type is selected, Deadband specifies the amount the expression value must
change before the script is executed.
OffScan
Called when the object is taken OffScan. Primarily used to clean up the object and account for any needs that
should be addressed as a result of the object no longer executing.
Shutdown
Called when the object is about to be taken out of memory, usually as a result of the AppEngine stopping.
Primarily used to destroy COM objects and .NET objects and clean up memory.
Attribute References

Relevant References
References that go up the hierarchy to parent objects are called relative references.
Relative references, such as Me, are valid reference strings. A valid reference string must always contain at
least a relative reference or one substring. The following are valid relative references that refer to the current
object:
• Me
• MyContainer
• MyPlatform
• MyEngine
• MyArea

Relative references are especially useful in templates because absolute references typically do not apply or
make sense.
When you use relative references, like MyContainer, you can refer to contained objects within that container.
For example, a reference to MyContainer.InletValve.PV is equivalent to Tank1.InletValve.PV in the
following hierarchy:

Tank1 Cannot reference at this level because this is not contained

Inlet Valve (InletValve) Can reference at this level because this object is contained
Outlet Valve (OutletValve) Can reference at this level because this object is contained

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 of 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 attributes
reference> needs to be specified.
Example:
If me.PV==”Open” Then
{Do something}
Endif;
Using Aliases
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.
First the user has to specify an alias for an external reference (for example, 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 you 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: Let’s assume you need to read the Value property and the Dimension1 property of the external
attribute Valve101.PV. Let’s further assume that you want to use inline references. The corresponding code
snippet is:
A = Valve101.PV; {reads the Value property}B = Valve101.PV.Dimension1; {reads the
Dimension1 property}
The two references Valve101.PV and Valve101.PV.Dimension1 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
Tag.ArrayAttribute

UDAs and Scripting

When using UDAs in scripting, keep the following list in mind.
 If you use Calculated and Calculated retentive UDAs, they must be manually initialized. For example,
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 scripts with Execution type triggers of On Scan and Execute,
but not initialized in Startup scripts.

 Calculated retentive UDAs can be initialized nearly anywhere, however the advantage of initializing on
Startup is the StartingFromCheckpoint attribute can be evaluated. For example, a Calculated retentive
UDA retains the attribute’s current value after a computer restart, redundancy-related failover, or similar
situation in which valid checkpoint data is present. Your Startup script should contain a statement
testing the Boolean value of the StartingFromCheckpoint attribute on the object’s AppEngine. If the
value is TRUE, do not initialize the UDA. If the value is FALSE, initialize the UDA.

Language Definition
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the case is
preserved throughout editor sessions.
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:
Dim A; ’This is a single line comment
Dim B; {This is an example of a multiline comment}
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.

 
QuickScript.NET Operations that Require 1 Operand
Operation Description
~ Complement
- Negation
NOT Logical NOT

QuickScript.NET 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

QuickScript.NET 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) (, )
2 - (negation), NOT, ~
3 **
4 * , /, MOD
5 +,
6 SHL, SHR
7 <, >, <=, > =
8 ==, <>
9 &
10 ^
11 |
12 =
13 AND
14 (lowest) OR
QuickScript.NET Variables
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.
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, let’s assume that your script accesses the hosting object’s PV attribute in the script text and you
declare ‘DIM PV AS Integer;’. Within the declaring script, expressions using ‘PV’ in a 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 VB’s 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).

Data Type
Default
(as specified in Comment
Value
AS <data_type>)
Boolean, Discrete False Discrete and Boolean are synonymous. Discrete is
still supported for migration from InTouch. True=1,
False=0
Integer 0 Signed –2147483648 to 2147483647
Float, Real NaN Float and Real are synonymous. Real is still
supported for migration from InTouch. For range
information please refer to Appendix
Double NaN For range information please refer to Appendix
String, Message “” (empty Maximum length defined by BSTR (2147483647)
string)
Time 0 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 0 100 nanosecond ticks represents a time span.
Object Nothing Leveraged for accessing OLE Automation servers.

Indirect Datatype
The Indirect keyword supports dynamically binding a variable to an arbitrary reference string for get/set usage.
The syntax for this keyword, including the use of the method, BindTo(s), is show in the example below:
dim x as indirect;
...
x.BindTo(s); ' where s is any expression that returns a string
x = 1234;
if WriteStatus(x) == MxStatusOk then
' ... do something
endif;

QuickScript.NET Control Structures

QuickScript.NET provides four primary control structures in the scripting environment:
 IF ... THEN ... ELSEIF ... ELSE ... ENDIF
 FOR ... TO ... STEP ... NEXT Loop
 FOR EACH ... IN ... NEXT
 WHILE Loop
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
 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 Value = 0 evaluated as False Value != 0 evaluated as True
Double Value = 0 evaluated as False Value != 0 evaluated as True
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 Cannot be mapped. Using an expression that results in a time
type as the boolean_expression results in a script validation
error.
Object Cannot be mapped. Using an expression that results in an
object type as the boolean_expression results in a script
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 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 … 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:
 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.)
 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 exits. (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 .NET objects and 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:
 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: Collections are frequently leveraged by VB and VBA / JScript. Microsoft’s 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;
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.

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:
 boolean_expression is an expression that can be evaluated as a Boolean as defined above in the
description of IF…THEN 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.

Script Execution Error Handling

When the script execution engine experiences a script execution error the script’s 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:
 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 (for example,
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. For example, the script
infrastructure must attempt to release external objects or data base connections that were created by the script.
However, it can never be guaranteed that an aborted script has no negative side effects. For example, 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 (for example, 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
 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 pre-installed 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.

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 script’s data
as execution occurs.
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.}

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 result’s quality). The result value itself is set to the default value for the given data
type (for example, 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 (for example, 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: data time handling / propagation.

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. For example, 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 of 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 attribute’s 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.
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 of 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 user’s perspective it is easier if all the listed
cases are treated equally; i.e., the quality is ignored in all cases.

Time Propagation
Time propagation preserves the timestamp of process data obtained from source field devices like a
PLC or DAServer. The timestamp can be shown from visualization client applications like InTouch.
Also, timestamps are associated with the value and quality of data saved to the Wonderware
Historian.

Execution Mode
Execute 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 don’t meet the
above speed and determinism criteria. These scripts will be executed on a worker pool of separate,
lower priority threads than the Application Engine’s 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.
Only script code written for the Execute type of an object can be declared asynchronous.
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.
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 Threads

Threads are used for processing asynchronous scripts simultaneously when they are due and their trigger
condition is 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.

Asynchronous Scripts Diagnostics and Attributes

Asynchronous scripts require some additional attributes within the script to provide the following behavior:
 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 time-consuming 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).
 Asynchronous 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.

Script 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.
Support for .NET Constructs
QuickScript .NET is built on top of .NET and supports the following .NET constructions in its
syntax:
 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.

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:
Support for COM Servers:
 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, early-bound methods on
Dim app as Excel.Application;
App = new Excel.Application;

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 late-bound objects. Late-bound
methods on app can be called after the object is created.

dim app as object;

app = CreateObject(“Excel.Application”);

 
Script Examples
The following script examples may be used for reference.

Note: Many additional script examples may be located in the ArchestrA IDE Help files under Enhancing an
Object’s 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=northwind"
);
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"")]");
Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient
Introduction
The $DDESuiteLinkClient object lacks the capability to automatically reconnect to the data source if the
connection is lost, therefore in this lab you will extend the object with UDAs and scripts to add reconnection
functionality.
You will also add additional diagnostic information to the $DDESuiteLinkClient object through a UDA/script
combination that will indicate the number of disconnects the object has experienced since it last went on scan.

Objectives
Upon completion of this lab you will be able to: Use the QuickScript.NET scripting engine to extend your objects with extra
functionality
• Use attributes, including UDAs, within scripts
• Create scripts with different execution types
• Reconnect whenever the InControl object gets disconnected
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Add the auto-reconnect functionality

a. Add a script called Reconnect (locked) to the $tDDESuiteLinkClient with an Execute execution type configured
as follows:

Expression: Me.ConnectionStatus <> 2

Trigger type: WhileTrue
Trigger period: 00:00:05.0000000
Script body:
Me.Reconnect = True;

b. Add a Calculated Integer UDA named DisconnectCnt.

c. Add a script called DisconnectMonitor (locked) with an Execute execution type configured as follows:

Expression: Me.ConnectionStatus <> 2

Trigger type: OnTrue
Script body:
Me.DisconnectCnt = Me.DisconnectCnt + 1;
and an OnScan execution type configured as follows:
Script body:
Me.DisconnectCnt = 0;
d. Deploy the InControl object

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Add the Auto-reconnect Functionality

1. Double-click the $tDDESuiteLinkClient template to open its configuration editor.
2. Select the Scripts tab.

3. Click the button to add a new script to the object. Name the script Reconnect and configure it as follows:

Aliases section: (locked)

Declarations section: (locked)
Scripts section:
Execution type: Execute (locked)
Basics section: (locked)
Expression: Me.ConnectionStatus <> 2
Trigger type: WhileTrue
Trigger period: 00:00:05.0000000
Script body section: Me.Reconnect = True;

The purpose of this script is to monitor the ConnectionStatus attribute of the object every 5 seconds. As long as the
connection status is equal to something other than 'Connected' (A value of 2 signifies ‘Connected’), the script will tell the
object to attempt a reconnect.
 4. Select the UDAs tab.

5. Click the button to add a UDA to the object. Name the UDA DisconnectCnt and configure it as follows:

Data type: Integer

Category: Calculated

The DisconnectCnt attribute is a counter that will keep track of how many times the object disconnects. This attribute value
will be updated via a script, defined next.
6. Select the Scripts tab.
7. Click the button to add a new script to the object. Name the script DisconnectMonitor and configure it as
follows:
Aliases section: (locked)
Declarations section: (locked)
Scripts section:
Execution type: Execute (locked)
Basics section: (locked)
Expression: Me.ConnectionStatus <> 2
Trigger type: OnTrue
Script body section: Me.DisconnectCnt = Me.DisconnectCnt + 1;

This script monitors the connection status of the object. Every time it changes from a 'Connected' status to a
non-connected status ('Disconnected' or 'Mixed'), it increments the count (DisconnectCnt attribute).
8. Select the DisconnectMonitor script
9. Select an Execution type of OnScan to add a second section to the script.

10. Configure the script as follows: Script body section:

Me.DisconnectCnt = 0;

This script will initialize (set to zero) the DisconnectCnt attribute when the object goes on scan.
11. Click the Save and Close button and check in the object.
12. Deploy the InControl instance, accepting the defaults in the Deploy dialog box.
Lab 14 – Configuring Automatic Reference
Introduction
This lab illustrates how to add to the mixer objects the capability of automatically configuring the input and
output references within the objects based on the naming conventions established for your galaxy.
To successfully provide this functionality, a compromise regarding the naming of the objects has to be arranged.
In this example, it is required that every instance derived from the $Mixer template is named with the valid
three-digit mixer identification number at the end as identified in Lab 2.

Objectives
Upon completion of this lab you will be able to:
 Use the QuickScript.NET scripting engine to automatically configure on runtime the input and output references of
instances
 Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Add the auto-configuration functionality

a. Add a script to the $Mixer template called AssignIO (locked) with an OnScan execution type.
b. In the AssignIO script body, add the Lab 14 - Configuring Automatic Reference.txt script located in the
Wonderware Training folder.
c. Lock the Aliases and Declarations sections.

Modify the Mixer instance, create and deploy a new Mixer instance
d. Undeploy the Mixer_001 instance and change its name to Mixer_1XX.
e. Create a new instance of the $Mixer template named Mixer_2XX and assign it to the Line2 area.
f. Deploy both instances of the mixer.
g. Using the watch list created in Lab 5, verify configuration of Mixer 1and its contained Objects using the Mixer tab in
Object Viewer.
h. Rename the Mixer tab in Object Viewer, naming it Mixer 1.
i. Add a new watch window named Mixer 2 with the following attributes to verify configuration of Mixer 2 and its
contained Objects.

Object List Attribute List

Agitator_002 Cmd
PV
Inlet1_002 Cmd
PV
Inlet2_002 Cmd
PV
 
LIT_002 PV
Outlet_002 Cmd
PV
Pump1_002 Cmd
PV
Pump2_002 Cmd
PV
TT_002 PV

See the next page for Detailed Lab Instructions

 
Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Add the Auto-configuration Functionality

1. Double-click the $Mixer template to open its configuration editor.

2. In the Scripts tab, click the button to add a new script to the object. Name the script AssignIO and
configure it as follows:

Aliases section: (locked)

Declarations section: (locked)

Scripts section:
Execution type: OnScan (locked)
Script body section: Lab 14 - Configuring Automatic Reference.txt script located in the Wonderware
Training folder.

'Get the common part for the references.

Dim dataSource As String;
dataSource = "InControl.tagname.T" + StringRight(Me.Tagname, 3);

'Configure inlet valve 1.

Me.Inlet1.CLS.InputSource = dataSource + "_IV1_CLS";
Me.Inlet1.OLS.InputSource = dataSource + "_IV1_OLS";
Me.Inlet1.CmdOpen.OutputDest = dataSource + "_IV1_CmdOpen";

'Configure inlet valve 2.

Me.Inlet2.CLS.InputSource = dataSource + "_IV2_CLS";
Me.Inlet2.OLS.InputSource = dataSource + "_IV2_OLS";
Me.Inlet2.CmdOpen.OutputDest = dataSource + "_IV2_CmdOpen";

'Configure outlet valve.

Me.Outlet.CLS.InputSource = dataSource + "_OV_CLS";
Me.Outlet.OLS.InputSource = dataSource + "_OV_OLS";
Me.Outlet.CmdOpen.OutputDest = dataSource + "_OV_CmdOpen";

'Configure transfer pump 1.

Me.Pump1.FlowSwitch.InputSource = dataSource + "_TP1_FlowSwitch";
Me.Pump1.CmdStart.OutputDest = dataSource + "_TP1_CmdStart";

'Configure transfer pump 2.

Me.Pump2.FlowSwitch.InputSource = dataSource + "_TP2_FlowSwitch";
Me.Pump2.CmdStart.OutputDest = dataSource + "_TP2_CmdStart";

'Configure level meter.

Me.LIT.PV.Input.InputSource = dataSource + "_LT_PV";

'Configure temperature transmitter.

Me.TT.PV.Input.InputSource = dataSource + "_TT_PV";

'Configure agitator.
Me.Agitator.AuxContact.InputSource = dataSource + "_AG_AuxContact";
Me.Agitator.CmdStart.OutputDest = dataSource + "_AG_CmdStart";
Me.Agitator.Speed.InputSource = dataSource + "_AG_Speed";
Me.Agitator.SpeedSP.InputSource = dataSource + "_AG_SpeedSP";
3. Click the Save and Close button and check in the object. Modify the Mixer instance, create and deploy a

Mixer instance
4. Right-click Mixer_001 and select Undeploy.

5. Click OK to confirm the Undeploy, retaining the default selections in the Undeploy dialog box.
6. Click Close when the Undeploy complete message displays.
7. Right-click Mixer_001 and select Rename.
8. Rename Mixer_001 to Mixer_1XX, where XX is your student number.

Note: When the mixer instance is renamed, a dialog box with a warning displays.

9. Click the Yes button.

10. Right-click the $Mixer template and choose New / Instance to create a new instance of the $Mixer template.
11. Rename the new instance Mixer_2XX, where XX is your student number.
12. Click Yes when the warning displays.
13. Assign Mixer_2XX to the Line2 area.
14. Click the button to expand the Mixer_2XX instance.

The new instance of the Mixer_2XX displays a warning icon on all contained objects.

Note: Warnings can be cleared by setting the default references from ---.--- to ---, or by using the Upload
Runtime Changes in the context menu after deployment to pull runtime I/O assignments to the configuration
interface.

15. Deploy the Mixer_1XX instance, accepting the default deployment settings.

16. Click Close when deployment is complete.

17. Deploy the newly created Mixer_2XX instance, accepting the default deployment settings.

18. Click Close when deployment is complete.

Verify configuration of Mixers and their contained Objects

18. Click Close when deployment is complete.

Verify configuration of Mixers and their contained Objects

19. Right-click on Mixer_1XX and select View in Object Viewer. If you closed Object Viewer before, you
can use File / Load Watch List to open the file you saved earlier.

20. Click the Mixer Watch List to verify that the contained objects data values are updating.

21. Right-click the Mixer Watch List and select Rename Tab to rename it to Mixer 1.

22. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add
a new tab to the watch list.

23. Right-click in the new Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the watch list to Mixer 2.
24. Using the Object List (left section of Object Viewer) and the Attribute List (right section of Object
Viewer), locate and add the following attributes for the Mixer_2XX instance to the selected Mixer 2 watch
list by right-clicking on each attribute and selecting Add to Watch:

Object List Attribute List

Agitator_002 Cmd
 
PV
Inlet1_002 Cmd
PV
Inlet2_002 Cmd
PV
LIT_002 PV
Outlet_002 Cmd
PV
Pump1_002 Cmd
PV
Pump2_002 Cmd
PV
TT_002 PV

25. Save the watch list.

 
MODULE 5
Alarms and History
Section 1 – Alarms
Lab 15 – Configuring Alarms
Section 2 – Historization
Lab 16 – Configuring History

Module Objective:
 Obtain an overview and understanding of the concepts of Alarms, Events and Historization and how
ArchestrA handles each.
Section 1 – Alarms
Section Objectives
• Familiarize you with the concept of alarms and events, and
• Enable you to understand how ArchestrA handles alarms and events.

This section provides familiarization of the concept of alarms and events and how ArchestrA handles them.

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:
 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:

 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:

 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.
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 InTouch’s
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 Application 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 (for example Alarm Type (string)
“PV.HiAlarm”)
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 AutomationObject’s 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 AutomationObject’s 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:

Security Audit (includes User Data Change) Events:

 
Application Data Change Events:
Alarm Queries
Alarm queries are used within alarm clients to retrieve real-time alarm information and event reports from the Galaxy.
The fully-qualified syntax of an alarm query to retrieve a single alarm within an object as reported by a specific WinPlatform
object is:
\\nodename\Galaxy!area!object.attribute

If the WinPlatform object that serves as an alarm provider is located in the local computer, the following syntax of the
alarm query is allowed:
\Galaxy!area!object.attribute

The following table lists different variants of the alarm query and their return data:

Alarm Query Results

\\nodename\Galaxy!area All alarms and events from the area object itself. All alarms and
events from all the objects hosted in the area. All alarms and
events from all subareas contained in the area as configured in
the Model View of the ArchestrA IDE. All alarms and events
from all the objects hosted in the contained areas.
\\nodename\Galaxy!area!area All alarms and events from the object itself.
\\nodename\Galaxy!winplatform All alarms and events from the WinPlatform object itself.
\\nodename\Galaxy!engine All alarms and events from the engine object (AppEngine or
ViewEngine) itself.
\\nodename\Galaxy!dio All alarms and events from the device integration object itself.

Use of Wildcard
The asterisk (*) is a wildcard character that may be used to substitute any character or characters in the
object.attribute part of the alarm query.
The following table lists different examples on the use of the wildcard character on alarm queries and their return data:

Alarm Query Results

\\nodename\Galaxy!area!object.* All alarms and events from a specific object within an
area.
\\nodename\Galaxy!area!*.attribute All alarms and events from all the objects in the area
for the specific attribute.
\\nodename\Galaxy!area!objectprefix* All alarms and events from objects whose name
begins with the specific prefix.

Only one wildcard character is allowed per alarm query.

Using Multiple Queries

Multiple queries can be submitted by an alarm client. For example, if Area1 an Area2 are two mutually exclusive areas, the
following two queries can be submitted at once:
\Galaxy!Area1 \Galaxy!Area2

By using multiple queries it is possible to retrieve alarms from different nodes (WinPlatform objects) at the same time, for
example:
\\NodeNameA\Galaxy!Area1 \\NodeNameB\Galaxy!Area2
General Attributes
Alarm Attributes
You can set individual alarms within an object for each type of alarm. For example, you can set alarms for each of the limits
of a level alarm. The calculated AlarmMode attribute value of an individual alarm uses the same inputs an object alarm.
The parent AlarmMode attribute is from the object itself. As with object alarms, the individual alarm mode is set to the most
restrictive input state. For example, if the object’s AlarmMode state is disabled and the individual alarm’s AlarmInhibit is
FALSE, the individual alarm is disabled.
Each individual alarm is autonomous from other individual alarms in an object. The AlarmMode of an individual alarm is not
propagated to other alarms. Unlike inhibit for the entire object, inhibit of an individual alarm does not affect the alarms of
any contained objects. You can selectively enable, silence, or disable an individual alarm and not set other alarms to the
same value within the object hierarchy.

Attribute Description
AlarmInhibit If TRUE, all alarms for the object are disabled. Typically written to by a script, user or
input extension. If an area, all alarms for objects in area are disabled. If a container, all
alarms for objects in container are disabled.
AlarmMode Indicates current alarm mode of object. The mode is based on the object's commanded
mode; if an area and container are enabled. Otherwise, the most disabled state of the
container or parent area applies. Disabled mode is considered the most disabled, then
Silenced and then Enabled.
AlarmModeCmd The currently commanded alarm mode of the object.
InAlarm Indicates whether any of the object's alarms are in the Active state. Can be true only
when the object is on scan and alarms are enabled.

 
Alarm Attributes
Attribute Description
<Attribute>.Acked Used to specify whether an alarm has been acknowledged. This
attribute is updated when the AckMsg attribute is set. This attribute is
always set to FALSE when a new alarm condition is detected (when
the InAlarm attribute changes from FALSE to TRUE).
<Attribute>.AckMsg The operator comment at the time the alarm is acknowledged. Any
received text is stored, and the Acked attribute is set to TRUE. Also,
the TimeAlarmAcked attribute is set to the current time. The maximum
length is 256 characters.
<Attribute>.AlarmMode The current alarm mode setting. Valid values are: Enable, Disable,
Silence.
<Attribute>.AlarmModeCmd The command to set the alarm mode. Valid values are: Enable,
Disable, Silence.
<Attribute>.Category The category of the alarm. The label of each alarm category is fixed.
<Attribute>.DescAttrName The description of the alarm. The description must be of type String or
InternationalizedString, with a maximum length of 329 characters. The
DescAttrName attribute can contain a static alarm description or a
reference to another string attribute within the same object containing
the alarm description. The reference must be in the form:
"me.AttrName". If the reference is invalid, the actual reference string is
used for the description. If nothing is supplied for the DescAttrName
attribute, the object’s ShortDesc attribute is used at run time.
<Attribute>.InAlarm The alarm state. This is exactly the same as the attribute in the host
primitive that represents the alarm condition, except when the alarm
state is disabled, in which case, InAlarm is set to Off, regardless of the
actual condition state. The quality is set during execute to the quality of
the attribute, except when the alarm is disabled, in which case the
quality is always GOOD.
<Attribute>.Inhibit If true, the alarm is disabled. This attribute is intended to be written to
by a script or user or input extension. Only the individual alarm is
disabled. No other alarms are disabled in the same object or in any
objects that are assigned to or contained by this object.
<Attribute>.Priority The value for the urgency of the alarm. Valid values are 1 through 999,
with 1 being the most urgent.
<Attribute>.TimeAlarmAcked The timestamp indicating the last time this alarm was acknowledged.
The date format reflects the current locale setting for the operating
system.
<Attribute>.TimeAlarmOff The timestamp indicating the last time this alarm (as represented by
the InAlarm attribute) went off. The date format reflects the current
locale setting for the operating system.
<Attribute>.TimeAlarmOn The timestamp indicating the last time this alarm (as represented by
the InAlarm attribute) went on. The date format reflects the current
locale setting for the operating system.

Enabling, Silencing, and Disabling Alarms

Alarms can be enabled, disabled, or silenced while an application is running. Setting an object’s alarm state can be set at
the Area level, at the container object level, or at the individual object. In addition, individual alarms within a single object
can be enabled, silenced, or disabled.
Enabled: All alarms for an object are reported to client applications and saved as historical data. The enabled state is less
restrictive than the silenced or disabled alarm states.
Silenced: All alarms for an object are detected, saved to history, and sent to alarm clients. But, alarm clients do not show
the alarms. The silenced alarm state is more restricted than the enabled state, but less restrictive than the disabled state.
Disabled: No alarms for the object are detected. The alarm is return-to-normal until the alarm is re-enabled. The disabled
state is more restrictive than the silenced and enabled alarm states. A disabled alarm does not require
acknowledgement.
LogDataChangeEvent()
The LogDataChangeEvent() script logs an application change event to the Galaxy Historian. The LogDataChangeEvent()
function works only in object scripts, not in symbol scripts.
Syntax: LogDataChangeEvent(AttributeName, Description, OldValue, NewValue, TimeStamp);
A symbol script still compiles if the LogDataChangeEvent() function is included. However, a warning message is
written to the log at run time that the function is inoperable.
This example logs an event when a pump starts or stops with a timestamp of the current time when the event
occurred.
LogDataChangeEvent(TC104.pumpstate, “Pump04”, OldState, NewState);

Alarm Extensions
An alarm extension can be added to a template or instance Boolean attribute in the Extensions tab of the object’s editor. If
added to a template attribute, the alarm extension is automatically locked in derived objects. Attribute arrays cannot be
extended.
On the Extensions page of the Object Editor, select an attribute from the Extendable Attributes List. The four extension
groups dynamically change to allowed extension rules for the selected attribute type.Select the Alarms check box. For
Alarm Extension, select a Category from the list.

Type a Priority level for the alarm (default is 500).

Select to use either the Object Description for Alarm Message or type another alarm message in the Message box. An X
appears in the A column of the selected attribute.
For Boolean Label Extension, specify text strings for the False state and the True state, if needed. These text strings
appear in the Active Alarm State list for you to select.
Lock the values, if needed. 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.

Alarm DB Logger Manager Utility

The InTouch Distributed Alarm system includes the Alarm DB Logger Manager utility that logs alarms and events to
Microsoft SQL Server and/or Microsoft Data Engine (MSDE). The Alarm DB Logger can be manually started on demand or
can be configured to run as a Windows service. Alarm logging uses UTC (GMT) timestamping and provides compatibility
with DST and across time zones.

Note: MSDE is a de-featured version of SQL Server that has its own special attractions. High on the list is the ease with
which you can attach databases initially built for MSDE to a full SQL Server service. There is no need to upsize the
database or copy individual tables in a database from MSDE to a full SQL Server. This makes it more suitable for
environments where it isn't cost effective to deploy vast computer resources. The maximum size of an MSDE database is 2
GB.

Alarm DB Logger is an Alarm Consumer. You configure it with an alarm query that defines which alarms are to be logged.
You use the Alarm DB Logger to specify alarm queries and to log the resultant alarm records. These alarm queries are
sent via the Alarm Consumer interface of the Distributed Alarm System.
The Alarm DB Logger also has the ability to auto-reconnect. When the connection to the database is lost, the logger
continually checks for the database connection at regular intervals. When the connection is re-established, logging
proceeds.
The Alarm DB Logger reports all errors whether running as a service or a normal application to the Wonderware Logger.
The Alarm DB Logger consists of the following two components:
Alarm DB Logger Manager Utility – This utility is a separate executable that solely takes care of starting and stopping the
logging operations. It is launched and starts working either as a service or a normal application (depending upon the
running mode you select in the Alarm DB Logger Manager). The logging utility retrieves the setting information from the
registry and performs the logging.
Alarm DB Logger Configuration Utility – This utility takes care of user input and database configuration. The Alarm
DB Logger Manager allows you to select the mode in which the Alarm DB Logger will run (either as a windows service or
a normal application).

Note: The Alarm DB Logger Manager only saves the setting values into the registry. The utility is responsible for starting
and stopping the Alarm DB Logger. It is also responsible for displaying the status of Smart Cache. When Alarm DB Logger
Manager (almlogwiz.exe) is closed while wwalmlogger.exe is running (either by pressing the Esc key or by clicking the “X”
button on the upper right of the dialog box), the logging operation does not stop. The progress control status indicates the
percentage fill of the in-memory buffer with alarm records. The alarms are buffered when the SQL Server connection is
down, and/or when the alarms are coming at a rate faster than the logging rate of Alarm DB Logger.

 
The Alarm DB Logger Configuration Utility provides you with the ability to:
 Run the application as a Windows Service or as a normal application
 Select the database connection type – SQL Server or MSDE
 Create the necessary SQL tables in the database
 Specify the alarm query that will be a part of the logging instance
 Select the logging mode – Detailed or Consolidated
 Check/Uncheck logging of events
 Set performance tuning parameter – The auto reconnect rate is not the same as the performance tuning
parameter. It depends on the time out for a connection attempt associated with SQL ServerServer.
 Store the setting in the registry

Logging to SQL Database

The Alarm DB Logger logs alarm data into the database. If the OLEDB Provider is SQL Server, you will need to specify the
SQL Server machine in the Alarm DB Logger Manager. Alarm DB Logger automatically creates the necessary data
structures, if they do not already exist in the database.

To use the Alarm DB Logger Manager Utility

a. Start up the Alarm DB Logger Manager.

The Alarm DB Logger Manager dialog box appears.

When minimized, the Alarm DB Logger Manager appears as an icon in the system tray. When you right-click the icon, a
popup menu appears displaying the following commands:
Start – Begins the alarm logging process.
Stop – Ends the alarm logging process.
Settings – Opens the Alarm DB Logger Manager - Configuration dialog box.
Hide Window –Minimizes the Alarm DB Logger Manager dialog box to an icon in the system tray.
Show Window – Opens and maximizes the Alarm DB Logger Manager dialog box.
Close – Exits the Alarm DB Logger Manager Utility.

b. The Smart Cache Status indicates the percentage fill of the in-memory buffer with alarm records.
c. Click Settings to configure the Alarm DB Logger. The Alarm DB Logger Manager Configuration dialog box appears.

For more information on configuring the Alarm DB Logger, see “Alarm DB Logger Configuration.”
d. Click Start to begin the alarm logging process.
e. Click Stop to end the alarm logging process.
Lab 15 – Configuring Alarms
Introduction
This lab illustrates how to configure your galaxy to provide alarms to external alarm subscribers such as an
operator’s visualization interface or an alarm database logger. As an example of alarm functionality, a typical
high level alarm is added to the mixer, as well as a malfunction alarm from the mixer’s agitator generated from a
field device such as a PLC.
As part of the configuration necessary to accomplish this functionality, it is necessary to update the
auto-configuration script created in the previous lab to accommodate a new input signal associated with the
malfunction alarm.
The Wonderware Alarm DB Logger Manager is used to store real-time alarms in a centralized database.

Objectives
Upon completion of this lab you will be able to:
• Configure the $WinPlatform object as an alarm provider for the galaxy
• Configure alarms within objects including using the Alarm Extension
• Configure and use the Alarm DB Logger Manager
• Use alarm queries to request real-time alarms from alarm providers
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Configure the WinPlatform object as an Alarm Provider

a. Configure the GRPlatform instance to be an InTouch alarm provider for all areas in the galaxy.

Configure the $Mixer.LIT template for alarms

b. Configure the $Mixer.LIT template with a Hi level alarm, with a limit of 80.0, a priority of 500 and “Mixer Hi Level alarm”
as the alarm message.
c. Lock all level alarms attributes but the Hi Limit.

Configure the Alarm extension

d. Add a Boolean Object writeable UDA to the $Mixer.Agitator template named Malfunction.
e. Extend the Malfunction attribute with an Input extension and configure its Source as ---.
f. Extend the Malfunction attribute with an Alarm extension and lock it. Configure its category as Process and leave the
default values on the rest of the attributes.

Update auto-configuration script on $Mixer

g. Modify the AssignIO script of the $Mixer template by adding the following line of code to the Configure agitator section
of the code:
Me.Agitator.Malfunction.InputSource = dataSource + “_AG_Malfunction”;

View the alarm data on Runtime

h. Deploy the GRPlatform object on cascade.
i. Using the watch list created in Lab 5, add a new watch window called Alarms and add the following attribute references:
• LIT_001.PV
• LIT_001.InAlarm
• LIT_001.Hi.InAlarm
• LIT_001.Hi.Limit
• LIT_001.Hi.TimeAlarmOn
• LIT_001.Hi.TimeAlarmOff
• Agitator_001.InAlarm
• Agitator_001.Malfunction
• Agitator_001.Malfunction.InAlarm
• Agitator_001.Malfunction.TimeAlarmOn
• Agitator_001.Malfunction.TimeAlarmOff
• Line1.AlarmOnCnt
j. Save the watch list.
Configure and Start the Alarm DB Logger Manager
k. Use the Alarm DB Logger Manager to create a database named WWALMDB on your local computer. Use
the following user information:

User Name: sa

Password: ww

l. Configure the Alarm DB Logger Manager to query all priorities from the following alarm query: \Galaxy!ControlSystem
\Galaxy!Discharge
\Galaxy!Intake \Galaxy!Production
m. Leave the defaults advanced settings and start Alarm DB Logger Manager.

View the Alarm History data

n. Use SQL Server Management Studio to query all data from the v_AlarmHistory view

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Configure the WinPlatform Object as an Alarm Provider

1. In Model view, double-click the GRPlatform instance to open its configuration editor.
2. Check the InTouch alarm provider attribute and leave the Alarm areas attribute empty.

3. Click the Save and Close button and check in the object.
Configure the $Mixer.LIT Template for Alarms
4. Double-click the $Mixer.LIT template to open its configuration editor.

5. Select the Alarms tab and configure the object as follows:

Detect PV level(limit) alarms: checked (locked)

Level alarms: (locked)
Hi: checked (locked)
Hi Limit: 80.0 (unlocked)
Hi Priority: 500 (locked)
Hi Alarm Message: Mixer Hi Level alarm (locked)

6. Click the Save and Close button and check in the object.
Configure the Alarm Extension

7. Double-click the $Mixer.Agitator template to open its configuration editor.

8. Select the UDAs tab, add a UDA named Malfunction and configure it as follows:

Data type: Boolean

Category: Object writeable

9. Select the Extensions tab.

10. Select the Malfunction attribute.
11. Configure the Malfunction extensions as follows:
Input extension: checked
Source: ---
Alarm extension: checked (locked)
Category: Process
Priority: 500
Alarm message: me.ShortDesc
Active alarm state: True

12. Click the Save and Close button and check in the object.
Update Auto-configuration Script on $Mixer
13. Double-click the $Mixer template to open its configuration editor.
14. Select the Scripts tab.
15. Select the AssignIO script and add the following line of code to the Configure agitator section of the code:

Me.Agitator.Malfunction.InputSource = dataSource + “_AG_Malfunction”;

16. Click the Save and Close button and check in the object.

 
The ArchestrA IDE should now look similar to the following:

View the Alarm Data in Runtime

17. Deploy the GRPlatform object with Cascade Deploy checked in the Deploy dialog box.

18. Click Close when deployment is complete.

19. Right-click on the LIT_001 instance and select View in Object Viewer.
Note: If Object Viewer was open during undeployment, you will see the following error message. Click the OK button to
close and then re-open Object Viewer from the ArchestrA IDE.

20. Load your saved Watch List.

21. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add a new tab
to the watch list.
22. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list
to Alarms.
23. Add the following attributes to the watch list:
For the LIT_001 object:
 Hi.InAlarm
 Hi.Limit
 Hi.TimeAlarmOff
 Hi.TimeAlarmOn
 InAlarm
 PV

For the Agitator_001 object:

 InAlarm
 Malfunction
 Malfunction.InAlarm
 Malfunction.TimeAlarmOff
 Malfunction.TimeAlarmOn

For the Line1 object:

 AlarmOnCnt

24. 24. Save the watch list.

Configure and Start the Alarm DB Logger Manager.
25. Start the Alarm DB Logger Manager by selecting Start / All Programs / Wonderware / InTouch / Alarm DB
Logger Manager.
26. In the Alarm DB Logger Manager window, click the Settings button.

27. Configure the Alarm DB Logger Manager – Configuration dialog box as follows:

Server Name: localhost

Database: WWALMDB
User Info:
User Name: sa
Password: ww
Logging Mode: Detailed

28. Click the Create button

 
The Success dialog box displays indicating that the tables were created.

29. Click the OK button to continue.

Note: If the following Warning dialog is displayed, click the Yes button to delete the existing database and create a new
one.

30. In the Alarm DB Logger Manager – Configuration dialog box click the Next button to continue.

31. Configure the Alarm DB Logger Manager – Query Selection dialog box as follows:

From Priority: 1
To Priority: 999
Alarm Query: \Galaxy!ControlSystem
\Galaxy!Discharge
\Galaxy!Intake
\Galaxy!Production
 
32. Click the Next button to continue:
33. At the Alarm DB Logger Manager – Advanced Settings dialog box, leave the default settings.

34. Click the Finish button.

35. In the Alarm DB Logger Manager window, click the Start button to start the Alarm Database Logger.
When the Alarm Database Logger is started, the Alarm DB Logger Manager window will look similar to the following:

View the Alarm History Data

36. Start the SQL Server Management Studio by selecting Start / All Programs / Microsoft SQL Server 2005 /
SQL Server Management Studio.
37. Configure the Connect to Server dialog box as follows:
Server type: Database Engine
Server name: localhost
Authentication: Windows Authentication

38. Click the Connect button to continue.

39. In the Object Explorer (left pane) navigate to localhost / Databases / WWALMDB and select Views to get a list
of all the database’s Views in the Object Explorer Details (right pane).
40. In the Views list (right pane), right-click on the v_AlarmHistory view and select Open View to display the
current list of alarms logged in the database.
Your data should look similar to the following:
Section 2 – Historization
Section Objectives
• Familiarize you with the background concept of historization, and
• Enable you to understand details of historizable configuration.

This section provides familiarization with the background concept of historization and the details of historizable
configuration.

Historization Background
The history system supports historization of process data in distributed history architecture.
One or more Historian products can be installed on the same network as the Application Server Galaxy. The Galaxy can
be configured to store history data into one or more of those Historians. Since the Engines use push technology to
historize, the Historian box does not have any ArchestrA software requirements.
Each Engine in the Galaxy is configured with the location of the Historian storage node to which its history data is to be
sent. This configuration is stored in an attribute within the Engine.
Wonderware Historian requires a Historian 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 Wonderware
Historian.
When an AutomationObject starts up it registers its configuration data with Historian using a Historian supplied interface. If
the Historian tag already exists, it means this object has been previously registered. If the Historian 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 Historian. The user does not need to run Historian configure and import tags from
Application Server (as done with InTouch today).
For storage, the story is similar. When an object decides to store a new VTQ to Historian, it pushes that storage update
message, with the new VTQ, to Historian using a Historian supplied interface. The Historian must exist on a different
node from the AutomationObject. The history primitive uses the previously-returned unique identifier for the Historian tag
that corresponds to the historized property to identify the tag being stored.

History Configuration

Historizable Data Types for Attributes

For attribute data to be stored in the historian, a host AppEngine must be configured to send history data to a Wonderware
Historian node. For each object, you can configure attributes of the following data types to be saved to the Wonderware
Historian.
 Float (numerical)
 Double (numerical)
 Integer (numerical)
 Boolean (non-numerical)
 String – Unicode (non-numerical)
 CustomEnum (non-numerical) maps to Historian Integer
 ElapsedTime (numerical) Maps to Historian Float, converted to seconds
 Arrays or portions of arrays are not supported.
 Enum type attributes are saved as Wonderware Historian integer ordinal values.
 IEEE NaN values for float and double data types are converted to null values prior to being sent to the historian.
NaN values are associated with a Bad OPC data quality.
 All numerical attributes sent to the Wonderware Historian are in the engineering units specified for the attribute.
The Wonderware Historian does not scale numerical values.
 
Configuration of a non-numerical Attribute for Historization
For an object that has non-numerical historizable attributes, the ArchestrA 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 ArchestrA 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:
 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 Wonderware Historian at Object Deploy Time

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

Reconfiguration of Historian 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 Historian product automatically. For example, if the engineering
units string for the tag changes from “Deg F” to “Deg C” upon a redeploy, the Historian configuration database must
reflect this change.
Reconfiguration of Historian at Object Undeploy Time
When an AutomationObject is undeployed that has been historized, object does not cause any dynamic reconfiguration
of the Historian product. In other words, the Historian tag and all its history is left in the Historian historian. This
means the history data can still be examined in the future even if the AutomationObject is no longer deployed.

Historian Installation and Deployment

Wonderware Historian is installed and deployed using its standard mechanism. Historian can be deployed on any PC in
the Galaxy, or on a PC outside the Galaxy but on the local network. Historian 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 Historian can be utilized by a single Galaxy. However, a single engine sends its history to only one Historian.
A single Historian can receive historical data from a single Galaxy only.

Historian Value Mapping

The update packet to be sent to Historian 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 Historian datatypes as specified below:
Enum – historize as Integer ordinal value
Strings – Historian 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, Historian clients
do not handle NaN properly. Therefore, ArchestrA will convert the NaN value to a Null value representation just prior to
sending to Historian.

Historian Quality Mapping

The Application Server Data Quality is somewhat different than the Historian data quality. The plan is for Historian to
support the OPC Quality definition. Thus, the 16-bit value for the OPC Data quality is sent to Historian. 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 Historian. This means that a point that has an identical value over some period of time with varying qualities will
have multiple records stored to Historian. The quality stored in Historian is to be the actual quality of the attribute in
Application Server with no modification. However, Historian may insert “artificial” quality (for example 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.

Historian Timestamp mapping

The timestamp to be sent to Historian for each attribute value/quality update is sent by the object in the VTQ packet. Both
Application Server and Historian use UTC time.
Application Server History Storage Performance
The link from the Application Server to Historian may fail or be down for any of a number of reasons:
 The network connection to Historian goes down unexpectedly.
 The Historian storage node goes down or fails unexpectedly.
 The Galaxy Platform and its Engines which are generating history startup prior to Historian node startup in a
recovery situation.
 History data must be preserved in these cases by having it stored locally until the link to Historian has recovered or
Historian 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.

Historian extension

You can assign historical extensions to extended attributes that you select from the Extensions tab of your objects.
After you select the History extension check box to save the data to history associated with the attribute extension you
selected, an X appears in the H column of the Extendable Attributes list to indicate its data is saved to the historian.
The following are the common historical attributes that you can configure for your system and application objects.
Force Storage Period: Interval in milliseconds in which an attribute value is saved to the Historian, regardless of whether
the value exceeds its value deadband setting or not. An attribute value is saved to the Historian at every Force Storage
interval. The default value of zero (0) disables the Force Storage period.
Value Deadband: Threshold value in engineering units, which is the absolute difference between the current and most
recent saved historical values. The current value must exceed the absolute deadband to be saved as historical data.
The Value Deadband filters out small, momentary value changes from being saved to the Historian. A new value that is
within the range of the deadband is not saved to the Historian. The default value of 0.0 disables the Value Deadband and
any change to a value is saved as historical data.
Interpolation Type: List of methods used by the Historian to interpolate analog historical data. The interpolation type
determines which analog value is selected during a Historian data retrieval cycle. Interpolation types include System
Default, Stairstep, or Linear. The default interpolation type is System Default.
Stairstep: No interpolation occurs. The last known value is returned with the given cycle time. If no valid value can be
found, a NULL is returned to the Historian.
Linear: The Historian calculates a new value at the given cycle time by interpolating between the last known value prior to
the cycle time and the first value after the cycle time.
System Default: The Wonderware Historian system-wide interpolation setting. The system-wide setting must be either
stairstep or linear interpolated.
Rollover Value: Positive integer value that represents a tag’s reset limit when the Historian operates in counter retrieval
mode. In counter retrieval mode the Historian uses a tag's rollover value to calculate and return the delta change
between consecutive retrieval cycles. The default value is 0.0.
The Rollover value applies only to numeric attributes. The Rollover value is disabled if the historical attribute data
type is Boolean or a string.
Trend Hi: Initial maximum trend value in engineering units for clients. The default is 100.
Trend Lo: Initial minimum trend value in engineering units for clients. The default is 0.0.
Sample Count: Integer that indicates the number of samples the Historian should store in the active image for an
attribute value. Acceptable range of values is from 0 to 9999. The Historian enforces a sample count of 65 for the active
image.
If the current sample count for the active image is 65, and you set the sample count to a value less than or equal to 65, the
new sample count setting is not saved to the Historian database, and the active image count remains at 65.
If the current sample count for the active image is greater than 65, and you set the sample count to a value less than or
equal to 65, the new sample count is saved to the Historian database and 65 is used by the active image.
Regardless of the current sample count for the active image, if you set the sample count to a value greater than 65, the
new sample count is saved to the Historian database and used by the active image.
Enable Swinging Door: A flag that indicates whether the swinging door rate deadband is enabled or disabled. The default
is disabled.
Enable Swinging Door is disabled if the historical attribute data type is Boolean or a string.
Rate Deadband: Percentage rate of change deadband based on the change in the slope of incoming data values to the
Historian. For example, specifying a swinging door rate deadband of 10 percent means that data is saved to the Historian
if the percentage change in slope of consecutive data values exceeds 10 percent.
The default is 0.0, which indicates a swinging door rate deadband is not applied. Any percentage greater than 0.0 can be
assigned to the rate deadband.
Lab 16 – Configuring History
Introduction
In this lab you are to configure your galaxy for historization to your local Wonderware Historian server. As an
example, the mixer’s level and state of the Inlet Valve 1 is configured, as well as the speed of the mixer’s
agitator.
Although ActiveFactory Trend is outside the scope of this class, you will use it this lab as a quick and simple
way to retrieve history data from the history database.

Objectives
Upon completion of this lab you will be able to:
• Configure the $AppEngine object to store history data to a Wonderware Historian
• Configure attributes within objects for historization including the History Extension
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Configure the WinPlatform object

a. Configure the GRPlatform instance to use C:\S&F as the Store & Forward folder.

Configure the AppEngine object for History

b. Enable the AppEngine instance for storage to the historian in your local computer.

Configure the $Mixer.LIT template for History

c. Configure the $Mixer.LIT template to historize the PV attribute using the default values for the history attributes.
d. Lock all history-related attributes for the PV attribute.

Configure the $Mixer.Inlet1 template for History

e. Configure the $Mixer.Inlet1 template to historize the PV attribute using the default values for the history attributes.
f. Lock all history-related attributes for the PV attribute.

Configure the History extension

g. Extend the Speed attribute of the $Mixer.Agitator template for historization using RPM as the engineering units.
h. Lock the history extension.

View the History data with ActiveFactory Trend

i. Deploy the GRPlatform object on cascade.
j. Use ActiveFactory Trend to connect to the local Wonderware Historian using Integrated security.
k. Visualize the trend for the following tags:
• Agitator_001.Speed
• Inlet1.PV
• LIT_001.PV

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Configure the WinPlatform Object

1 Double-click the GRPlatform instance to open its configuration editor.
2 In the General tab, configure the object as follows: History store forward directory: C:\S&F

3 Click the Save and Close button and check in the object.
Configure the AppEngine Object for History
4 Double-click the AppEngine instance to open its configuration editor.
5 Configure the History section of the General tab as follows:
Enable storage to historian: checked
Historian: [Name of your local computer]
Leave the default values for the rest of the attributes.

6 Click the Save and Close button and check in the object.
Configure the $Mixer.LIT Template for History
7 Double-click the $Mixer.LIT template to open its configuration editor.
8 Select the History tab and check the PV box to historize the PV attribute. Leave the default values and lock all
attributes by clicking the lock on Historize.

9 Click the Save and Close button and check in the object.

Configure the $Mixer.Inlet1 Template for History

10. Double-click the $Mixer.Inlet1 template to open its configuration editor.
11. In PV section of the General tab, configure the object as follows: Historize PV: checked (locked) Force storage
period: 0 (locked) Sample Count: 0 (locked)

12. Click the Save and Close button and check in the object.
Configure the History extension for the $Mixer.Agitator template
13. Double-click the $Mixer.Agitator template to open its configuration editor.
14. Select the Extensions tab.
15. Select the Speed attribute.
16. Check and lock the History extension and configure it as follows:
Engineering units: RPM
Leave the default values for the remaining attributes.

17. Click the Save and Close button and check in the object.

View the History Data with ActiveFactory Trend

18. Deploy the GRPlatform object using the default Cascade Deploy.
19. Start ActiveFactory Trend by selecting Start / All Programs / Wonderware / ActiveFactory / Trend.
20. Configure the Server List Configuration as follows and click the Add button:

Server: LOCALHOST
Authentication information:
Use Integrated security: checked

21. After the server has being added to the Server list click the Close button.
22. With LOCALHOST selected on the Servers pane (top-left pane), you will see the attribute references
configured for historization in the Tags pane (bottom-left pane).
23. In the Tags pane (bottom-left) double-click the following tags to add them to the trend:
 Agitator_001.Speed
 Inlet1_001.PV
 LIT_001.PV

24. Click on the Live Mode button to configure the Trend to update automatically.

ActiveFactory Trend displays a graphical representation of the history data recorded for the selected tags. Notice in this
example the first half of the graph is blank. The blank section reflects the time period before deployment, when no data
was available.

 
MODULE 6
Security
Section 1 – Security Overview
Lab 17 – Security

Module Objective：

Configure, deploy, and test security with Application Server.

Section 1 – Security Overview
Section Objective
Introduce Security with Wonderware Application Server.

This section provides an understanding of Security as it relates to Application Server.

ArchestrA security is designed to prevent users from performing unauthorized activities. This includes
users of:
 The ArchestrA 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.

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 ArchestrA
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.
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.
ArchestrA’s security system is configured in the Configure 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
On the Authentication Mode page, choose the mode of Galaxy security:
• 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 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.
Authentication Mode selections provide the following general results:
 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 ArchestrA IDE closes.
 When you switch to None from another Authentication Mode and click OK, the ArchestrA 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
ArchestrA IDE and anywhere in the ArchestrA environment are granted based on the logged in user's associated
roles and permissions. The ArchestrA 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
ArchestrA 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 ArchestrA 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 ArchestrA 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.

 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.

 
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:
 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 the new login data. If that fails, the trusts are being
reestablished by the controller, and you should retry at a later time.
  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 ArchestrA IDE, SMC, and InTouch for System Platform 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:
 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:
 Machines and users participating in a domain.
 Users being drawn from multiple domains.
 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 Starting 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 appears:
 The user explicitly chooses a Log On option from within the user interface. 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.
Attribute Security Classifications
Attribute SecurityClassifications classify Attributes of AutomationObjects (like the previously discussed
Command attribute) from a security perspective. They are:
 FreeAccess – Any User can write to these attributes to perform safety or time critical tasks that could be
hampered by an untimely logon request (for example 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.
 Read-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:
 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.

Lab 17 – Security
Introduction
As you work with the security settings within the ArchestrA IDE you set up various Roles and Users and configure
them with different sets of permissions. You then observe the different behaviors in the Object Viewer as you logon
as various users.
In this lab you configure the security settings for your galaxy and test those settings with a sample automation object that
has been partially pre-configured for you.
The security configuration used in this lab is based on the following premises:
Operators: these users can acknowledge alarms and operate devices by modifying Operate attributes in the objects
(for example, open a valve or start a motor); but they are not allowed to change alarm set points or other Tune
attributes. Users in this role do not have access to the configuration data.
Supervisors: these users are only allowed to perform tuning configurations by modifying Tune attributes in the objects
(for example, changing an alarm set point). Users in this role do not have access to the configuration data.
Engineers: these users have access to the configuration of the Galaxy through the ArchestrA IDE and configuration of
the objects in runtime by modifying Configure attributes in the objects (for example, changing a deadband or an input
source). Notice that users in this role do not have Operate permissions, which will prevent them from setting objects off
scan before writing to a Configure attribute. It is assumed that the Operators “own” the runtime, so they have to set the
objects off scan (put the devices off line) before an engineer can change the configuration on runtime.

Note: Importing objects will be discussed in detail, including the options in the Import Objects dialog box, in a subsequent
module.

Objectives
Upon completion of this lab you will be able to:
• Configure the security classifications for individual attributes within automation objects
• Configure the security settings for a galaxy
• Record and view the security audit trail for a galaxy
 Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Import the SecurityTest Object

a. Import the object in the $SecurityTest.aaPKG file located in the C:\Wonderware Training folder.
b. Assign the $SecurityTest object to your toolset.

Configure the SecurityTest Object

c. Configure the Security Classifications for each UDA in the object as follows:

Att1_FreeAccess: Free Access

Att2_Operate: Operate
Att3_SecuredWrite: Secured Write
Att4_VerifiedWrite: Verified Write
Att5_Tune: Tune
Att6_Configure: Configure
Att7_ReadOnly: Read Only

Create and Deploy an Instance of SecurityTest

d. Create an instance of $SecurityTest and leave the default name.
e. Assign the new instance to the Discharge area and deploy it.

Configure Security for the Galaxy

f. Configure the galaxy’s security Authentication Mode to Galaxy.
g. Add a security group named TestGroup and assign the SecurityTest_001 instance to it.
h. Configure the Default role with the following permissions:
On the General permissions section:
IDE Permissions: unchecked
SMC Permissions: unchecked
Can Write to GObject Attribute using ObjectViewer: checked

On the Operational permissions section:

Default: checked
TestGroup: unchecked

i. Add a new role named Operators with an access level of 500 and with the following permissions:
No General permissions

 
No Operational permissions for the Default security group
Configure the Operational permissions section for the TestGroup security group as follows:
Can acknowledge Alarms: checked
Can modify “Configure” attributes: uncecked
Can modify “Operate” attributes: checked
Can modify “Tune” attributes: unchecked

j. Add a new role named Supervisors with an access level of 1000 and with the following permissions:
No General permissions.
No Operational permissions for the Default security group.
Configure the Operational permissions section for the TestGroup security group as follows:
Can acknowledge Alarms: unchecked
Can modify “Configure” attributes: unchecked
Can modify “Operate” attributes: unchecked
Can modify “Tune” attributes: checked

k. Add a new role named Engineers with an access level of 2000 and with the following permissions:
Configure the General permissions as follows:
IDE Permissions: checked (this will check every box within the node)
Framework Configuration: unchecked
SMC Permissions: checked (this will check every box within the node)

Configure the Operational permissions for the TestGroup security group as follows:
Can acknowledge Alarms: unchecked
Can modify “Configure” attributes: checked
Can modify “Operate” attributes: unchecked
Can modify “Tune” attributes: unchecked

l. Configure the Administrator role with all Operational permissions.

m. Add a new user named HOper with a full name of Homer Operator and make it part of the Operators role. Assign ww
as the password.
 

n. Add a new user named JSup with a full name of Joe Supervisor and make it part of the Operators and Supervisors
role. Assign ww as the password.

o. Add a new user named WEng with a full name of William Engineer and make it part of the Engineers role. Assign
ww as the password.
Test General Permissions
p. Verify that the WEng user cannot modify the security configuration through the ArchestrA IDE.

Test Operational Permissions

q. Login as Administrator and deploy the SecurityTest_001 object.
r. Using the watch list created in Lab 5, add a new watch window called Security and add the following attribute
references:
Object Name Attribute Name
SecurityTest_001 Att1_FreeAccess
SecurityTest_001 Att2_Operate
SecurityTest_001 Att3_SecuredWrite
SecurityTest_001 Att4_VerifiedWrite
SecurityTest_001 Att5_Tune
SecurityTest_001 Att6_Configure
SecurityTest_001 Att7_ReadOnly
SecurityTest_001 ScanState
SecurityTest_001 ScanStateCmd

s. Save the watch list.

t. Test the different security classifications and the security permissions by modifying the value of the attributes under the
different user accounts created before.

View the Security Audit Trail

u. Use SQL Server Management Studio to query all data from the v_EventHistory view.

See the next page for Detailed Lab Instructions

Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Import the SecurityTest Object

1. From the Galaxy menu, select Import / Object(s) to import an automation object.

2. In the Import Automation Object(s) dialog box, navigate to C:\Wonderware Training and select the
$SecurityTest.aaPKG file.

3. Click the Open button.

Note: Importing objects will be discussed in detail, including the options in this dialog box, later in this course.

4. In the Import Preferences dialog box, leave the default options and click OK to continue.

5. Click Close in the Import completed message box.

The imported object now appears in the Application toolset:

6. Move the $SecurityTest to the Training toolset.

Configure the SecurityTest object

7. Double-click the $SecurityTest template to open its configuration editor.

8. Select the UDAs tab.

9. Select the Att1_FreeAccess UDA and click the Shield icon to select the security classification for the
attribute.

10. Select the Free Access security classification from the popup menu.
11. Repeat step 6 to configure the security classifications for the following attributes:

Att2_Operate: Operate

Att3_SecuredWrite: Secured Write

Att4_VerifiedWrite: Verified Write

Att5_Tune: Tune

Att6_Configure: Configure

Att7_ReadOnly: Read Only

12. Click the Save and Close button and check in the object.

Create and deploy an instance of SecurityTest

13. Using the Template Toolbox and the Model view, create an instance of the $SecurityTest template.
14. Leave the default name and assign the instance to the Discharge area.

15. Deploy the newly created instance.

16. Click Close when deployment is complete.

Configure Security for the Galaxy
17. From the Galaxy menu, select Configure / Security to enable and configure security for the galaxy.
18. Select Galaxy for the Authentication Mode.
19. Select the Security Groups tab.
20. Click the plus icon button to add a new security group. Name the new security group TestGroup.
21. Select the Default security group and locate the SecurityTest_001 instance in the objects list (right pane).
22. Drag-and-drop the SecurityTest_001 instance to the TestGroup in the security group list (left pane).
23. Select the TestGroup security group to confirm SecurityTest_001 appears as an object in the TestGroup security
group.

Important! Make sure that you are moving the object’s instance (SecurityTest_001) and NOT the object’s template
($SecurityTest).
24. Select the Roles tab.
25. From the Roles available list, select the Default role and configure the permissions as follows:

In the General permissions section:

IDE Permissions: unchecked (this will uncheck all boxes within the node)
SMC Permissions: unchecked (this will uncheck all boxes within the node)
Can Write to GObject Attribute using ObjectViewer: checked
In the Operational permissions section:
Default: checked
TestGroup: unchecked

Note: The Can Write to GObject Attribute using ObjectViewer permission will allow everyone (the Default role applies
to every user) to modify attribute values using Object Viewer.
26. Click the plus icon button to add a new role and name it Operators.

27. Double-click on the Access level field and enter 500.

28. Configure the Operational permissions for the Operators security group as follows:

Can acknowledge Alarms: checked

Can modify “Configure” attributes: unchecked
Can modify “Operate” attributes: checked
Can modify “Tune” attributes: unchecked
29. Click the plus icon button to add a new role and name it Supervisors.

30. Double-click on the Access level field and enter 1000.

31. Configure the Operational permissions for the TestGroup security group as follows:

Can acknowledge Alarms: unchecked

Can modify “Configure” attributes: unchecked
Can modify “Operate” attributes: unchecked
Can modify “Tune” attributes: checked
32. Click the plus icon button to add a new role and name it Engineers.

33. Double-click on the Access level field and enter 2000.

34. Configure the General permissions as follows:

:
IDE Permissions: checked (this will check every box within the node)
Framework Configuration: unchecked
SMC Permissions: checked (this will check every box within the node)

35. Configure the Operational permissions for the Engineers security group as follows:

Can Acknowledge Alarms: unchecked

Can Modify “Configure” Attributes: checked
Can Modify “Operate” Attributes: unchecked
Can modify “Tune” attributes: unchecked
36. Select the Administrator role and configure the Operational permissions for the TestGroup security group as
follows:
TestGroup: checked (this will check every box within the group)

37. Select the Users tab.

38. Click the plus icon button o add a new user and name it HOper.

39. Double-click on the Full name field and enter Homer Operator.

40. Check the checkbox in front of Operators to assign it to the Operators role.
 

 
 
41. With HOper selected, click on the Change Password button, enter the following information in the Change
Password dialog box, and then click the OK button to continue.

Old Password: [blank]

New Password: ww
  New Password:
Confirm ww

42. Click the plus icon button to add a new user and name it JSup.

43. Double-click on the Full name field and enter Joe Supervisor.

44. Assign the user to the Operators and Supervisors roles.

Note: Notice that the user JSup will inherit permissions from both the Operators and Supervisors roles, allowing JSup to
modify attributes with Operate and Tune security classifications.

45. With JSup selected, click on the Change Password button, enter the following information in the Change
Password dialog box, and then click the OK button to continue.

Old Password: [blank]

New Password: ww
Confirm New Password: ww

46. Click the plus icon button to add a new user and name it WEng.

47. Double-click on the Full name field and enter Will Engineer.

48. Assign the user to the Engineers role.

 

 
 
 
 
   
49. With WEng selected, click on the Change Password button, enter the following information in the Change
Password dialog box, and then click the OK button to continue.

Old Password: [blank]

New Password: ww
Confirm New Password: ww

50. In the Configure Security dialog box, click OK to accept the security configuration.

51. In the Change User dialog box, enter the following information.
User name: WEng
Password: ww

52. Click the OK button to log in.

Test General permissions

53. From the Galaxy menu, select Configure / Security.
You will be presented with the following dialog box since WEng does not have permissions to modify security
configuration.

54. Click No to dismiss the dialog box.

 
55. From the Galaxy menu, select Change User to log in as the Administrator.

56. Enter Administrator for the User name.

Note: By default the Administrator account DOES NOT have a password assigned.

57. Click the OK button to log in as the Administrator

Test Operational Permissions

Note: Notice that the SecurityTest_001 object needs to be re-deployed. This is because when the object was assigned to
a different security group, the object's SecurityGroup attribute was changed, modifying the configuration of the object.

58. Deploy the SecurityTest_001 object.

59. Open Object Viewer by right-clicking the SecurityTest_001 instance and selecting View in Object Viewer. If you
closed Object Viewer before, you can use File / Load Watch List to open the file you saved earlier.
60. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add a new tab to
the watch list.
61. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to
Security.
62. Add the following SecurityTest_001 attributes to the watch list:
 Att1_FreeAccess
 Att2_Operate
 Att3_SecuredWrite
 Att4_VerifiedWrite
 Att5_Tune
 Att6_Configure
 Att7_ReadOnly
 ScanState
 ScanStateCmd

63. Save the watch list.

64. Test the different security classifications and the security permissions by modifying the value of the attributes under the
different user accounts created before.
65. To log in to Object Viewer with a different user account, select Change User from the Options menu.
66. Enter the user’s credentials in the Change User dialog box.

67. Click the OK button.

You can verify the current logged in user on the left side of the status bar.

View the Security Audit Trail

Note: Make sure that the Alarm DB Logger Manager utility is started.

Tip: You can refer to Lab 15 – Configuring Alarms to see how to run and start the Alarm DB Logger Manager utility.

68. Start the SQL Server Management Studio by selecting Start / All Programs / Microsoft SQL Server 2005 /
SQL Server Management Studio.
69. Configure the Connect to Server dialog box as follows:

Server type: Database Engine

Server name: localhost
Authentication: Windows Authentication

70. Click the Connect button to continue.

71. In the Object Explorer (left pane) navigate to localhost / Databases / WWALMDB / Views to get a list of all the
database’s Views in the Object Explorer Details (right pane).
72. In the Views list (right pane), right-click on the v_EventHistory view and select Open View to display the
current list of alarms logged in the database.

 
MODULE 7
Galaxy Maintenance
Section 1 – Exporting and Importing Objects
Section 2 – Configuring Instances Through a .CSV File
Section 3 – System Management Console (SMC)
Section 4 – Network Account Utility

Module Objectives
Obtain an overview and understanding of:
 Exporting and Importing Objects
 Configuring Instances Through a .csv File Using Galaxy Dump and Load
 Using the System Management Console to manage platforms
 Using the Network Account Utility
Section 1 – Exporting and Importing Objects
Section Objective
 This section discusses some fundamental functions dealing with Galaxy Maintenance. Specifically, it
illustrates how to Export for future use and how to Import a galaxy created previously.

This section provides an understanding of fundamental functions dealing with Galaxy Maintenance.
Specifically, it illustrates how to Export for future use and how to Import a galaxy created previously.

Exporting Automation Objects

Use the ArchestrA IDE’s 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 ArchestrA 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.
When exporting an object instance, it will also include the parents of that object all the way back to and including
the base template.

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
a. Select an object in the Template Toolbox or Application Views pane.
b. From the Galaxy menu, select Export/AutomationObject(s).

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.
c. The Export Automation Object(s) dialog box appears.
In the Export Automation Object(s) 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.
d. 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.

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 ArchestrA IDE’s 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 ArchestrA 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
a. From the Galaxy menu, select Export/All Object(s).
b. The Export All Automation Objects dialog box appears.
In the Export AutomationObject(s) 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.
c. 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.

Importing Automation Objects

Objects can be reused from another Galaxy in your Galaxy. This saves time if the objects are already set up in another
Galaxy.
Importing instances previously exported from a Galaxy retains previous associations, when possible, such as
assignment, containment, derivation, and area.
Objects can be imported from exported .aaPKG files or from an .aaPDF file. An .aaPDF file contains the configuration
data and implementation code for one or more base templates. It is created by a developer using the ArchestrA Object
Toolkit.
Before starting, you cannot have two objects with the same name or more than one copy of the same version of an object
in the same Galaxy. When you import an object, these conflicts are identified and you can manage them.
To import Automation objects
a. On the Galaxy menu, select Import/Object(s).
b. The Import AutomationObject(s) dialog box appears.
Browse for the file with either a .aaPKG or a .aaPDF extension. You can select more than one file. Click Open.
c. The Import Preferences dialog box appears.
In the Objects from same toolkit and vendor area, select one of the following:

Skip objects with same conflict or newer codebase leaves the existing object unchanged.
Overwrite objects with name conflicts if their configuration version is higher
replaces the existing object with the object being imported if the codebases are the same and the imported object
has been edited more often than the existing object.
Migrate objects with a newer codebase also overwrites existing objects if the codebases (versions) are
the same. In addition, this option will migrate the state of existing objects to the newly imported version if the
object supports it. For more information about migrating, see the Application Server Installation Guide.
In the Objects from different toolkits and/or vendor but with same tagname area, select one of the following:

Skip does not import the object when a name match exists in the Galaxy.
Rename Object in Galaxy renames the existing object by appending to its current name the string (up to four
characters) you type in the Append to Object Name box. The default value is _old but you can change it to any
four-character string.
Rename Importing Object renames the object being imported by appending to its current name the string (up to
four characters) you type in the Append to Object Name box. The default value is _new, but you can change it to
any four-character string.

Note: Object name conflict resolution only applies to templates and instances derived from different base templates.

Click OK to start the import process.

When the import process is complete, you can start using the objects you imported.
Section 2 – Configuring Instances Through a .CSV File
Section Objective
This section discusses some fundamental functions dealing with Galaxy Maintenance. Specifically, it illustrates
how to Export a galaxy for future use and how to Import a galaxy created previously.

This section provides an understanding of fundamental functions dealing with Galaxy Maintenance.
Specifically, it illustrates how to Export for future use and how to Import a galaxy created previously.

Galaxy Dump
Object instances and their configuration data can be exported to a comma-delimited format Galaxy dump file
(.csv extension).
The Galaxy Dump 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:
a. 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.
b. Select Export on the Galaxy menu and then click Galaxy Dump.

The Galaxy Dump dialog box is displayed.

c. 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.
d. 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 has been created.

Galaxy Dump File (.csv) Structure
Dumped objects are organized in the resulting .csv file based on the template from which each is derived. A header row
per template indicates the instance’s columns’ reference. Comments can be added in the resulting .csv file by adding a line
preceded by a semi-colon.

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.
Galaxy Load
Object instances and their configuration data in an existing Galaxy can be exported to a comma-delimited
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

a. Select Import on the Galaxy menu and then click Galaxy Load.

The Galaxy Load dialog box is displayed.

b. 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. The options are:
 Replace entire instance if an instance of an object with the same name already exists and you want to replace it
entirely with the object in the import file.
 Only update changed attributes if an instance with the same name already exists and you want to replace only
the attributes of the object where the values are different.
 Skip if an instance with the same name already exists and you want to keep the version already in the Galaxy.
 Stop Galaxy Load if an instance with the same name already exists and you want to cancel the Galaxy Load.

c. 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.
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.
Section 3 – System Management Console (SMC)
Section Objectives
• Effectively utilize the System Management Console
• Configure the System Management Console

This section provides an understanding of role of the System Management Console and how it can be
configured.

About System Management Console

The System Management Console (SMC) provides ArchestrA Application Server 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 System Management Console

Some of the key features of the Platform Manager are that it:
• 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
To Start the System Management Console

Start Windows and click Start. Select All Programs/Wonderware/System Management Console.

The Platform Manager appears under the ArchestrA System Management Console (SMC) root node.
If the Galaxy has security enabled, the Platform Manager Login dialog box appears when the user attempts to access the
Platform Manager from the System Management Console (SMC).

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 will depend upon the software installed:
• Galaxy Database Manager (GR Node only)
• DAServer Manager (DAServer or WinPlatform deployed)
• Log Viewer (all Wonderware nodes)
• Platform Manager (all Application Server nodes)
• Other snap-ins (for example IndustrialSQL Server) will be available when other Wonderware software is installed

Each snap-in has its own toolbar, menu options, detail panel, and so on. The contents of these items will change as you
select different items in the console tree.

Security
For all ArchestrA administrative utilities, including Platform Manager, security is configured through the ArchestrA IDE. By
default, there is no security enabled for Platform Manager or any of the other snap-ins.

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.
Galaxy Backup / Restore
Be sure to back up your Galaxies so that if a Galaxy becomes corrupted, you can restore the Galaxy. You can choose a
backup file to overwrite an existing, corrupted Galaxy or to reproduce a Galaxy in another Galaxy Repository.
The Galaxy Database Manager is automatically installed on every Galaxy Repository node.

Backup
When running a Galaxy backup, no other applications may write to the GR node. Be sure to perform the backup
operation when no database-write operations will occur.
a. Select the Galaxy to backup, and select Action / Backup.
b. Name the .cab file to be created, and click Save.

c. Click Close when the backup is complete.

Create a new galaxy with a galaxy backup (.cab) file

You may also create a new galaxy using the .cab file created when a Galaxy backup is performed. You must first copy the
backup .cab file to:
C:\Program Files\ArchestrA\Framework\Bin\BackupGalaxies
In the New Galaxy window, create a new galaxy and select your backup Galaxy in the Galaxy type field.

Restore
When you restore a database from backup, any information saved to the database since the backup was performed is
overwritten with the restored information. All changes to the database since the backup are lost. Also, any transactions in
progress when the backup was performed are rolled back.

a. On the Action menu, click Restore.

b. Click Yes to continue restoring and No to terminate the restore function.

c. Select the name(.cab extension) of the backup file you want to use and click Restore.
If you have an active client connected to the Galaxy Repository, a message appears. You are required to quit those client
programs before restore can continue. A confirmation dialog box displays when the restore function is finished.

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.

Log Viewer
The ArchestrA Logger is a utility that records information regarding the activity occurring on the computer. For example,
it records start-up data, error conditions, and DAServer information.
The Log Viewer can:
• Monitor messages on any machine in the system
• Send a portion of the log to notepad or E-mail
• Filter messages on a flag

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 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.

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 dependent 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 Action menu when you select Log Viewer in either the
console tree or the details pane.

Command Description
Monitor System messages provide information about the state of the IndustrialSQL Server
historian as it starts up, runs, or shuts down. For more information about system
messages, see System Messages.
Open Log File Use this dialog box to locate and open a log file of saved messages.
Connect Allows the opening of a Log File
About Log Viewer Displays copyright and version information
New Create a new log file.
Refresh Update the contents of the Log File window.
Export List You can export the currently shown log messages to a log file. Log files have
an .aaLGX extension. The default file name is LogExport with the current date in
the format (mmddyyyy) appended as a suffix. You can edit the name of a log file
but not its extension.
Help Access to the System Management Console Help files
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
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

The Logger and Log Viewer are automatically installed when an ArchestrA component is installed.
 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 ArchestrA 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

a. Gather as much information first about the process that is malfunctioning. For instance, you attempted to deploy an
object in the ArchestrA IDE and a message was displayed stating the deployment was not completed. Note the function
you attempted and the message you received.
b. 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 ArchestrA 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.
c. 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.

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.
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

a. Right-click the message and click Add Bookmark on the Bookmark submenu.
b. 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.
c. Click OK to set the bookmark or Cancel to terminate the process.

To set a fast bookmark on a message

a. 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.
b. 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
a. On the View menu, click Go To.
b. In the Go To dialog box, enter the name of the message’s bookmark by typing it in the box or selecting from the list.
c. Click Go To. The Go To dialog box remains open.
d. Use the Previous and Next buttons to go to the nearest bookmarked message above and below, respectively.
e. 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.
To manage bookmarks
a. On the View menu, click Bookmarks.
b. 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.
c. 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.
d. To go to a bookmarked message, double-click on it in the list or select it and click Go To.
e. To remove one or all bookmarks from your logged messages, select a message and click Remove, or click Remove All.
f. 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.
g. 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.

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 Galaxy or an Engine, you can use the Action menu to start or stop the object, or set it OnScan/OffScan.
If the galaxy has security implemented, you must log on as a user configured with the proper SMC permissions to start
SMC, Start/Stop engines and platforms, or write from the Object Viewer.
Console Menu Commands
The following commands are available from the Platform Manager Action menu when you select a Platform in either the
console tree or the details pane.

The following commands are available from the Platform Manager Action menu when you select an Engine in either the
console tree or the details pane.

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.
Section 4 – Network Account Utility
Section Objectives
This section discusses the role of changing the network account and how to use the Change Network Account Utility to
accomplish that task. After discussing this section you will be able to:
• Understand the role of the Change Network Account Utility, and;
• Have an understanding of how it can be configured.

This section discusses the role of changing the network account and how to use the Change Network
Account and how to configure it.

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 Wonderware
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 ArchestrA IDE will stop functioning properly. If you delete the ArchestrA user account on an ArchestrA
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
a. Start the Change Network Account utility by selecting Start/All Programs/Wonderware/ Common/Change Network
Account.

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.
The Change Network Account utility allows you to change the current data shown in the dialog box, including:
 Changing the password of the current account.
 Creating a new local user account.
 Using an existing local machine or network domain account.

b. In a single-node ArchestrA system, create any account.

c. 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.
d. 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 ArchestrA 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).
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 You must have Administrator privileges on the computer to run this
required to run this utility. utility. Click OK, login as a user with Administrator rights, and start the
Change Network Account utility again.
The Password was not correctly You mistyped either the password or confirmation password in the
confirmed. Please ensure that the dialog box. These two passwords must match to ensure the accuracy
of user account data. Click OK, retype both password and
Password and Confirmation
confirmation
match exactly. password text, and then click OK again.
Password cannot be empty. You must type a password in the Change Network Account utility.
Please enter a valid password 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. You chose to create a local account by selecting Create Local
Please enter another user name. 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 You must enter an existing local machine or network domain account.
cannot be empty. Click OK, either type a valid network domain name or select the local
machine name from the list, and click OK. If you don’t know the valid
network domain name, ask your network administrator.
User account 'a' does not exist. You chose to use a local machine or network domain account that
Please enter another user name. 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 You chose to use a local machine or network domain user account
account allows the password to whose password policy allows the password to be changed or to
expire and to be changed. expire. Click OK if you want to use this account or Cancel to return to
However the password must not the Change Network Account utility. Then, you can choose to use or
expire or should not be changed create another user account. Caution! It is recommend that you do not
for the ArchestrA products to use a domain account whose password expires periodically or can be
function properly. Do you want to changed. Using such an account is allowed, but after the expiration
use this account? 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.
Do you want to update user You chose to use a local machine user account, but the password you
account 'a' to use this new typed does not match the account's password. Click OK if you want to
password? 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'. You typed an invalid network domain name in the Domain/Local
Please enter a valid domain Machine Name box. Click OK, retype the domain name, and click
name. OK.
Invalid Password for user You chose to use a network domain user account, but the password
account 'a'. Please enter the you typed does not match the account's password. Click OK, correct
correct password. the password, confirm the password, and click OK.

The system will now reboot. You changed account information in the Change Network Account
Please close all your open utility. The computer must be restarted to implement those changes.
applications and press "OK" Close open applications, and click OK.
when you are done.
User name cannot contain these You used one or more invalid characters in the User Name box. Click
characters: " / \\ [ ] : ; | , + * ? < > OK, type a valid user name and click OK.
Please enter a valid user name.
A user name cannot consist You must type a user name in the Change Network Account utility.
solely of periods [.] or spaces. 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. In the Network Connections dialog box (see image
below) you may choose to rename each card with a clearly identifiable function (for instance, “Supervisory Net” and “PLC
net”). Different operating systems provide unique access to the Network Connections dialog box.

You must order the network cards properly. In the Network 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 according to your network setup.

 
MODULE 8
Device Integration Products
Section 1 – Wonderware I/O Servers
Section 2 – Wonderware Data Access Servers
Section 3 – Device Integration Objects

Module Objectives
Obtain an overview and understanding of:
• DAServers and DI Objects and how they relate to the connectivity of your application to external data.
• FactorySuite Gateway and how it can enhance the connectivity of your application.
Section 1 – Wonderware I/O Servers
Section Objective
Configure a Wonderware I/O Server (Modbus)

This section will describe the configuration of a Wonderware I/O Server (Modbus).

Introduction
Wonderware I/O Servers are Microsoft Windows application programs that enable other DDE-aware Windows
applications (such as InTouch or Excel) access to data in the real world (such as PLCs or RTUs).
Wonderware servers are primarily intended for use with Wonderware's InTouch program; however, they can be
used by any Microsoft Windows program capable of acting as a DDE client.
In this section, we will examine the start-up, configuration and use of a Wonderware I/O Server. Because
Wonderware's I/O servers are Windows applications, they will all have the same basic appearance and
capabilities. Keep in mind that depending on server requirements, additional hardware (network, and so on)
may be necessary and the configuration screens may require additional information.
The following information references the Modbus I/O Server as a point-to-point server using the RS-232 serial
port to PLCs provided at the Wonderware Lake Forest facility training environment.

Configuring I/O Servers

Once the I/O Server has been installed, some configuration is required. Configuring the server automatically creates a
configuration file named MODBUSDV.CFG. This file stores the configuration information about communication ports and
all of the topic definitions (described in detail later).
The configuration file is automatically saved to the directory in which the I/O Server is installed unless a different directory
is specified via the Configure / I/O Server Settings command.

a. Select Start / All Programs / Wonderware / IOServers / Modicon MODBUS. The MODBUS dialog box appears:

b. Click Configure / Com Port Settings.

The Communication Port Settings dialog box appears. This dialog is used to configure the communication port that will
be used to communicate with the PLC equipment.

Com Port: Select the communication port that is connected to the PLC equipment.
Reply Timeout: Enter the amount of time (in seconds) that all PLCs connected via this serial communications port will be
given to reply to commands from the I/O Server.

Note: This timeout is sustained only when the PLC fails to respond. When the PLC is responding normally, there is no
penalty. The default value of 3 seconds should be sufficient for most configurations.

Protocol area: Select the protocol configured for the equipment attached to this communication port. RTU is
recommended.
Baud Rate area: Select the baud rate (serial bit rate) setting that matches the equipment connected to this
communication port.
Data Bits area: Select the option for the number of data bits that corresponds to the configuration of the
equipment on this communication port.
If ASCII is selected for the protocol, use 7. If RTU is selected, use 8.
Stop Bits area: Select the appropriate number of stop bits for the communication port. If the baud rate is greater than 300,
the stop bits should be set to 1.
Parity area: Select the setting that corresponds to the configuration of the equipment on this communication port.

Note: All devices on a single communication port must be configured with the same Protocol, Parity, Stop Bits, Data Bits
and Baud Rate.
For this training class, the following settings must be configured as shown.
c. Save your changes in the suggested directory and click Done to exit.

Note: Click Save to save the current settings entered for the selected communication port. The Communication Port
Settings dialog box remains displayed and another communication port can be configured.
Creating Topic Definitions
The Configure / Topic Definition command is used to create, modify, or delete topic definitions. One or more topic
definitions must exist for each PLC that the I/O Server will communicate with.
Each topic definition must contain a unique name for the PLC associated with it. This unique name is then used as the
topic name portion of the DDE Address for all DDE conversations to that PLC.
a. Click Configure / Topic Definition.
The Topic Definition dialog box appears:

Note: Once topics have been defined, their names will be listed in the Topics pane of this dialog box.

b. Click New to add a new topic definition.

The MODBUS Topic Definition dialog box appears:

c. Topic Name: Enter a unique name (up to 32-characters long) for the PLC in the field.

Note: When communicating with InTouch, this exact name is used as the topic name in the Access Name definition.

d. ComPort: Select the communications port to be associated with this topic.

 
e. Slave ID: Enter the Slave ID of the PLC in the box.
f. Slave Device Type: Drop-down list contains slave device types other than the default.
g. String Variable Style: The PLC will use this style to store ASCII strings in its registers.
h. Register Type: Select BINARY or BCD, based on hardware used.
i. Block I/O Sizes: Coil Read: Enter the maximum number of consecutive coils to be read at one
time. In this example, the valid coil read values can be between 8 and 2000 and must be an
even multiple of 8.
j. Coil Write: Enter the maximum number of consecutive coils that can be written to at one time.
In this example, the valid coil write values can be between 8 and 800 and must be an even
multiple of 8.
k. Register Read: Enter the maximum number of consecutive registers to be read at one time. In
this example, the valid register read values can be between 1 and 125.
l. Register Write: Enter the maximum number of consecutive registers that can be written to at
one time. In this example, the valid register write values can be between 1 and 100.
m. Update Interval: Enter the frequency (in milliseconds) that the I/O Server will read (poll) the
items/points associated with this topic. Different items/points can be polled at different rates by
defining multiple topic names for the same PLC and setting different update rates for each topic.
n. Click OK to accept the entries and close the dialog box.
The Topic Definition dialog box will open with the new topic listed:

o. Click the Done button to close this dialog box and return to the server's program window.
p. Click Modify to change an existing topic definition.
q. Click Delete to delete an existing topic definition.

Note: The previous information is provided for example only. Configuration steps for this class are provided in the following
lab.
Section 2 – Wonderware Data Access Servers
Section Objective
Become familiar with Wonderware Data Access Server and its use with Wonderware Application Server.

This section provides familiarization with Wonderware Data Access Server and its use with Application Server.

Introduction
Wonderware Data Access (DA) Server is designed to provide simultaneous connectivity between client applications based
on Wonderware SuiteLink, OPC and DDE protocols that run on the Microsoft Windows operating system and the data
devices supported by the specific protocol being translated.
The Wonderware 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:
 Compliance with OPC version 3.0
 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. A few of the current DAServers
Wonderware includes support for are:
 Allen-Bradley CIP protocol for ControlLogix
 Allen-Bradley TCP protocol
 Allen-Bradley DH Plus protocol
 Siemens Simatic Net S7
 Modbus Serial protocol

Component Architecture
A DAServer is comprised of three physical parts:
 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.
You must create the Device Protocol Layer (server specific) modules with the DAServer Toolkit, and all three sets of
modules are required for a fully functioning DAServer.

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.

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 server-specific code.
Here is a complete list of notifications to the server about changes in the configuration:
 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.
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.

One of the functions of the FS Gateway is to translate between ArchestrA MX protocol and other protocols. For instance, a
Wonderware 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 Wonderware products
without using InTouch tags. Using FS Gateway as a protocol translator allows direct connection to a Wonderware
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.
Section 3 – Device Integration Objects
Section Objective
Become more familiar with DI Objects and their use with Wonderware Application Server.

This section provides familiarization with DI Objects and their use with Wonderware Application Server.

Introduction
Device Integration (DI) Objects represent the application's network and devices, and mirror the actual device
hierarchy. In Application Server, Device Integration (DI) Objects are a subset of Automation Objects available
in the Template Toolset of the ArchestrA IDE. As a subset of these Automation Objects, Device Integration
Objects consist of two parts:
 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
ArchestrA IDE/Galaxy. This facilitates the DAServer installation process for end-users.
Several DI Objects are delivered and installed by default with your Application Server software. There are also
several DI objects available that are for specific DA Servers. These are available on the Wonderware Device
Integration DVD.

DI Object Advantages
Device Integration Objects (DI Objects) represent communication with external devices. DI Objects may be
DINetwork Objects (for example, the Redundant DI Object) or DI Device Objects. DI Objects (and their
associated AppEngine) can reside on any I/O, DA, or Automation Object Server node in the Galaxy. DI Objects
allow connectivity to data sources such as DDE servers, SuiteLink servers, OPC servers, and existing InTouch
applications.
The advantages of using DI Objects are as follows:
 DI objects allow you to configure, deploy, and monitor DAServers from one centralized location.
 DI Objects can be used to represent all devices and PLCs in a network, enabling representation of an entire plant,
including a hierarchical view of network connectivity.
 DI objects are so closely tied to the DAServer that when an object is deployed across the network, it remotely
installs the DAServer (This means that you can install the DAServer without going to the actual machine, and that
the DAServer connects immediately.).
 DI objects are very closely tied to the DAServer they are assigned to, so that when an object is deployed, it brings
with it all code, including registry, scripting, attributes, and parent.

Note that in a large project, this process may take some time. However, tremendous savings are achieved when
comparing centralized deployment with individual tasks should the Servers be separately installed and configured on each
node.

 
DI Objects in the ArchestrA 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:

Scan On Demand
Advanced Communication Management minimizes network traffic and CPU usage of a DIObject or DAServer. While the
client application is running, scanning for an attribute value is suspended when the owning object no longer appears in the
running application. For example, Advanced Communication Management suspends scanning for an object's attribute
value when the operator minimizes the application window containing the object. When the operator shows the window
containing the object again, Advanced Communication Management resumes scanning and the object's attribute value is
updated in the application.
Scanning can be configured using the following options:
Active
 Items are deleted and added to the scan group as requested (referenced) by the clients.
 Items that exist when a scan mode change occurs are not deleted unless the previous mode was ActiveAll and the
items are no longer referenced.
 The Active scan mode polls all points that are referenced, whether active or inactive.
 In Active scan mode an attribute is always in the active state. When the last reference to the attribute is
unregistered/unadvised, the attribute is deleted.

ActiveAll
 Scanning is continuous and dynamic attributes are never removed when unsubscribed.
 Items are activated by client requests, but continue to exist even after the client are not interested in them
anymore.
 Items are not removed when the scan mode changes.
 The scan group polls the field device for all points irrespective of whether they are currently active, inactive, or
even subscribed to by items.

ActiveOnDemand
 When the scan mode is configured as ActiveOnDemand, attributes that are not actively being referenced by any
client or object are made Inactive and are not scanned.
 New Items are deleted and added to the scan group as requested (referenced) by clients.
 Items that exist when a scan mode change occurs are not deleted unless the previous mode was ActiveAll and the
items are no longer referenced.
 ActiveOnDemand scan mode polls the field device for currently active items only. Inactive items are not scanned.

 
MODULE 9
Multi-Node Applications
Section 1 – Application Redundancy
Lab 18 – Configuring Application Redundancy
Section 2 – DI Redundancy
Lab 19 – Configuring the Redundant DI Object
Section 3 – Multi Node Application
Lab 20 – Convert to Network Environment

Module Objectives
Obtain an overview and understanding of:
 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.
Section 1 – Application Redundancy
Section Objective
 This section 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

This section provides an understanding of the concept of redundancy, how it can be configured and key points
to more effectively implement this feature. It also provides an understanding of 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:
 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.
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.
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 ArchestrA 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:
 IT Alarm provider-Areas
 Store Forward directories
 Common user-defined attributes (UDAs)
 Common scripting
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.

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

 
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 engine’s WinPlatform using the redundancy message channel (RMC).

Note: If some or all of these files already exist on the Standby AppEngine’s WinPlatform (perhaps, assigned to another
AppEngine on that platform), only the delta files are deployed to the Standby AppEngine.

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 AppEngine’s 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:
 Active: The state of an AppEngine when it has communication with its partner object, its partner is in Standby-Not
Ready, Standby-Sync’ing 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 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 AppEngine’s partner is
in one of the following states: Active-Standby not Available, Active, or Standby- Missed Heartbeats.
 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-Sync’d 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:
• 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 AppEngine’s 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:

Previous Current
Alarm Alarm Raised When Alarm Cleared When Alarm Reported By
State State
Standby -
Standby - Not Active Standby - Not Entering Standby - ACtive
Not
Ready 1 Ready Ready Ready Engine
Standby - Not Active Active - Active - Standby Not Entering Active Active
Available Standby Not Available Engine
Available
Failover Standby Becomes During the next scan Active
Occurred Active of the Active Engine Engine

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:
 Out of alarm
 Unacknowledged
 Unacknowledged-Return to normal
 Acknowledged-Return to normal
 Acknowledged

Timestamps are also preserved for alarms, including when:

 The alarm was acknowledged
 The alarm condition went true
 The alarm condition went false

Finally, the following information is preserved for alarms:

 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.

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:
 Cascade deploy from the Galaxy
 Multiple object selection deploy
 Deployment of the WinPlatform that hosts the Primary or Backup AppEngine

See the following table for a matrix of allowed operations based on specific conditions.

Deploy Both Primary and Cascade Deploy

Condition
Backup Objects Allowed
Backup AppEngine's host WinPlatform configured for failover Yes Yes
and deployed.
Backup AppEngine in error state. Yes Yes
Backup AppEngine's host WinPlatform not deployed. No Yes
Backup AppEngine's host WinPlatform not configured for Yes Yes
failover and deployed.
Deploy from Galaxy node. No Yes
Deploy from WinPlatform hosting Primary AppEngine. No Yes
Multiple object selection deploy. No No
Backup AppEngine's host WinPlatform not configured for No Yes
failover and not deployed.
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.

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:
 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.
Lab 18 – Configuring Application Redundancy
Introduction
This lab describes how to configure your galaxy for redundancy starting with the necessary network
configuration in Windows to properly handle a second network connection as the galaxy’s redundant message
channel.
Using the ArchestrA IDE, the galaxy is configured to become a two-node redundant system that will failover
between the two nodes when a failure occurs in the system.

Note: You need 2 computers and it is assumed that the required second network card is installed in both computers and
the crossover cable for the RMC is connected

Objectives
Upon completion of this lab you will be able to:
• Configure a second network connection in Windows as the redundant message channel
• Configure the $WinPlatform and $AppEngine object for redundancy
• Create a deployment model for redundant engines
• Force a failover on a redundant system
 Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Configure Windows network connections

Note: The following configuration needs to be done on BOTH computers.

a. Rename the network connections as follows: Local Area Connection to ArchestrA Local Area Connection 2 to
RMC
b. Use the network connections Advanced Settings to make sure that the ArchestrA connection is access before the
RMC connection.
c. Assign an IP address to the RMC in a different subnet than the ArchestrA connection.

Important! The IP address for the RMC connection on both computers must be different but in the same subnet.

d. On the Advanced setting for TCP/IP, configure the RMC connection to not Register this connection’s addresses in
DNS.

Configure the Galaxy for Redundancy

e. Undeploy the galaxy.

f. Configure the GRPlatform object’s Redundancy message channel IP address with its own RMC IP address.

g. Create a new instance of the $tWinPlatform template named Platform_001 and assign it to the ControlSystem area.

h. Configure the Platform_001 object with the name of the second computer and its own RMC IP address for the
Redundancy message channel IP address.

i. Configure the AppEngine object for Redundancy and assign its backup to the Platform_001 object.
 

Test Redundancy
j. Deploy the galaxy.

k. Using the watch list created in Lab 5, add a new watch window called Redundancy and add the following attribute
references:
Instance Attribute
AppEngine Host
AppEngine Redundancy.Identity
AppEngine Redundancy.Status
AppEngine Redundancy.PartnerPlatform
AppEngine Redundancy.PartnerStatus
AppEngine Redundancy.FailoverOcurred
AppEngine Redundancy.ForceFailoverCmd

l. Save the watch list.

m. Force a failover in the system and monitor the data using Object Viewer and the different watch windows created
during the class.
 
 
See the next page for Detailed Lab Instructions
Detailed Lab Instructions
Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Configure Windows network connections

Note: The following configuration (steps 1-13) needs to be done on BOTH computers.

1. Open Windows Network Connections by double-clicking on Start / Control Panel / Network Connections.
The Network Connections window appears.

2. Rename network connections as follows:

Local Area Connection to ArchestrA
Local Area Connection 2 to RMC

This is an optional step that enables you to easily identify each connection in this lab environment.
3. From the Advanced menu, select Advanced Settings.

4. In the Advanced Settings dialog box, Adapters and Bindings tab, make sure that the ArchestrA connection is listed
before the RMC connection and then click the OK button to close the dialog box.

Note: You can use the and buttons to arrange the access order.
5. Right-click on the RMC connection and select Properties.

6. In the RMC Properties dialog box, General tab, select the Internet Protocol (TCP/IP) item and click the Properties
button.

7. At the Internet Protocol (TCP/IP) Properties dialog box select the Use the following IP address option and assign an
IP address in a different subnet than the ArchestrA connection.
Important! The IP address for the RMC connection must be different on each computer but in the same subnet, and on a
different subnet than the ArchestrA node.

Note: In this example the first computer will have an IP address of 192.168.1.1 and the second computer will have an IP
address of 192.168.1.2. Both will be have a subnet mask of
255.255.255.0.

8. Click the Advanced button to continue.

9. In the Advanced TCP/IP Settings dialog box, select the DNS tab.
10. Uncheck the Register this connection’s address in DNS box.
11. Click the OK button to close the Advanced TCP/IP Settings dialog box.

12. Click the OK button to close the Internet Protocol (TCP/IP) Properties dialog box.
13. Click the Close button to close the RMC Properties dialog box.
Configure the Galaxy for Redundancy
14. Undeploy the GRPlatform object.
15. Double-click the GRPlatform instance to open its configuration editor.
16. In the Redundancy panel, Redundancy message channel IP address field, enter the IP address assigned to
the RMC connection you used for the first computer in step 7. In this example the first computer has an IP address
of 192.168.1.1

17. Click the Save and Close button and check in the object.
18. Create a new instance of the $tWinPlatform template named Platform_001.
19. Assign the new Platform_001 instance to the ControlSystem area.

20. Double-click the Platform_001 instance to open its configuration editor.

21. In the Network address field, enter the name of second computer.
22. In the Redundancy panel, Redundancy message channel IP address field, enter the IP address assigned to
the RMC connection you used for the second computer in step 7. In this example the second computer has an IP
address of 192.168.1.2
23. Click the Save and Close button and check in the object.
24. Double-click the AppEngine instance to open its configuration editor.
25. Select the Redundancy tab and configure the object as follows: Enable redundancy: checked

26. Click the Save and Close button and check in the object.
27. In Deployment view, assign the automatically created AppEngine (Backup) object to the Platform_001
instance.
Test Redundancy
28. Deploy the galaxy by right-clicking the name of the galaxy and selecting Deploy.
29. Open Object Viewer by right-clicking the AppEngine instance and selecting View in Object Viewer.
30. Load your saved Watch List.
31. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add a new tab to
the watch list.
32. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to
Redundancy.
33. Using the watch list created in Lab 5, add a new watch window named Redundancy with the following attributes from
the AppEngine instance:
 Host
 Redundancy.Identity
 Redundancy.Status
 Redundancy.PartnerPlatform
 Redundancy.PartnerStatus
 Redundancy.FailoverOccurred
 Redundancy.ForceFailoverCmd
Your data should look similar to the following:

34. Save the watch list.

35. Force a failover to the second computer by writing true to the ForceFailoverCmd attribute of the AppEngine.

You can use the Mixer1 watch window to verify that the objects are running properly.

36. Failover the system doing any of the following on the second computer:
• Unplug the power cable
• Shut down Windows
• Disconnect both network cables at the same time.

You can use the Mixer1 watch window to verify that the objects are running properly.
Section 2 – DI Redundancy
Section Objective
 This section 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

This section provides an understanding of the concept of redundancy, how it can be configured and key points
to more effectively implement this feature. It also provides an understanding of the concept and functionality of
Redundant DI Objects

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.
 
Configuration RedundantDIObjects
Configure redundancy in data acquisition objects in the ArchestrA 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 ArchestrA 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:
 Setting the Primary DI Source and Backup DI Source on the General tab of the object’s editor.
 Setting up the common scan groups, and block read and block write groups on the respective tabs of the object’s
editor.

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.
Lab 19 – Configuring the Redundant DI Object
Introduction
This lab describes the steps necessary to configure your galaxy for redundancy at the communication level with
the field by using two similar device integration objects connected to the same field device, such as a PLC.

Objectives
Upon completion of this lab you will be able to:
• Create a deployment model for redundant DI object
• Configure and use the $RedundantDIOObject
• Force a failover on a redundant DI system
Summary Lab Instructions
Following is a summary of the general steps you will complete for this lab. For detailed instructions, please refer to the
Detailed Lab Instructions on subsequent pages.

Configure DI Redundancy
a. Create two new instances of the $tAppEngine template, name them AppEngineDI1 and AppEngineDI2 and
assign them to the ControlSystem area.
b. Host AppEngineDI1 on the GRPlatform platform and AppEngineDI2 on Platform_001 platform.
c. Rename the InControl instance as DIO1 and host it on the AppEngineDI1 engine.
d. Create a copy of the DIO1 object by repeating Lab 6 but naming the object DIO2. Assign the new object to the
ControlSystem area and host it on the AppEngineDI2 engine.
e. Derived a new template from the $RedundantDIObject object, name it $tRedundantDIObject, and assign it to the
Training template toolset.
f. Create an instance of the $tRedundantDIObject template and name it InControl.
g. In the General tab, configure the object as follows:
Primary DI source: DIO1
Backup DI source: DIO2

h. In the Scan Group tab, copy the common scan groups and attributes from the primary or backup DI sources.
i. Host the InControl instance on the AppEngine object.

Test the Redundant DI Object

j. Deploy the AppEngineDI1, AppEngineDI2, DIO1, DIO2 and InControl objects.
k. Using the watch list created in Lab 5, add a new watch window called RDIO and add the following attribute
references:
Instance Attribute
InControl DISourcePrimary
InControl DISourceBackup
InControl DISourceActive
InControl DISourceStandby
InControl StatusPrimaryDISource
InControl StatusBackupDISource
InControl ConnectionStatus
InControl SwitchReason
InControl ForceFailoverCmd

l. Save the watch list.

m. Force a failover in the system and monitor the objects using Object Viewer and the different watch windows
created during the class.

See the next page for Detailed Lab Instructions Detailed Lab Instructions
Detailed Lab Instructions

Following are detailed lab instructions for completing this lab. For a summary of instructions, please refer to the Summary
Lab Instructions on the previous page(s).

Configure DI Redundancy
1. Create two new instances of the $tAppEngine template.
2. Name the new instances AppEngineDI1 and AppEngineDI2 and assign them to the ControlSystem area.

3. In the Deployment view, host AppEngineDI1 on the GRPlatform platform and AppEngineDI2 on Platform_001
platform.

4. Undeploy the InControl instance.

5. Rename the InControl instance DIO1.
6. Host the DIO1 object on the AppEngineDI1 engine.

7. Use Lab 6, “Connecting to the Field” to create another device integration object, but name it DIO2 instead of
InControl. Assign it to the ControlSystem area.

Note: You can export your object, rename the original, and then import the object to create a copy of the object with all of
the original object’s configuration attributes.
8. In the Deployment view, host the DIO2 object on the AppEngineDI2 engine.

9. Create a derived template from the $RedundantDIObject template named $tRedundantDIObject and assign it to
the Training template toolset.

10. Create an instance of the $tRedundantDIObject template named InControl and assign it to the ControlSystem
area.
Note: The template name InControl is used here to match the existing attribute references that were configured in the
objects and scripts in previous labs.

11. Double-click the InControl instance to open its configuration editor.

12. In the General tab, configure the object as follows:
Primary DI source: DIO1
Backup DI source: DIO2
13. Select the Scan Group tab and click on the Copy Common Scan Groups button.

14. In the Copy Common Scan Groups dialog box, click the OK button to accept tagname as the scan group for the new
InControl object.
15. Click on the Copy Attributes From Primary button.

16. Click the Save and Close button and check in the object.
17. In the Deployment view, host the new InControl object on the AppEngine engine.

Test the Redundant DI Object

18. Deploy the AppEngineDI1 object on cascade.
19. Deploy the AppEngineDI2 object on cascade.
20. Deploy the InControl object.
21. Open Object Viewer by right-clicking the InControl instance and selecting View in Object Viewer. If you closed
Object Viewer before, you can use File / Load Watch List to open the file you saved earlier.
22. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch Window to add a new tab
to the watch list.
23. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list
to RDIO.
24. Add the following attributes from the InControl instance to the watch list:
 DISourcePrimary
 DISourceBackup
 DISourceActive
 DISourceStandby
 StatusPrimaryDISource
 StatusBackupDISource
 ConnectionStatus
 SwitchReason
 ForceFailoverCmd
 SwitchCnt
Your data should look similar to the following:

25. Save the watch list.

26. Force a failover to the second device integration object by writing true to the ForceFailoverCmd attribute of the
Redundant DI Object. You can use the Mixer 1 watch window to verify that the objects are running properly.

27. Failover the system doing any of the following on the second computer:
 Unplug the power cable
 Shut down Windows
 Put the DIO2 object off scan
You can use the Mixer 1 watch window to verify that the objects are running properly.
Section 3 – Multi Node Application
Section Objective
This section deals with migrating from a standalone configuration to a network configuration. At the conclusion of this
section you will have an understanding of the steps necessary to migrate to a network environment.

This section provides an understanding of how to migrate from a standalone configuration to a network
configuration. At the conclusion of this section you will have an understanding of the steps necessary to migrate
to a network environment.

Standalone to Network Configuration

Earlier we discussed the standalone configuration you have been using up to this point. At this time you 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 ArchestrA IDE, and a Galaxy Repository. Once you have
reconfigured the environment there will be one machine (Node1) that will contain the Bootstrap, the ArchestrA
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 ArchestrA 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:

 
The networked environment that you are migrating to is illustrated as follows:
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 a need for only one PLC so the one residing on the resulting Galaxy Repository node is the one that is
most likely the one desired for the network. Therefore, that is the one and only one that is to be exported in
preparation for the network environment.
The node that contains the Galaxy Repository must do several tasks before any other nodes can connect.
These include:
• 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.

 
APPENDX A
Wonderware 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 Server
The supervisory control platform. Application Server uses existing Wonderware products such as InTouch for visualization,
the Wonderware Historian for data storage, and the device Integration product line like a Data Access Server (DAServer)
for device communications. An Application Server can be distributed across multiple computers as part of a single Galaxy
Namespace.
Application Views
The Application Views pane displays the object-related contents of the Galaxy in different ways: Model view,
Deployment view, Derivation view and Operations view. The Model view is the default display when the
ArchestrA 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 programmer’s 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.
Automation Object Server (AOS)
A computer that hosts one or more application engines and associated automation objects. A Wonderware
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 saving 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, it’s Hierarchical Name = Line1.Tank1.InletValve and its
Contained Name= InletValve
Containment
A 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 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 (DIObjects). 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 AutomationObject Server. 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.
Element
Basic shapes, such as rectangles, lines, and text elements, and controls you can use to create an ArchestrA Symbol to
your specifications.
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).
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
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 PC’s 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.
Graphic Toolbox
The part of the IDE main window that shows a hierarchy of graphic toolsets, which contain ArchestrA Symbols and
client controls.
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 Wonderware 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.
Wonderware Application Server
2
Refers to the Wonderware A Supervisory Control Platform, commonly known as the Application Server. The
Wonderware 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
Wonderware 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 Wonderware Application Server uses InTouch v8.0 or InTouch View v8.0 for visualization
with the addition of Platforms to the visualization node.
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.
Integrated Development Environment (ArchestrA IDE)
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 Wonderware A2 Development License.
InTouch View
InTouch View Clients are InTouch Runtime Version 8.0 clients that solely use of the Wonderware Application
Server for its data source. In addition, standard InTouch v8.0 runtimes can leverage the Wonderware
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 Wonderware 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 Wonderware 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 object’s
data value, data quality and the communication status of the object, you can also modify some of it’s attributes for
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 Historian
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 Wonderware Application Server or InTouch® HMI. For example, there is a Proxy Object that enables
the Wonderware Application Server to access an OPC server.

Redundancy 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.

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 object’s 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
Wonderware Application Server security is applied to the ArchestrA IDE, the System Management Console (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 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 system-wide message exchange component, a
set of basic services, the operating system, and the physical hardware. This object hosts all AppEngines.