Wonderware Training

W O N D E R W A R E T R A I N I N G

Training Manual
Revision A
April 2019
Part Number 11-GM-10096

y
op
C
ot
N

Application Server 2017

o
D

Update 3
© 2019 AVEVA Group plc and its subsidiaries. All rights reserved.

No part of this documentation shall be reproduced, stored in a retrieval system, or transmitted by any means,
electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of AVEVA.
No liability is assumed with respect to the use of the information contained herein.

Although precaution has been taken in the preparation of this documentation, AVEVA assumes no
responsibility for errors or omissions. The information in this documentation is subject to change without
notice and does not represent a commitment on the part of AVEVA. The software described in this
documentation is furnished under a license agreement. This software may be used or copied only in
accordance with the terms of such license agreement.

ArchestrA, Aquis, Avantis, Citect, DYNSIM, eDNA, EYESIM, InBatch, InduSoft, InStep, IntelaTrac, InTouch,

y
OASyS, PIPEPHASE, PRiSM, PRO/II, PROVISION, ROMeo, SIM4ME, SimCentral, SimSci, Skelta,
SmartGlance, Spiral Software, Termis, WindowMaker, WindowViewer, and Wonderware are trademarks of

op
AVEVA and/or its subsidiaries. An extensive listing of AVEVA trademarks can be found at: https://
sw.aveva.com/legal. All other brands may be trademarks of their respective owners.

Contact Information C
AVEVA Group plc
High Cross
Madingley Road
Cambridge
ot

CB3 OHB. UK

https://sw.aveva.com/

For information on how to contact sales, customer training, and technical support, see https://sw.aveva.com/
N

contact.
o
D
 Table of Contents 1

Table of Contents
Module 1 Introduction .................................................................................1-1
Section 1 – Course Introduction......................................................................... 1-3
Section 2 – System Platform Overview.............................................................. 1-7
Section 3 – Application Server Overview......................................................... 1-11
Lab 1 – Creating the Galaxy ............................................................................ 1-15
Section 4 – The ArchestrA IDE ........................................................................ 1-19
Section 5 – Automation Objects....................................................................... 1-29
Lab 2 – Creating Global Derived Templates.................................................... 1-41
Section 6 – System Requirements and Licensing ........................................... 1-49

Module 2 Application Planning ..................................................................2-1

Section 1 – Application Server Project Workflow............................................... 2-3
Section 2 – Case Study ..................................................................................... 2-5

Module 3 Application Infrastructure ..........................................................3-1

y
Section 1 – The Plant Model.............................................................................. 3-3
Section 2 – The Deployment Model................................................................... 3-5

op
Lab 3 – Creating the Plant and Deployment Models ....................................... 3-11
Section 3 – System Management Console...................................................... 3-27
Section 4 – The Runtime Environment ............................................................ 3-35
Lab 4 – Using Object Viewer ........................................................................... 3-41
Section 5 – Data Simulation............................................................................. 3-53
C
Lab 5 – Configuring for Data Simulation .......................................................... 3-55

Module 4 Application Objects ....................................................................4-1

ot

Section 1 – Introduction to Application Objects ................................................. 4-3

Section 2 – Object Attributes ............................................................................. 4-7
Lab 6 – Modeling Meters ................................................................................. 4-15
Section 3 – Change Control and Propagation ................................................. 4-27
N

Lab 7 – Configuring Change Control and Propagation .................................... 4-31

Section 4 – Containment.................................................................................. 4-41
Lab 8 – Modeling the Mixer.............................................................................. 4-45
o

Module 5 Device Integration .......................................................................5-1

Section 1 – Device Integration Servers.............................................................. 5-3
D

Lab 9 – Configuring the OI Server ..................................................................... 5-7

Section 2 – Device Integration Objects............................................................ 5-15
Lab 10 – Configuring the Device Integration Object ........................................ 5-21
Section 3 – Connecting Application Objects to Field Data............................... 5-29
Lab 11 – Connecting the Mixer to the Field ..................................................... 5-31
Section 4 – Device Integration Redundancy.................................................... 5-37
Lab 12 – Configuring the Redundant DI Object ............................................... 5-41

Module 6 History..........................................................................................6-1
Section 1 – Historizing Data for Application Server ........................................... 6-3
Lab 13 – Configuring and Retrieving History ................................................... 6-11

Module 7 Alarms and Events......................................................................7-1

Section 1 – Alarms and Events Overview.......................................................... 7-3
Lab 14 – Configuring and Interacting with Alarms ........................................... 7-23

Application Server 2017 Update 3

2 Application Server 2017 Update 3

Module 8 Object Management ................................................................... 8-1

Section 1 – Object Export and Import ................................................................ 8-3
Lab 15 – Exporting and Importing Objects ....................................................... 8-11
Section 2 – Galaxy Dump and Galaxy Load .................................................... 8-29
Lab 16 – Configuring Instances Using a .CSV File .......................................... 8-35

Module 9 Security ....................................................................................... 9-1

Section 1 – Security Overview ........................................................................... 9-3
Lab 17 – Configuring Security .......................................................................... 9-11
Section 2 – Object Security .............................................................................. 9-37
Lab 18 – Implementing Object Security ........................................................... 9-41

Module 10 Introduction to QuickScript.NET............................................. 10-1

Section 1 – Introduction to Scripting................................................................. 10-3
Lab 19 – Adding Auto Reconnect to the DDESuiteLinkClient Object............. 10-11
Section 2 – Variables and Control Statements............................................... 10-21
Lab 20 – Scripting Valve Status ..................................................................... 10-29
Lab 21 – Scripting Custom Alarms ................................................................. 10-37

y
Module 11 Galaxy Backup and Restore .................................................... 11-1

op
Section 1 – Galaxy Backup and Restore.......................................................... 11-3

C
ot
N
o
D

Wonderware Training
 y
op
Module 1 – Introduction
C
Section 1 – Course Introduction 1-3
ot

Section 2 – System Platform Overview 1-7

Section 3 – Application Server Overview 1-11
N

Lab 1 – Creating the Galaxy 1-15

Section 4 – The ArchestrA IDE 1-19
o

Section 5 – Automation Objects 1-29

D

Lab 2 – Creating Global Derived Templates 1-41

Section 6 – System Requirements and Licensing 1-49
1-2 Module 1 – Introduction

Module Objectives
 List the objectives of the course and describe the agenda
 Describe the System Platform and Application Server
 Introduce the ArchestrA IDE
 Describe Automation Objects
 Explain the system requirements for Application Server
 Explain licensing and product security of System Platform and Application Server

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Course Introduction 1-3

Section 1 – Course Introduction

This section describes the course and its objectives, intended audience, prerequisites, and
agenda.

Course Description
The Application Server 2017 Update 3 course is a 4-day, instructor-led class designed to provide
an overview of the features and functionality of Application Server. This course provides lectures
and hands-on labs to supply and reinforce the knowledge necessary to use these features and
functions for plant modeling.
The class demonstrates how to use Application Server technology to connect to field devices,
process data, run scripts, handle alarms, and historize alarms and events. This course also
provides a fundamental understanding of application maintenance, real-time alarm recording, and
security settings, and describes how to set up redundancy for data acquisition.

y
Objectives

op
Upon completion of this course, you will be able to:
 Create a new application
 Model the plant floor

C
Employ rapid prototyping using a data simulator
 Acquire data from field devices
 Configure data communication redundancy
ot

 Work with alarm and history configurations in an application

 Maintain application functionality using import and export
 Define the security model for the application
N

 Implement .NET Scripting to enhance application functionality

 Back up and restore an application
o

Audience
D

Individuals who need to configure or modify Application Server applications

Prerequisites
Knowledge of the following tools, features, and technologies is required:
 Industrial automation software concepts

Application Server 2017 Update 3

1-4 Module 1 – Introduction

Course Outline

Module 1 – Introduction
Section 1 – Course Introduction
This section describes the course and its objectives, intended audience, prerequisites, and
agenda.
Section 2 – System Platform Overview
This section describes fundamental concepts about System Platform, including its clients,
components, and services. It also introduces the ArchestrA technology.
Section 3 – Application Server Overview
This section describes Application Server and its components and discusses what a Galaxy is
and how to create one.
Section 4 – The ArchestrA IDE
This section describes the ArchestrA IDE, including the layout, its key functions, toolboxes and

y
how to create them, and the application views available.
Section 5 – Automation Objects

op
This section describes automation objects, templates, and instances. It discusses the Object
Editor, explains the different states of automation objects and operations when editing objects,
and gives a brief explanation of Object Wizards.
C
Section 6 – System Requirements and Licensing
This section describes the System Platform computer roles, the software and hardware
requirements for Application Server, the ArchestrA Network Account, and how the product is
secured and licensed.
ot

Module 2 – Application Planning

N

Section 1 – Application Server Project Workflow

This section describes the suggested project workflow.
Section 2 – Case Study
o

This section describes the simulated manufacturing environment to be used for the course
and explains the naming conventions used in the simulated process.
D

Module 3 – Application Infrastructure

Section 1 – The Plant Model
This section describes the importance of the plant model and explains the usage of area
objects and the Model view in the ArchestrA IDE.
Section 2 – The Deployment Model
This section describes the Deployment view of the ArchestrA IDE, discusses the hosting
relationship between objects, explains the usage of the $WinPlatform and $AppEngine
objects, and describes the Deployment options.
Section 3 – System Management Console
This section describes the overall functionality of the System Management Console (SMC). It
explains how to back up and restore using the Galaxy Database manager, and includes how
to create a new Galaxy from a backup file. It discusses how to use the ArchestrA Logger and
Log viewer, and explains how to use Platform Manager.

Wonderware Training
 Section 1 – Course Introduction 1-5

Section 4 – The Runtime Environment

This section describes the runtime environment of the Galaxy, explains communication
between automation objects’ attribute references, and introduces Object Viewer and Platform
Manager tools.
Section 5 – Data Simulation
This section describes the OI Simulation Server and explains the configuration of an
$OPCClient to the OI.SIM.

Module 4 – Application Objects

Section 1 – Introduction to Application Objects
This section describes the application objects in the Galaxy and discusses the basic
configuration of the $UserDefined object.
Section 2 – Object Attributes
This section describes the Attributes tab and the features of an attribute. It also discusses the
configuration options available for application objects, including automatic and manual I/O

y
binding capabilities.

op
Section 3 – Change Control and Propagation
This section describes attribute locking and unlocking. It also discusses how template
changes can propagate to previously derived objects.
Section 4 – Containment
C
This section describes containment with templates and application objects, and explains
different modeling approaches. It also discusses the naming conventions of contained objects.
ot

Module 5 – Device Integration

Section 1 – Device Integration Servers
This section describes available DI servers, discusses OI servers, and explains the
N

configuration of an OI Server to a Controller.

Section 2 – Device Integration Objects
This section describes DI objects, explains the configuration of a DI object to an OI Server,
o

and discusses how to monitor the connectivity of a DI object in Object Viewer.

D

Section 3 – Connecting Application Objects to Field Data

This section describes how to change the data source for objects using the autobind
capabilities of application objects.
Section 4 – Device Integration Redundancy
This section describes DI redundancy and explains how to configure a Redundant DI Object.

Module 6 – History
Section 1 – Historizing Data for Application Server
This section describes how Historian historizes data. It explains how to configure engines and
platforms for historization and describes how to configure objects to historize attributes. It also
discusses how to retrieve historical data with Insight.

Application Server 2017 Update 3

1-6 Module 1 – Introduction

Module 7 – Alarms and Events

Section 1 – Alarms and Events Overview
This section describes alarms and events. It explains alarms and events reporting of objects
through areas, the alarm options for attributes, and how to monitor alarm attributes and states
with Object Viewer. It discusses the historization of alarms and events with Historian, as well
as how to retrieve alarm history from SQL Server.

Module 8 – Object Management

Section 1 – Object Export and Import
This section describes how to export and import objects from and to a Galaxy. It also explains
how to upgrade objects to new versions or revert to previous configurations.
Section 2 – Galaxy Dump and Galaxy Load
This section describes how to use the Galaxy Dump and Galaxy Load features of the
ArchestrA IDE. It explains how to use these features to modify and create instances of objects.

y
Module 9 – Security

op
Section 1 – Security Overview
This section describes how ArchestrA handles security. It discusses the security models
available in the ArchestrA IDE and describes how to configure general security permissions
and operational permissions.
C
Section 2 – Object Security
This section describes the security classifications for object attributes and discusses the
security audit trail.
ot

Module 10 – Introduction to QuickScript.NET

N

Section 1 – Introduction to Scripting

This section describes the scripting environment and basic scripting syntax. It also discusses
the execution types and triggers.
o

Section 2 – Variables and Control Statements

This section describes the usage of variables and control statements in a script.
D

Module 11 – Galaxy Backup and Restore

Section 1 – Galaxy Backup and Restore
This section briefly describes the SMC and explains how to back up and restore operations
using the Galaxy Database manager. It includes a discussion on how to create a new Galaxy
from a backup file.

Wonderware Training
 Section 2 – System Platform Overview 1-7

Section 2 – System Platform Overview

This section describes fundamental concepts about System Platform, including its clients,
components, and services. It also introduces the ArchestrA technology.

Introduction
System Platform is an industrial software platform built on ArchestrA technology. It contains an
integrated set of services and an extensible data model to manage plant control and information
management systems. System Platform supports both the supervisory control layer and the
manufacturing execution system (MES) layer, presenting them as a single information source.
System Platform and its clients provide the framework and tools for developing, executing,
monitoring, and visualizing your applications. Services such as data acquisition, historization, and
alarming are provided by System Platform components. Services such as visualization and
trending are provided by System Platform clients.

y
The System Platform software is based on industry standards and Microsoft technologies, such as
Windows, .NET, SQL Server, IIS, and others. ArchestrA provides the fundamental technology and

op
services for the multi-user, object-oriented platform.
Additional functional modules, such as Manufacturing Execution System (MES), Skelta BPM
Workflow Management, and others, are available to extend the functionality of System Platform
and its clients.
C
ot
N
o
D

Application Server 2017 Update 3

1-8 Module 1 – Introduction

System Platform Components and Clients

System Platform components access and process external data from controllers, software
applications, and other data sources. System Platform clients access information from System
Platform.

y
op
System Platform components are as follows:
 Application Server is the heart of System Platform. It provides an object-oriented
framework with tools for developing and deploying applications.
C
 Historian provides process data historization and alarm and event logging for Application
Server. Data is exposed through SQL Server and/or an Open Data Protocol (oData)
interface.
 Communication Drivers are drivers for communicating with third-party controllers. These
ot

come in the form of OI Servers and IO Servers. System Platform also works with third-
party drivers, such as third-party OPC Servers.
System Platform clients include:
N

 Supervisory clients run the operator interface and provide real-time access to
Application Server data, alarms, and events. There are two supervisory client products,
based on different technologies. Both can coexist in the same System Platform solution.
o

 InTouch Operations Management Interface has a rapid-design visualization

framework with tools, and provides the ability to automatically navigate and display
D

graphics based on the application's data model.

 InTouch for System Platform is based on traditional development tools to create
displays and corresponding navigation.
 Historian Client is a collection of tools for accessing and reporting on data historized with
Historian. This client includes a Trend application for plotting data on a graphical display, a
Query application for constructing SQL queries through a point-and-click interface, and
add-ins to Microsoft Excel and Word for generating reports.
 Insight is a browser-based tool for quick data query, trending, and analysis. Pulling data
from Historian, it enables visualization of how your operations are performing.

Wonderware Training
 Section 2 – System Platform Overview 1-9

Together, System Platform and its clients provide the core services needed to develop, implement,
and deploy industrial automation applications. Some of these services include:
 Real-time data acquisition from field devices
 Scaling, statistics, and manipulation of data
 Process control
 Alarm triggering, logging, acknowledgement, and management
 Historization, trending, and analysis of process data
 Visualization of real-time process data
 Reporting
Applications built on System Platform are extensible through the use of scripting within the product
itself or through several available toolkits. For example, an application can access a third-party
web service by means of a script.

ArchestrA Technology

y
ArchestrA is a distributed architecture developed for supervisory control and manufacturing
information systems. It is an open and extensible technology based on a distributed, object-

op
oriented design. It is built on .NET and leverages the Microsoft Framework for the industrial
automation world.
ArchestrA provides the following system services:
C
 Object management for creating object-oriented applications
 A component object framework for application modeling of plants, factories, and
equipment
ot

 A common, global name space for all application types, from single-node to distributed,
and networked applications
 Inter-process advanced communications with system maintenance and diagnostic
information
N

 Centralized security services with support for multi-user environments for development
and runtime
 Version management for every object in the application, including logging of development
o

operations
Most of these services are exposed, configured, and managed by Application Server.
D

Application Server 2017 Update 3

1-10 Module 1 – Introduction

y
op
C
ot
N
o
D

Wonderware Training
 Section 3 – Application Server Overview 1-11

Section 3 – Application Server Overview

This section describes Application Server and its components and discusses what a Galaxy is
and how to create one.

Application Server
The Application Server is the heart of the System Platform; it provides the services and tools to
create, manage, and deploy your application. An application created with Application Server is
called a Galaxy; both terms are interchangeable.
Based on an object-oriented framework, Application Server allows you to "assemble" a project out
of smaller, individual objects that represent the different parts of your plant and your application.
These are assembled from an area or a section of the factory, to every equipment in the field
(valve, tanks, pumps, and so on), to the actual computers running your application. Almost
everything that is part of your project is modeled as an object in a Galaxy. A point-and-click
interface allows you to easily create, configure, and manage your objects, and at the same time

y
allows the extension and enhancement of your application through integration with the .NET
Framework, particularly through a powerful scripting engine.

op
Applications created with Application Server have distributed capabilities by nature. Going from
one computer to a multi-node networked environment is simply a matter of modeling the
computers that will be part of your project and distributing the load of your application (objects)
across them. This same functionality allows you to easily create and deploy redundant
configurations.
C
Some of the main characteristics and benefits of Application Server are:
 Object-oriented framework that provides a modeling approach to creating and managing
ot

applications
 Native support for DDE, SuiteLink, and OPC to access Wonderware and third-party
drivers, such as OI Servers and legacy IO Servers
N

 Multi-user development environment

 Self-documenting objects and versioning
 Security features to prevent users from performing unauthorized activities within the
o

development and runtime environments

 Redundancy capabilities for the application and for I/O communications
D

 Diagnostics tools for troubleshooting the application

 Extensibility through a scripting engine with .NET capabilities
 Out of the box graphic libraries; one of them designed to create Situational Awareness
HMIs

Application Server 2017 Update 3

1-12 Module 1 – Introduction

Application Server Components

Application Server is not a single piece of software but a set of software components, tools, and
services that work together for the development and deployment of industrial automations
systems. It is comprised of three software components:
 The Bootstrap is a Windows Service that provides the required software for a computer to
be able to receive a platform (a component from your application that makes the computer
part of your application)
 The ArchestrA IDE (Integrated Development Environment) is Application Server's
development tool for creating, configuring, and deploying your application
 The Galaxy Repository is a Windows Service that manages the development and
deployment of the application; the computer running the Galaxy Repository software hosts
the configuration project database

The Galaxy and the Galaxy Repository

A Galaxy is the entire application. It is the project database and configuration information, as well

y
as the single logical name space of your deployed application (runtime environment). It is
composed of:

op
 A collection of objects that represent all your physical and logical entities in your
application; from computers and runtime engines, to all the equipment in the field
 A project database that holds the configuration information
 One or more networked computers running the application
C
 A common set of system-level policies that all components and objects comply with, such
as security, alarm, and communications settings
The Galaxy Repository software, a Windows Service, manages the development and deployment
ot

of the Galaxy. The project database is hosted in the same computer where the Galaxy Repository
software is installed.
N

Important: While a Galaxy Repository can host more than one Galaxy, only one Galaxy can be
deployed and running at any given time.

For runtime, the objects in the Galaxy can be deployed to multiple computers for load balancing,
o

task distribution, and redundancy. A key benefit of the single namespace is that it allows objects
and process data to be referenced by scripts, graphics, and other objects from any computer in the
D

Galaxy without specifying the object's location.

One of the main objects in any Galaxy is the WinPlatform object, which represents a computer in
the Galaxy. A WinPlatform object adds a computer to the single namespace on deployment, at
which point it is said that the Galaxy "owns" that computer. Only one WinPlatform object can be
deployed to a computer at any given time; therefore, in runtime, a computer can belong to one and
only one Galaxy.
Multiple Galaxies deployed on the same network environment are isolated from each other and, by
default, cannot access each other's data. Galaxies can be configured for multi-Galaxy
communication allowing two or more Galaxies on the same network to access each other's data in
runtime.

Wonderware Training
 Section 3 – Application Server Overview 1-13

Creating and Connecting to a Galaxy

The ArchestrA IDE is used to create, configure, and manage a Galaxy. The ArchestrA IDE cannot
be started in a Galaxy-neutral state, so when starting the ArchestrA IDE, the Connect to Galaxy
dialog box is first displayed.

y
op
This dialog box is used to:
 Connect to the selected Galaxy in the specified Galaxy Repository node and open the
ArchestrA IDE. If the selected Galaxy has security enabled, it will prompt you for login
credentials.
C
 Create a new Galaxy in the specified Galaxy Repository node.
 Delete the selected Galaxy from the specified Galaxy Repository node. As a safety
ot

measure, Galaxies with objects deployed cannot be deleted.

When creating a new Galaxy, you use the Galaxy type to indicate what will be the default content
of the new Galaxy.
N
o
D

The following Galaxy types are available out-of-the-box:

Default_EMPTY.cab – Creates a baseline Galaxy that contains only base template objects.
Default.cab – The recommended starting point for creating a new Galaxy; contains default
screen profiles, templates, a basic equipment mode, and an InTouch OMI View App example
that provides an introduction to key features.
Base_InTouch.cab – Creates a Galaxy that includes only the objects and graphics needed for
tag-based Managed InTouch applications.
Reactor_Demo_InTouch.cab – Creates a Galaxy with a version of the Reactor Demo, based
on a tag-based Managed InTouch application.
Other Galaxy types can be made available using backups of other Galaxies; this allows the
distribution of standards, such as preconfigured objects, graphics, and system-level settings.

Application Server 2017 Update 3

1-14 Module 1 – Introduction

y
op
C
ot
N
o
D

Wonderware Training
 Lab 1 – Creating the Galaxy 1-15

Lab 1 – Creating the Galaxy

Introduction
In this lab, you will create a Galaxy and connect to it using the System Platform IDE (ArchestrA
IDE). This Galaxy will be used during the course.

Objectives
Upon completion of this lab, you will be able to:
 Create a Galaxy
 Connect to a Galaxy using the System Platform IDE

y
op
C
ot
N
o
D

Application Server 2017 Update 3

1-16 Module 1 – Introduction

Create the Galaxy

First, you will create a Galaxy and connect to it.
1. Open the System Platform IDE (ArchestrA IDE).
The Connect To Galaxy dialog box appears with the local node name displayed in the
GR node name drop-down list. Once a Galaxy has been created and accessed, the last GR
node name to which it was connected will be shown by default.
2. Click the New Galaxy button to create a new Galaxy.

y
op
C
ot

The New Galaxy dialog box appears.

3. In the Galaxy name field, enter TrainingGalaxy.
4. In the Galaxy type drop-down list, select Default_EMPTY.cab.
N
o
D

5. Click Create.

Wonderware Training
 Lab 1 – Creating the Galaxy 1-17

The Create Galaxy dialog box appears and shows the Galaxy creation progress. This will take
a few moments.

When complete, the Create Galaxy progress displays 100% completed.

y
6. Verify there are no error messages.

op
C
ot
N
o

Note: Notify your instructor, if there are any error messages.

D

7. Click Close.

Application Server 2017 Update 3

1-18 Module 1 – Introduction

The TrainingGalaxy you entered in Step 3 has been created and now appears in the Galaxy
name drop-down list.

y
op
8. Click Connect.
The Connect To Galaxy dialog box closes and, after a few moments, the ArchestrA IDE
opens. C
ot
N
o
D

You will use the ArchestrA IDE to develop the Galaxy throughout the remainder of this course.

Wonderware Training
 Section 4 – The ArchestrA IDE 1-19

Section 4 – The ArchestrA IDE

This section describes the ArchestrA IDE, including the layout, its key functions, toolboxes and
how to create them, and the application views available.

The ArchestrA IDE

The ArchestrA IDE is the configuration and development tool for the Galaxy. It accesses the
Galaxy Repository, local or remote, and connects to the Galaxy. Once connected to the Galaxy,
the ArchestrA IDE allows the configuration of Galaxy-wide settings (such as Security), as well as
the creation and configuration of automation objects (such as a valve) and graphics.

y
op
C
ot
N

All operations commanded through the ArchestrA IDE are actually run by the Galaxy Repository
o

service; the ArchestrA IDE simply sends commands and requests to the Galaxy Repository and
waits for status responses or confirmations. For example, when connected to a remote Galaxy
Repository you deploy an object, the actual deployment task will be executed from the Galaxy
D

Repository computer to the target platform, not from the computer running the ArchestrA IDE.
If the Galaxy has security enabled, the ArchestrA IDE will ask for login credentials; access to the
tool, as well as operations within the tool, will be dictated by the permissions assigned to the user.

Application Server 2017 Update 3

1-20 Module 1 – Introduction

Key Functions
Use the System Platform IDE shortcut to open the ArchestrA IDE. Upon opening the ArchestrA
IDE, the Connect to Galaxy dialog box is first displayed. Once connected to a Galaxy, the
ArchestrA IDE application allows the configuration of Galaxy-wide settings as well as the creation
and configuration of automation objects and graphics.
Some of the Galaxy-wide settings that can be configured with the ArchestrA IDE include:
 Security configuration and permissions
 Language definition for multi-language applications
 I/O communication management
 Global graphic styles
 Time master computer for time synchronization across all Galaxy nodes
 Alarms and events logging parameters
 User preferences
 Multi-Galaxy communications

y
When working with objects, the ArchestrA IDE allows:
 Creation of new objects

op
 Configuration of existing objects, such as I/O points, alarm definitions, and process data to
historize
 Check-out/Check-in functionality for versioning control
C
 Deployment and undeployment of objects
 View object properties, such as error and warning messages, as well as cross-reference
information
Upload changes to the runtime version of the object to the configuration database
ot

The ArchestrA IDE also includes import and export capabilities, including:
 Objects
N

 Global graphic styles

 Script function libraries, such as .NET assemblies to use within a script
 Localization strings to easily translate text between different languages
o

Toolboxes and Application Views

D

The ArchestrA IDE main window displays several toolboxes and views that are used to work with
automation objects and graphics; out-of-the-box, it includes two toolboxes and six views (five of
them are visible by default).
Other software products might include extensions to the ArchestrA IDE that add more toolboxes or
views, or both; these new components might serve another purpose than to work with objects in
the Galaxy. For example, Skelta BPM includes an extension for the ArchestrA IDE that adds a
Workflow toolbox to interact with the Workflow Sever.

Wonderware Training
 Section 4 – The ArchestrA IDE 1-21

The toolboxes included with the ArchestrA IDE hold libraries of reusable objects and graphics:
 Template Toolbox – Contains all automation object templates in your Galaxy organized
by folders called Template Toolsets.
 Graphic Toolbox – Contains all ArchestrA Symbols and Client Controls organized by
folders called Graphic Toolsets. Graphics created within an automation object are not
displayed in this toolbox.
The application views included with the ArchestrA IDE are used to display and configure
relationships between objects:
 Model – Relationship between automation object instances as it pertains to the
automation scheme of the application, usually the physical layout of the plant
 Deployment – Relationship between automation object instances as it pertains to the
computers where the objects will be deployed (where the objects will run)
 Derivation – Parent-child relationship between all automation objects in the Galaxy, from
base templates to each individual instance
 IO Devices – Relationship between automation object instances and the Device
Integration objects; it allows automatic assignment of I/O references

y
The other views included with the ArchestrA IDE are:

op
 IO Device Mapping – Displays the I/O references configured through the IO Devices
view; it allows validation and override of the references
 Operations – Displays the results of manually validating the configuration of automation
object templates and instances
C
You can use the * on the keypad to expand the hierarchy of a selected object or toolset in a view or
toolset. For example, if you select the top-level object, such as the Galaxy name in the Model view,
and then press the * on the keypad, the entire hierarchy will be expanded.
ot

You can customize your working area by arranging the way toolboxes and views are displayed on
the ArchestrA IDE. All toolboxes and views can be:
 Docked to any edge of the main window or have it float over the working area
N

 Grouped in a single panel and accessed through tabs at the bottom of the panel
 Closed so it will not show in the working area; closed panels can be reopened through the
View menu
o

 Auto-hidden so it will show as a single tab on an edge of the main window; clicking the tab
will temporarily show the panel
D

Note: The layout of the ArchestrA IDE can be reset to the factory default by using the Reset
Layout option on the View menu.

The customization of the working area is associated with the currently logged-in user and saved as
part of the Galaxy configuration; this allows the user to access the Galaxy from a different
computer using the ArchestrA IDE and retrieve their custom layout for the working area.
The Synchronize Views option on the View menu will use the selected object in the active panel to
automatically select the same object in all the other opened panels.

Application Server 2017 Update 3

1-22 Module 1 – Introduction

The Template Toolbox

The Template Toolbox hosts all automation object templates in the Galaxy organized by folders
called Template Toolsets.

y
op
C
ot

Base and protected derived template objects are displayed with a small orange lock icon to the left
of the object icon. The configuration of these objects is read-only, but you can still create writeable
derived templates and instances from them.
Containment relationships between templates can be configured and displayed within this toolbox.
N

When creating a containment relationship, contained templates are displayed using only their
contained name; for example, when containing a template called $Agitator into a template called
$Mixer, the agitator template is displayed as Agitator instead of $Mixer.Agitator.
o

Template Toolsets
D

Template toolsets are used to organize all templates within the Template Toolbox.
You can create your own template toolsets to organize the templates as you need, including the
creation of sub-toolsets. Template toolsets and the organization of templates within the toolbox is
shared by all users of the Galaxy.
Top-level template toolsets can be hidden or shown as needed, which in turn will hide or show any
sub-toolsets. The configuration is associated with the currently logged-in user and saved as part of
the Galaxy configuration; this allows the user to access the Galaxy from a different computer using
the ArchestrA IDE and retrieve their custom view of the Template Toolbox.

Wonderware Training
 Section 4 – The ArchestrA IDE 1-23

The Graphic Toolbox

The Graphic Toolbox hosts all ArchestrA Symbols and Client Controls (.NET Controls) in the
Galaxy, organized by folders called Graphic Toolsets. The toolbox only displays generic symbols
created with the intent of reuse, such as the ones included in graphic libraries; graphics created
within automation objects are not displayed in this toolbox.

y
op
C
ot
N
o
D

Protected ArchestrA Symbols are displayed with a small orange lock icon to the left of the symbol
icon. This graphics are read-only and cannot be modified; they can be used and configured via
their Wizard Options and Custom Properties.

Graphic Toolsets
Graphic toolsets are used to organize all ArchestrA Symbols and Client Controls within the
Graphic Toolbox.
You can create your own graphic toolsets to organize the symbols and controls as you need,
including the creation of sub-toolsets. Graphic toolsets and the organization of graphics within the
toolbox is shared by all users of the Galaxy.
Top-level graphic toolsets can be hidden or shown as needed, which in turn will hide or show any
sub-toolsets. The configuration is associated with the currently logged-in user and saved as part of
the Galaxy configuration; this allows the user to access the Galaxy from a different computer using
the ArchestrA IDE and retrieve their custom view of the Graphic Toolbox.

Application Server 2017 Update 3

1-24 Module 1 – Introduction

The Model View

The Model view displays the relationship between automation object instances as it pertains to the
automation scheme of the application; usually, this scheme is based on the physical layout of the
plant. Each section and sub-section of the plant is represented by an instance of the $Area object;
these areas then host the rest of the object instances as they are distributed across the plant. This
relationship is called the Plant Model of the Galaxy.
This application view displays all automation object instances in the Galaxy and none of the
templates. There are two ways to view these objects: Tagname or Alias.

y
op
C
ot
N
o

You can switch between these view by using the button on the toolbar. Alternatively, you can
use the option in the context menu when you right-click within the Model view.
D

Since this view is structured by areas, the top-level objects are $Area objects. You contain sub-
areas within other areas up to a maximum of 10 levels per branch; this limitation does not include
other automation objects hosted in an area.
Any non-$Area instance that has not been assigned is located in the Unassigned Area folder.
The Model view also displays the containment relationship between instances; contained objects
display their contained name in brackets.

Wonderware Training
 Section 4 – The ArchestrA IDE 1-25

The Deployment View

The Deployment view displays the relationship between automation object instances as it pertains
to the computers where the objects will run on when they are deployed. Each computer in the
Galaxy is represented by an instance of the $WinPlatform object; these platforms then host the
rest of the object instances in the Galaxy as they are distributed across the different computers.
This relationship is called the Deployment Model of the Galaxy.
This application view displays all automation object instances in the Galaxy and none of the
templates.

y
op
C
ot
N
o
D

Since this view is structured by platforms, the top-level objects are $WinPlatform objects. The
platform objects host engines and the engines host the rest of the objects in the Galaxy, such as
device integration objects, application objects, and visualization applications.
Any non-$WinPlatform instance that has not been hosted is located in the Unassigned Host
folder.
The Deployment view also displays the containment relationship between application object
instances; contained objects display their contained name in brackets.

Application Server 2017 Update 3

1-26 Module 1 – Introduction

The Derivation View

The Derivation view displays the parent-child relationship between all automation objects in the
Galaxy; from the base template to each individual instance. With the exception of base templates,
all objects in the Galaxy are derived from templates.
This application view is the only view that displays object templates and instances together.

y
op
C
ot

The parent-child relationship between objects is represented in a hierarchical view, with the base
N

templates as the top-level objects.

Base templates and protected derived templates display a small orange lock icon to the left of the
object icon. The configuration of these objects is read-only, but you can still create writeable
o

derived templates and instances from them.

Any base template that has not been derived is located in the Unused Base Templates folder.
D

The Derivation view helps identify which objects will be impacted by the propagation of changes.

Wonderware Training
 Section 4 – The ArchestrA IDE 1-27

The IO Devices View

The IO Devices view displays the relationship automation object instances as it pertains to where
their I/O data will be acquired from. Access to the I/O data in the Galaxy is represented by device
integration objects; these objects communicate with controllers through drivers, such as OI
Servers, legacy IO Servers, and OPC Servers. The association in this view allows for automatic
I/O reference configuration of objects for attributes configured for autobinding.
This application view displays all automation object instances in the Galaxy and none of the
templates.

y
op
C
ot
N
o

The relationship with I/O devices is represented in a hierarchical view, with device integration
objects as the top-level objects and all of their configured scan groups displayed as sub-items. All
D

other objects, application and system objects, are assigned directly to the scan groups.
Any non-device integration object that has not been assigned is located in the Unassigned IO
Device folder.
The IO Devices view does not display the containment or hosting relationship between the objects;
contained objects display their hierarchical name in brackets.

Application Server 2017 Update 3

1-28 Module 1 – Introduction

IO Device Mapping View

The IO Device Mapping view displays I/O references for attributes configured with autobinding.
The content of the list is based on which objects or scan groups are selected in the IO Device
view; the objects must be assigned to a scan group for the list to update.

y
op
The IO Device Mapping view allows for validation of the references by reading a single data point
for each one of the references and displaying if the read was a success (value on green
background) or not (no value on red background).
C
The references generated by autobinding can be adjusted by overriding the device integration and
scan group names (Device.ScanGroup override) or the object and attribute names
(Object.Attribute override), or both.
ot

The Operations View

N

The Operations view displays the results of manually validating the configuration of automation
object templates and instances. This view is not opened by default; it will automatically appear
when manually validating an object or it can be accessed through the View menu.
o
D

The list displays all validated objects along with the status of the validation: Good, Warning, or
Error. Details about the specific warnings and errors can be found in the properties of the object.

Wonderware Training
 Section 5 – Automation Objects 1-29

Section 5 – Automation Objects

This section describes automation objects, templates, and instances. It discusses the Object
Editor, explains the different states of automation objects and operations when editing objects,
and gives a brief explanation of Object Wizards.

Automation Objects
Automation objects, along with the relationship between each other, are the centerpiece of the
object-oriented framework of Application Server. Through automation objects, you can model
virtually anything related to the Galaxy, from an area or section of the plant, to every equipment in
the field, to the actual computers running your application.

y
op
C
ot
N
o

For this, Application Server provides objects in three different categories:

 System Objects – Used to build the infrastructure of the application. They represent the
D

computers that are part of the Galaxy, the runtime engines that execute the rest of the
objects (including how fast the objects will run), and the layout of the plant and distribution
of alarms. System objects also include the visualization applications to run in InTouch.
 Device Integration Objects – Represent the controllers and other I/O data sources
outside the Galaxy, such as PLCs, RTUs, and DCSs. Device integration objects are the
means by which the Galaxy gets access to I/O data from the field; they connect to the
drivers that access the different controllers in your application, such as OI Servers, legacy
IO Servers, and OPC Servers.
 Application Objects – Simply put: everything else. Application objects usually represent
the equipment in the plant floor, such as valves, tanks, and motors; however, they can also
be used to run specific runtime calculations and connections to external data sources
(other than field devices), like databases or web services.
A brand new Galaxy includes a series of objects that can be customized and enhanced to fit the
needs of virtually any application. Other software products might include specialized automation
objects for use in the Galaxy; usually these in the form of application objects. You can also build

Application Server 2017 Update 3

1-30 Module 1 – Introduction

new application objects from scratch using ArchestrA Object Toolkit; though knowledge of C# and
Visual Studio is required to use the toolkit.
The main benefit of an object-oriented approach to configuring the Galaxy is that it allows for the
encapsulation of all configuration elements of each element of your system in an automation
object. This self-contained approach reduces the engineering time associated with the
development and maintenance of the application.

y
op
C
ot

All automation objects include the following features and configuration options:
Inputs and Outputs – References to real-time I/O data from the field or other objects in
N


the Galaxy. For example, read the status of a valve and command it to open or close.
 Scripting – To implement custom calculations, decision-making based on equipment
data, or to enhanced the functionality of objects in the Galaxy. For example, calculating
o

flow rates or defining complex alarm conditions.

 Historical Configuration – Specify which data points in the object will be historized by the
D

Historian Server. It also includes configuration parameters, such as range and deadbands.
 Security Requirements – Permissions necessary to write values to the object. For
example, command a valve to open or change the setpoint for the speed of a motor.
 Alarms and Events Configuration – Specify which alarms and events are to be triggered
(or captured if triggered by the controller); automation objects include traditional alarm
definitions built-in. For example, a HI and a LO alarm for the level of a tank.
 Version and Documentation – Each object keeps track of its own configuration version
and includes its own help file.
 Graphic Symbols – Graphical representations of the object to be used in the operator's
interface displayed by InTouch. Graphics can be animated to display real-time changes to
values of the object; for example, a graphic for a motor object can turn green when the
motor is running and gray when it is not.

Wonderware Training
 Section 5 – Automation Objects 1-31

To configure automation objects:

 Each object includes its own editor for the ArchestrA IDE, which presents a point-and-click
interface to configure all aspects of the object
 All configuration options and parameters within an object are called attributes
 Objects have certain number of built-in attributes and can be enhanced by adding your
own custom attributes
 Objects have built-in behaviors or features (things that the object can do) and can be
enhanced by creating custom behavior through scripting
Automation objects are provided in the form of templates and instances. Templates allow the
configuration of reusable standards while instances implement the standards for each individual
equipment. For example, all common configuration for the valves in the application can be
modeled in a $Valve template and then instances for the actual CV101, CV102, and CV103 valves
can be created out of the $Valve template.

y
op
C
Types of Automation Objects
ot

There are three categories of automation objects in a Galaxy: Application objects, Device
Integration objects, and System objects. Each one of these categories include several types of
N

automation objects, each serving a distinct function within the Galaxy.

A new Galaxy groups the out-of-the-box objects in template toolsets named after each category;
this is not mandatory and moving an object from one toolset to another does not change the
underlined category the object belongs to. For example, moving the $Area object from the System
o

toolset to the Device Integration toolset does not make the $Area object a device integration
object.
D

Application Objects
While System objects provide the infrastructure to distribute and run your application, and Device
Integration objects give you the means to access real-time I/O from field devices, it is the
Application Objects that allow you to model the equipment in the field. For example, valves,
motors, conveyors, and level and temperature transmitters are all modeled through Application
Objects.

Application Server 2017 Update 3

1-32 Module 1 – Introduction

At present, Application Server provides several application objects out-of-the-box:

 Analog Device Object ($AnalogDevice) – This object provides two configuration modes.
As a basic analog I/O, it is used to model devices, such as a level meter or a temperature
transmitter. As an analog regulator, it can represent a PID loop running elsewhere
(typically in a PLC). The object provides typical analog alarm and historization capabilities.
The built-in I/O capabilities of the object cannot take advantage of I/O autobinding, but the
functionality of the object is fairly simple to duplicate using Attributes in any other object,
such as the User Defined object.
 Discrete Device Object ($Discrete Device) – This object can be used to monitor and
control devices that have up to five discrete states. From a simple on/off pump, to an
open/transitioning/close valve, to a stop/running forward/running in reverse motor. The
object provides historization and alarm capabilities that are tailored to multi-state devices.
The built-in I/O capabilities of the object cannot take advantage of I/O autobinding; the
alarm capabilities will require scripting to duplicate in another object.
 Sequencer Object ($Sequencer) – This object allows you to run a series of steps defined
by user-configurable conditions. It is useful to model basic supervisory or manufacturing
procedures with a finite number of steps.

y
 SQL Data Object ($SQLData) – This object provides access to SQL Server databases by
means of mapping data in a table to attributes in objects in the Galaxy. It provides

op
commands for all basic database transactions such as select, insert, update and delete
records.
 User-Defined Object ($UserDefined) – This object is an "empty" object and a "blank
canvas" in the sense that it does not provide any extra functionality besides the common
C
features shared by all object in the Galaxy. It can be used to model virtually any kind of
equipment, from the most basic (like a tank with a level meter or a valve) to very complex
devices (like a reactor system with multiple components).
ot

Other application objects are available as part of other software products; these objects provide
extended functionality to the Galaxy. For example, MES includes up to three application objects
that can be added to the Galaxy: the operations, utilization, and sample recording objects. You can
also build new application objects from scratch using ArchestrA Object Toolkit; though knowledge
N

of C# and Visual Studio is required to use the toolkit.

Device Integration Objects

o

Device Integration objects (or simply DI objects) represent your controllers, such as PLCs, RTUs,
or similar devices. They do not communicate directly to the controllers, but with a driver that
D

speaks the actual controller protocol, like Modbus TCP or DH+.

Application Server provides out-of-the-box communication with other applications through the
DDE, SuiteLink, or OPC protocols. These applications can be OI Servers, legacy IO Servers, OPC
Servers, or any other applications that is a DDE, SuiteLink, or OPC server.

Wonderware Training
 Section 5 – Automation Objects 1-33

At present, Application Server provides the following device integration objects:

 DDE and SuiteLink Client Object ($DDESuiteLinkClient) – This object can be
configured to be a DDE or a SuiteLink client (a Wonderware proprietary communication
protocol). It provides access to OI Servers, legacy IO Servers and other DDE/SuiteLink
server applications. A single instance of this object can provide access to multiple
controllers connected to same driver.
 OPC Client Object ($OPCClient) – This object provides communication to OI Servers
and third-party OPC Servers through the OPC Data Access (OPC DA) protocol; support
for the OPC Unified Architecture (OPC UA) protocol can be added to the Galaxy as a
service to the ArchestrA Service Bus. A single instance of this object can provide access
to multiple controllers.
 Redundant Device Integration Object ($RedundantDIObject) – This object allows the
configuration of redundant communication channels from your Galaxy to the controllers. It
will monitor both communication channels and automatically switch to the standby
channel whenever the active channel is not available. Each channel is represented by a
"regular" DI Object; the Redundant DI Object does not communicate directly with the field,
but with your other DI Objects in your Galaxy.

y
 InTouch Proxy Object ($InTouchProxy) – An object useful in "hybrid" installations,
where System Platform coexist with legacy, tag-based InTouch applications. It provides a

op
way of integrating legacy InTouch applications to your Galaxy; it sits on top of your tag-
based InTouch applications and allows your Galaxy to read (and if necessary, write) data
from InTouch. It helps you consolidate all your data within the Galaxy, without having to
immediately convert your existing InTouch applications. For example, you can implement
C
new production lines in System Platform and integrate data from existing production lines
that are implemented with legacy, tag-based InTouch applications.
ot

System Objects
System objects constitute the infrastructure objects of the Galaxy. These objects provide the pillars
or foundation of your application, and define two very important concepts in your project Galaxy:
N

The Plant Model (the logical organization of the objects and distribution of alarms) and the
Deployment Model (in which computers the objects will run on).
o
D

At present, Application Server provides the following System objects:

 Area Object ($Area) – One of the simplest objects, which has a two-fold job: on one side,
it represents the logical scheme of the application, usually the physical layout of the plant,
allowing you to organize the rest of your objects; and on the other side, it represents how
alarms are distributed in the Galaxy. For example, if the production area has two
production lines (also modeled by the Area object), the operator for Line 1 will only want to
see alarms for that area, while the Production Supervisor might want to see alarms for
both lines. This object is the basis of the Plant Model.
 Windows Platform Object ($WinPlatform) – Or "platform", as it is commonly referred to.
This object represents each computer that is part of the Galaxy. Each application object

Application Server 2017 Update 3

1-34 Module 1 – Introduction

server, operator station, engineering node (among others), are all represented by this
object. It gathers and calculates information about the computer node itself; from RAM
and disk space available to CPU load and page faults. This object is the basis of the
Deployment Model.
 Application Engine Object ($AppEngine) – This object is the runtime engine for the
application; it is in charge of running areas, device integration objects, and application
objects in the Galaxy. One of the most important settings in this object is the scan period,
which indicates how fast you want your application to run; it can run scans as fast as 10ms
and as slow as 1 hour, hardware permitting, of course. Multiple Application Engines can
be hosted on the same computer or across multiple computers running different objects at
different speeds, or both.
 View Application Object ($ViewApp) – This object holds the operator's graphical
interface (HMI). This is one of two visualization applications, which include the windows
and ArchestrA graphics that comprise your operator interface. The application will
effectively run in InTouch Operations Management Interface, but it is managed and
deployed by the Galaxy; it is integrated with the rest of the Galaxy configuration, including
security.

y
 View Engine Object ($ViewEngine) – Another engine object, but much more simple than
the Application Engine; its only purpose is to allow the distribution of visualization

op
applications (InTouchViewApp objects) to the operator stations.
 InTouch View Application Object ($InTouchViewApp) – This object can also hold the
operator's graphical interface (HMI). This is one of two visualization applications, which
include the windows and ArchestrA graphics that comprise your operator interface. The
C
application will effectively run in InTouch, but it is managed and deployed by the Galaxy; it
is integrated with the rest of the Galaxy configuration, including security.
ot

Templates and Instances

Automation objects are classified into templates and instances. Templates allow the configuration
of reusable standards, while instances implement the standards.
N

 Instances are created out of template objects. Instances inherit the entire configuration
from the parent template, but allows for extended configuration on its own. For example, if
there was no configuration to historize certain data point in the template, that configuration
can be added to the instance.
o

 Templates are also created out of other templates. As instances, they inherit the
configuration from the parent template and can be extended. The top-most level template
D

is called a base template; all other templates are called derived templates.
 Configuration changes to templates are propagated to its derived children objects, both,
derived templates and instances.
 Creating your own templates lets you enforce standards and create a library of reusable
objects.
 Instance objects are deployed to the runtime environment and are run by the system;
template objects are configuration-only and cannot be deployed.

Wonderware Training
 Section 5 – Automation Objects 1-35

The following is a comparison between the characteristics of all three classifications of automation
objects.

Base Templates Derived Templates Instances

Created with the ArchestrA Created from another template within the ArchestrA IDE
Object Toolkit
Contain the base attributes Inherits the attributes, functionality, and configuration from the parent
and functionality of the object template
Read-only configuration Writeable configuration
Development environment Development and runtime
environments

 Base templates are created with the ArchestrA Object Toolkit while derived templates and
instances are created within the ArchestrA IDE.
 The first level of derived objects is created from base templates; other derived
templates and instances can be created out of other derived templates.
 Multiple levels of derivation are allowed.

y
 The ArchestrA Object Toolkit (Visual Studio and C# knowledge required) is available
for you to create your own base templates if needed (only application objects can be

op
created with the toolkit; device integration and system objects cannot be created with
the toolkit).
 Base Templates contain predefined, built-in attributes and functionality; these cannot be
removed/deleted. Derived templates and instances inherit all attributes, scripts, and
C
configuration settings from the parent template; attribute and configuration values might
be modified, but not removed/deleted.
ot
N
o
D

Application Server 2017 Update 3

1-36 Module 1 – Introduction

 Base Templates are read-only and cannot be changed. Derived templates and instances
can be enhanced by adding custom attributes, features, and scripts; inherited
configuration might be writeable.
 Your derived templates can be made read-only for distribution, if needed by way of
protecting the objects (useful to establish corporate-wide standards, OEM, and
System Integrators libraries).
 Templates, base and derived, only exist in the development environment (configuration
project database) and cannot be deployed to runtime. Instances exist on both
environments, development and runtime, and are designed to be deployed and run.

Important: Always create derived templates from base templates and never create instances
directly from a base template. Base templates are read-only; therefore, they cannot be customized
to propagate changes to their children.

y
op
C
ot
N

When deriving objects, note that:

 Every derivation hierarchy starts with a base template
o

 All derived templates and instances are said to be of the same type as the base template
from which they are created; for example, in the illustration above, the $Valve, $Inlet, and
$Outlet templates, as well as all the CV instances are classified as User-Defined objects
D

 There is no limit on the number of levels of derivation

 The parent-child relationship between objects in the derivation hierarchy cannot be broken
or rearranged

Wonderware Training
 Section 5 – Automation Objects 1-37

Working with Objects

Configuration and runtime access to automation objects is done through attributes. Attributes
represent all configuration options and parameters, as well as any runtime calculations or data
changes within the object. For example, when configuring a tank object, the range and
engineering units of the level are represented by different attributes you configure in the object;
when the object is deployed, the actual value of the level, as well as the average calculation of the
level are represented by different attributes.
Some attributes are configuration-only (existing only in the development environment), runtime-
only (existing only in the runtime environment), or both. Attributes that exist in both environments
might be writeable during configuration and read-only in runtime. The documentation of the object
includes the detail information about each attribute.
Automation objects include their own editor, referred to as the Object Editor. With this editor, you
can configure all options and parameters. Any changes made to an object's template are inherited
by all objects created from it. When you open the Object Editor in non-read-only mode, the object
is checked out. No one else can edit an object while you are working with it. If someone else is
already working on the object, you can open it to view, but you cannot make changes.

y
op
C
ot
N

The configuration editor of automation objects group attributes in tabs based on functionality.
There are three tabs that are common to all objects:
o

 Attributes – Allows you to enhance an automation object by adding your own custom
attributes. Custom attributes can be extended by adding features such as: I/O references,
D

historization capabilities, and alarm configuration.

 Scripts – Allows you to enhance an automation object by adding custom functionality
through scripting. The scripting engine leverages the Microsoft .NET Framework for
advanced capabilities.
 Object Information – Includes information about the object, such as a description and the
name of the parent template. This tab also allows you to modify the help file of the object.

Application Server 2017 Update 3

1-38 Module 1 – Introduction

Other configuration tabs might be available in the editor depending on the object. For example, the
$Area object includes a tab named 'General' with several area-specific configuration attributes.

y
op
C
ot
N
o
D

Wonderware Training
 Section 5 – Automation Objects 1-39

Object States
The state of an automation object is displayed as overlay icons to the object icon in the Template
Toolbox and application views within the ArchestrA IDE. There are deployment-related and
configuration-related status indicators; both can be present on an object at the same time.
The following are deployment status indicators for object instances; these overlay icons appear in
the top-left corner of the object's icon:

Overlay Icon Example Description

Object is not deployed.

[No Icon] Object is deployed and no configuration changes are pending. This is the
normal scenario for a deployed object.
Object is deployed, but there are configuration changes that have not been
deployed. In this state, the configuration version of the object is different from
the runtime version of the object.
Object is deployed, but there are software updates that have not been

y
deployed. In this state, the software version in the development environment is
different from the runtime version. This occurs when a new version of base

op
templates has been imported to the Galaxy.

The following are configuration status indicators for object templates and instances; these overlay icons
appear on the bottom-right corner of the object's icon:
C
Overlay Icon Example Description
[No Icon] Normal state of an object. There are no configuration warnings or errors.
ot

There is an issue with the configuration of the object. The object can still be
deployed, but results might not be as expected.
There is an issue with the configuration of the object. The issue is too severe
N

and the object cannot be deployed.

Configuration warning and error messages are displayed in the properties of the object. Before
chasing for configuration attributes in the object editor, it is best to check the properties of the
o

object first, to narrow your options.

D

Editing Objects
Application Server supports multi-user configuration management by implementing a check-out/
check-in system:
 When a user opens an automation object for configuration, the object is checked out from
the configuration project database
 While an object is checked out, no other user can open the object for configuration; other
users can still be open the object in read-only mode
 A red check mark is displayed to the right of the object's icon to indicate that the object has
been checked out by the logged-in user; a black check mark indicates that the object is
checked out by a different user than the logged-in user
 An object needs to be checked in for the configuration to be available for deployment
 Checked out objects can be saved without checking in the object

Application Server 2017 Update 3

1-40 Module 1 – Introduction

 Checked out objects can be undone to revert the last checked in state; only the user that
checked out the object can perform an 'undo check out' on the object
 Override check-out can be performed by other users with the right security permissions to
revert back to the last checked in state
When checking in objects, by default, the ArchestrA IDE asks for a comment; this comment is
recorded in the configuration log of the object and can be accessed through the properties of the
object. If a comment is not provided, the default "Check in by user" comment is entered in the log.
When deleting automation objects:
 Templates with derived objects cannot be deleted
 Instances that are deployed cannot be deleted
 Deleted base templates are available to re-import form the Application Server installation
folder

Object Wizards

y
An Object Wizard can be added to any derived template. It provides a simplified user interface for
configuring instances (assets) from the template. A single template with an Object Wizard can

op
replace a number of derived templates to configure a variety of similar instances. You can add an
Object Wizard to any derived template.
Depending on your level of permissions, you can:
Create and configure instances from within the ArchestrA IDE and add them to the Galaxy,

C
or modify existing instances. You open an instance and answer a series of prompts or
questions.
 Use the Configure New Asset editor to create and configure instances and a
ot

representative symbol by dragging an associated symbol into a graphic, and then

answering a series of prompts or questions.
Object Wizards consist of a series of user-selectable choices and options that are used to
N

customize a deployable instance. Each choice and option may have one or more attributes,
symbols, and scripts associated with it.
Using an Object Wizard allows you to reduce both the depth of the template hierarchy and the
o

number of templates that are needed to configure instances. Adding an Object Wizard to a
template can eliminate the need for many templates, while providing coverage for the same variety
D

of possible configurations of instances.

With an Object Wizard, you can configure instances that contain only the elements needed at
runtime. When an Object Wizard is not used, instances derived from the template may contain a
number of additional attributes, symbols, and scripts that are not used. Object Wizards can be
configured to trim unneeded elements from its derived instances.
Object Wizards can simplify the process of configuring instances. Using an Object Wizard to
configure instances reduces the amount of product knowledge and training that is required.

Wonderware Training
 Lab 2 – Creating Global Derived Templates 1-41

Lab 2 – Creating Global Derived Templates

Introduction
In this lab, you will create derived templates from base templates using the System Platform IDE.
These derived templates will be used in the course to develop the mixing application used
throughout this course. You will organize the templates into template toolsets, and then hide the
template toolsets that contain the base templates to ensure that instances are not created from
base templates.

Objectives
Upon completion of this lab, you will be able to:
 Create a new template toolset to organize templates
 Create a derived template
 Hide a template toolset

y
op
C
ot
N
o
D

Application Server 2017 Update 3

1-42 Module 1 – Introduction

Create the Template Toolsets

First, you will create template toolsets to help organize the templates you will use in your
application.
1. In the Template Toolbox, right-click TrainingGalaxy and select New Template Toolset.

y
op
2. Rename the new toolset Training.
C
ot

 
N

Note: The Rename feature is activated by default when a new toolset is created. It can also
o

be found by right-clicking the toolset or object.

D

Wonderware Training
 Lab 2 – Creating Global Derived Templates 1-43

You will now create additional toolsets within the new Training template toolset.
3. Right-click the Training toolset and select New Template Toolset.

4. Rename the new toolset Global.

y
op
C
5. Repeat Steps 3 and 4 to create a new toolset named Project.
ot
N
o
D

Application Server 2017 Update 3

1-44 Module 1 – Introduction

Create the Derived Templates

For the remainder of this lab, you will create derived templates and organize them in the template
toolsets that you created.

6. Expand the Device Integration toolset by clicking the plus icon to the left of the template
toolset.
7. Right-click $DDESuiteLinkClient and select New | Derived Template.

y
op
C
8. Rename the new derived template $gDDESuiteLinkClient.
ot

Note: The $ is added by default to the name of any template.

N
o
D

Wonderware Training
 Lab 2 – Creating Global Derived Templates 1-45

9. Create three more derived templates from the following base templates:
Base Template Derived Template
$InTouchProxy $gInTouchProxy
$OPCClient $gOPCClient
$RedundantDIObject $gRedundantDIObject

The Template Toolbox now displays all four new derived templates in the Device Integration
template toolset.

y
op
C
10. Select and drag the four new derived templates into the Training\Global toolset.

Note: You can select multiple items by pressing the CTRL key and clicking each desired
ot

object, and then dragging the group of objects together.

N
o
D

Application Server 2017 Update 3

1-46 Module 1 – Introduction

11. Expand the System template toolset.

12. Create four new derived templates from the following base templates:

y
Base Template Derived Template

op
$AppEngine $gAppEngine
$Area $gArea
$ViewEngine $gViewEngine
$WinPlatform $gWinPlatform
C
The Template Toolbox now displays the four new derived templates in the System template
toolset.
ot
N
o
D

Note: You will not create a derived template from $InTouchViewApp or $ViewApp because
they are special objects that do not accept second-level derivation, but you will drag them
together with the other new objects.

Wonderware Training
 Lab 2 – Creating Global Derived Templates 1-47

13. Select and drag the four new derived templates, as well as the $InTouchViewApp and
$ViewApp objects to the Global toolset.

y
op
To ensure that instances are not created from base templates, you will hide the Device
Integration and System template toolsets. Going forward, you will only use the Application and
Training template toolsets.
C
14. Right-click the Device Integration template toolset and select Hide.
ot
N
o
D

15. Hide the System template toolset.

Application Server 2017 Update 3

1-48 Module 1 – Introduction

If you need to view the hidden template toolsets again, perform the following steps to unhide them.
16. On the Galaxy menu, select Configure | Customize Toolsets.

y
op
C
The Customize Toolsets dialog box appears.
ot

17. From the Toolset list, check the toolsets you wish to see in your ArchestrA IDE and click
Close.
N
o
D

Note: This will allow you to unhide toolsets you have hidden and wish to see again.

Wonderware Training
 Section 6 – System Requirements and Licensing 1-49

Section 6 – System Requirements and Licensing

This section describes the System Platform computer roles, the software and hardware
requirements for Application Server, the ArchestrA Network Account, and how the product is
secured and licensed.

System Platform Computer Roles

A complete implementation of System Platform and its Clients involves many computer roles
based on the software installed and tasks performed on each computer.
The following diagram is an example of a distributed System Platform implementation, where each
computer has been designated a single role. Keep in mind that most of these roles can be
combined on a single computer, depending on the size of the application and the hardware
resources available.

y
op
C
ot
N

The possible computer roles on a System Platform implementation are:

 Galaxy Repository – Runs the Galaxy Repository service and hosts the configuration
o

project database. There is only one Galaxy Repository per Galaxy.

Engineering Station – Runs the tools necessary to develop and configure the
D


application, such as the ArchestrA IDE and the InTouch development tools. There can be
multiple engineering stations for multi-user development teams.
 Application Object Server – Computer where application objects are deployed to run on.
There can be multiple application object servers for load distribution or redundancy, or
both.
 Device Integration Server – Computer connected to the control network and running the
corresponding drivers, such as a OI Sever or legacy IO Server. A single device integration
server can run multiple drivers, but there can also be multiple device integration servers,
depending on the control network topology.
 Visualization Station – Runs the operator's interface or HMI through InTouch runtime
tools. There can be multiple visualization stations.

Application Server 2017 Update 3

1-50 Module 1 – Introduction

 Historian Server – Runs the Historian Server software and hosts the history and alarm
databases. Typically, there is only one historian server per Galaxy, but there can be more
than one if needed, such as in largely distributed Galaxies hosting local historian servers
per location.
 Information Server – Runs the Information Server software and host the reporting
industrial information web portal. Typically, there is only one information server per Galaxy,
but more than one can be implemented if desired.
 License Server – Required if implementing Information Server or Historian Client
concurrent license, or both.
 Workstation – Computer on the business network that can access reports in Information
Server through a web browser.
Based on these computer roles, the following diagram illustrates the Application Server
components that need to be installed and deployed on each computer.

y
op
C
ot
N

The WinPlatform objects are required on those computers to either host other automation objects
in the Galaxy (Application Object Servers, Visualization Stations) or for real-time communication to
o

those objects (Galaxy Repository, Engineering Stations, Visualization Stations, Information

Server), or both.
D

Wonderware Training
 Section 6 – System Requirements and Licensing 1-51

Software and Hardware Requirements

The following topics describe software and hardware requirements for System Platform.

Note: Please refer to the readme file that came with your software for more details about
hardware and software requirements, compatibility information, key product notes, and additional
resources.

Software Requirements
The following table lists supported and preferred software requirements for various nodes in your
system:
Development Galaxy Automation Supervisory
(ArchestrA IDE) Repository Object Server Client
Windows Server Preferred Preferred Preferred Supported
Windows Workstation Supported Supported Supported Preferred

y
SQL Server --- Required --- ---
.NET Framework Required Required Required Required

op
Minimum Hardware Requirements
The following table lists minimum hardware requirements for server nodes, such as Historian, the
C
GR node, AppEngine host (Application Objects Server), and the ArchestrA IDE (development
environment):
ot

CPU RAM Storage Display Network

(Cores) (GB) (GB) (Resolution) (Mbps)
Small 2 2 100 1024 x 768 100
1-25K I/O per node
N

Medium 4 8 200 1024 x 768 1000

25K-50K I/O per node
Large 8 16 500 1024 x 768 1000
> 50K I/O per node
o

You can use all products on a single node. An All-in-One node includes Application Server,
D

InTouch, Historian, Historian Client, and Licensing components. The following table lists the
minimum hardware requirements for an All-in-One node:

CPU RAM Storage Display Network

(Cores) (GB) (GB) (Resolution) (Mbps)
4 8 200 1280 x 1024 100

Application Server 2017 Update 3

1-52 Module 1 – Introduction

Licensing
The following topics provide general information about System Platform licensing.

Note: Consult your sales representative for details about licensing and pricing.

System Platform
System Platform licenses are available in different sizes. Each option may include licenses for a
number of Galaxies, I/O points, Historian tags, Device Integration Servers, and supervisory clients.
Each System Platform license also includes:
 One Insight license.
 Remote Response Objects, which are not available out-of-the-box. They must be
downloaded from the Support site.
 Available upon request, one Recipe Manager Plus Standard Edition license with two client
connections. Please contact your sales representative for more information.

y
System Platform licenses with 25K I/O points or less do not include a Microsoft SQL Server

op
Standard license.
System Platform licenses are provided for the runtime environment. For development purposes, a
Development Studio license is required. Otherwise, tools such as the ArchestrA IDE will not
launch. Development Studio licenses are offered only with the subscription model.
C
Supervisory Client
A Supervisory Client license enables the use of both Operations Management Interface for
ot

System Platform and InTouch for System Platform.

A Supervisory Client license can be used for thick clients (desktop), thin clients (remote access,
such as Remote Desktop Server), or a web client through InTouch Access Anywhere (which uses
N

Remote Desktop Server).

Activated Licensing
o

System Platform is license-enforced using an activated licensing framework with an activation

D

code. Management and activation of licenses are performed with the following components, which
are installed as part of the installation of your purchased products:
 License Server: Acquires, stores, maintains, and serves licenses. It supports redundancy
and failover.
 License Manager: Web-based user interface for accessing and maintaining licenses.
For more information about licensing components, refer to your product documentation.

Wonderware Training
 Section 6 – System Requirements and Licensing 1-53

ArchestrA Network Account

An important requirement when implementing System Platform is the correct setup of the
ArchestrA Network Account. This account, created for the IDE, enables communication between
all computers in the system that have Wonderware software installed. Some of the things that rely
on this account are:
 Deployment of objects from the Galaxy Repository
 Real-time communication between platforms
 Historization of data from the Galaxy
The ArchestrA Network Account is a Windows account (local or Active Directory) that needs to be
setup on all computers running Wonderware software and must comply with all of the following:
 The same account must be used on all computers. If on a workgroups environment, the
same account and password must be created on each computer.
 Member of the local Administrators group on all computers. If on an Active Directory
environment, the account does not need to be a domain administrator, but a local
administrator of each computer.

y
 Password must not expire or change. If the password expires or is changed, all
communications between Wonderware software will cease.

op
The ArchestrA Network Account does not need to be an interactive user.
The first Wonderware software that is installed on a computer will prompt you to setup the
ArchestrA Network Account; at that point, you can use or create a local user or specify an Active
C
Directory user. All subsequent Wonderware software installed on that same computer will
automatically use that same account.
If the password of the ArchestrA Network account is ever changed, all communication between
Wonderware software will stop and you will need to run the Change Network Account utility
ot

(automatically installed with any Wonderware software) on each computer to update the account
information on that node. This will require a restart of the computer.
N
o
D

Note: The ArchestrA Network account cannot be used to log into a computer.

Application Server 2017 Update 3

1-54 Module 1 – Introduction

Encrypted Communication
The end-to-end communication between software applications (server and client) can be
encrypted and secured to prevent eavesdropping and malicious tampering (aka: Man-in-the-
Middle) attacks.
To enable encrypted network communication, one of the nodes in the network must be configured
to host and run the System Management Server (SMS). The role of the System Management
Server is to generate, manage, and distribute secure digital certificates used for establishing and
maintaining secure communications.
All other nodes need to be configured to connect to the SMS so they all become part of the same
community.
The SMS does not need to be available at runtime for secure communications to be established.
In fact, once joined to the SMS, a node will not need access to the SMS until it is time to renew the
certificates.

Protocols that Benefit From Encrypted Communication

y
With encrypted communication, all of the following protocols are secured:

op
 SuiteLink
 Message Exchange (MX)
 iData
iBrowse

C
 HCAL
ot
N
o
D

Wonderware Training
 Section 6 – System Requirements and Licensing 1-55

Software that Supports Secured Communication

The following software supports secured communication:
 Application Server 2017 Update 3 and later
 InTouch Operations Management Interface 2017 Update 3 and later
 InTouch for System Platform 2017 Update 3 and later
 *OI Server
 InTouch Web Client in 2017 Update 3 and later
 Historian 2017 Update 3 and later
 Sentinel System Monitor 1.1 for System Platform 2017 Update 3 and later
*Communications from the specific OI Server to any other products listed above can be encrypted.
This is generic and applies to all OI Server versions.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

1-56 Module 1 – Introduction

Node-to-Node Communication
Node-to-node communication is unsecured under certain scenarios, including the following:
 The version of the software installed on one or more nodes is earlier than 2017 Update 3
(Communication Driver version has no impact)
 One node points to a System Management Server, but there is no System Management
Server configured on the other node
 There is no System Management Server configured for both nodes
Please note that if one node points to one System Management Server and the other node points
to another System Management Server, there will be NO network connection between the nodes.

y
op
C
ot
N
o
D

Wonderware Training
 Section 6 – System Requirements and Licensing 1-57

Sentinel System Monitoring

Sentinel System Monitor is a software application that continuously monitors your Wonderware
applications and system hardware, identifies upset conditions, and alerts you to potential issues
before they manifest into real problems like software application errors or machine downtime
events.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

1-58 Module 1 – Introduction

Sentinel System Monitor constantly monitors the following attributes, messages, and metrics:
 System Platform (Platform & Engine): Runtime attributes like Scan Status, Redundancy/
Failover, ArchestrA Event Log Error/Warnings, logged Script issues
 DI Objects: Connections/Scan Status, DAServer Status, ArchestrA Event Log Errors/
Warnings
 Historian: Historian Services Status, Database Health, ArchestrA Event Log Errors/
Warnings
 ArchestrA: ArchestrA Services Status, ArchestrA Event Log Errors/Warnings
 MES: MES Services Status, MES Database Performance, ArchestrA Event Log Errors/
Warnings
 SQL Server: Internal Performance & Health per Microsoft SQL Server Management Pack
 Hardware/Operating System: CPU, Memory, Event Logs, Performance Counters
 Other Supporting Software: Terminal Services, 3rd-party IO Servers, and others

y
op
C
ot
N
o
D

Wonderware Training
 y
op
Module 2 – Application Planning
C
Section 1 – Application Server Project Workflow 2-3
ot

Section 2 – Case Study 2-5

N
o
D
2-2 Module 2 – Application Planning

Module Objectives
 Describe the suggested project workflow
 Discuss the simulated manufacturing environment and naming convention to be used for
the training session

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Application Server Project Workflow 2-3

Section 1 – Application Server Project Workflow

This section describes the suggested project workflow.

Introduction
The object-oriented framework of Application Server makes it easy to develop and maintain a
Galaxy by encapsulating all-related functionality in individual objects and combining all common
configuration in templates that can be easily spawned into multiple instances. A Galaxy can be
made out of hundreds and even thousands of objects, so careful planning is recommended before
creating these objects to avoid backtracking and redesigning objects down the road.
The following is a suggested project development workflow to get you started on creating your first
Galaxy.

y
op
C
ot
N
o
D

The first three steps are the most important, since the objects derivation hierarchy will rely on this
(and cannot be fixed later on without recreating it); the other three items (plant model, security
model, and deployment model) can be updated later if needed. Here is an explanation of each
step:
 Identify field devices and functional requirements - You should start by collecting
information about all the field equipment and devices that will be part of your application.
These devices will be modeled as objects in your Galaxy, so you should gather all their
functional requirements, such as vessel capacities, engineering units, motor states, and
alarms needed, to name a few. Most of the time you will be able to gather most or all the
information from the pipping and instrumentation diagram (P&ID).
 Defining naming conventions - Before creating any objects, a key piece is defining a
naming convention for your templates, instances, and attributes; this is particularly

Application Server 2017 Update 3

2-4 Module 2 – Application Planning

important when using the automatic binding feature of Application Server to link objects to
I/O data.
 Plan templates - Once field devices, functional requirements, and naming conventions
have been defined, you can start planning your templates. What common functionality can
you combine in a single template? How many levels of derivation will you need to
minimize duplicating configuration? How should you name your attributes? Do not forget
that the parent-child relationship between objects cannot be broken; if you later find that
you need another level of derivation between templates already created, you will need to
delete all children objects and recreate them later; so pay careful attention to this step as it
is important to avoid any possible redesign of the objects.
 Define the plant model - This is the organizational structure of the objects in your Galaxy
and how alarms will be distributed and filtered. The plant model is usually based on how
the equipment is distributed within the factory or plant. The main thing to consider when
defining the plant model is the distribution of alarms; for example, if there are operators
dedicated to each production line, then production lines should be included in the plant
model as individual areas so each operator can filter by the production line it is monitoring.
 Define security model - One of the things to define before going to production is the

y
security model for the runtime environment. Which users can write to attributes on which
objects? (for example, who can open a valve or change a setpoint) Who can acknowledge

op
alarms from which objects? Some of the runtime security configuration might involve
changing the security classification of individual attributes within an object, so part of this
could be done while planning the templates. If working on a multi-user development
environment, the security model for working in the ArchestrA IDE might need to be defined
earlier.
C
 Define the deployment model - Also before going to production, it will be necessary to
define the production deployment model. This involves the definition of all the WinPlatform
objects necessary to deploy the Galaxy to the production environment. A testing
ot

deployment model will be needed while creating and testing the Galaxy.
N
o
D

Wonderware Training
 Section 2 – Case Study 2-5

Section 2 – Case Study

This section describes the simulated manufacturing environment to be used for the course and
explains the naming conventions used in the simulated process.

This section does not contain information specific about Application Server, but a description of the
example that is the basis for the exercises in this training manual, from the fictitious manufacturing
plant, to the equipment that is going to be modeled, to the simulated I/O process that will feed the
Galaxy.

Factory Layout
The factory example for this training course is divided in four main sections or areas: Receiving,
Production, Packaging, and Shipping; with the Production area including two production lines: Line
1 and Line 2.
All these areas will be modeled in the Galaxy using the $Area object and will be the basis for the
plant model.

y
op
C
ot
N
o
D

While all areas of this factory will be simulated in the Galaxy, only some of the equipment in the
Production and Packaging areas and their sub-areas will be modeled.

Note: The simulation provided with this course only simulates some of the equipment in the
Production and Packaging areas.

Application Server 2017 Update 3

2-6 Module 2 – Application Planning

The Mixer System

The mixer system consists of the following devices:
 Three valves:
 Inlet Valve 1 (Inlet1): Used in conjunction with Transfer Pump 1 to add the first
material into the tank
 Inlet Valve 2 (Inlet2): Used in conjunction with Transfer Pump 2 to add the second
material into the tank
 Outlet Valve (Outlet): Drains the tank
 Two transfer pumps:
 Transfer Pump 1 (Pump1): Used in conjunction with Inlet Valve 1 to add the first
material into the tank
 Transfer Pump 2 (Pump 2): Used in conjunction with Inlet Valve 2 to add the second
material into the tank
 One motor:
 Agitator (Agitator): Mixes the materials in the tank; the speed of the motor can be set

y
for this device
Two transmitters:

op


 Level Transmitter (Level): Indicates the current level of the tank

 Temperature Transmitter (Temperature): Indicates the current temperature of the
tank C
ot
N
o
D

Equipment Signal I/O Type Range Eng. Units

Level Transmitter MixerX00.Level.PV I Float RAW: 0 - 4095 Liters
EU: 0 - 250
Temperature MixerX00.Temperature.PV I Float RAW: 0 - 4095 Celsius
Transmitter
EU: 0 - 250
Inlet Valve 1 MixerX00.Inlet1.CLS I Boolean - -
MixerX00.Inlet1.OLS I Boolean - -
MixerX00.Inlet1.CMD O Boolean - -
Inlet Valve 2 MixerX00.Inlet2.CLS I Boolean - -
MixerX00.Inlet2.OLS I Boolean - -
MixerX00.Inlet2.CMD O Boolean - -

Wonderware Training
 Section 2 – Case Study 2-7

Equipment Signal I/O Type Range Eng. Units

Outlet Valve MixerX00.Outlet.CLS I Boolean - -
MixerX00.Outlet.OLS I Boolean - -
MixerX00.Outlet.CMD O Boolean - -
Transfer Pump 1 MixerX00.Pump1.CLS I Boolean - -
MixerX00.Pump1.CMD IO Boolean - -
Transfer Pump 2 MixerX00.Pump2.CLS I Boolean - -
MixerX00.Pump2.CMD IO Boolean - -
Agitator MixerX00.Agitator.PV I Boolean - -
MixerX00.Agitator.CMD IO Boolean - -
MixerX00.Agitator.Speed.PV I Float EU: 0 - 500 Rpm
MixerX00.Agitator.Speed.SP O Float EU: 0 - 500 Rpm

The I/O data source (from the PLC simulator and the OI Server) relies on the above naming

y
convention (Signal column in the table), where X is either 1 or 2 for Mixer100 and Mixer200.
The Level and Temperature transmitters are provided in counts (0 - 4095) and will need to be

op
scaled to the corresponding engineering units (0 - 100 Liters, 0 - 250 Celsius, respectively).
Each valve has three signals:
 A Close Limit Switch (CLS) to indicate if the valve is fully closed

C
An Open Limit Switch (OLS) to indicate if the valve is fully open
 A Command (CMD) to signal the valve to open or close
The pumps have two signals:
ot

 A Process Value (PV) to indicate if the pump is running or stopped

 A Command (CMD) to signal the pump to start or stop the motor
The agitator has four signals:
N

 A Process Value (PV) to indicate if the agitator is running or stopped

 A Command (CMD) to signal the agitator to start or stop the motor
A Speed Process Value (Speed.PV) to indicate how fast the motor is running, when the
o


agitator is on
A Speed Setpoint (Speed.SP) to tell the agitator how fast the motor should run, when it is
D


on

Note: The simulation provided with this training course includes four Mixers named Mixer100,
Mixer200, Mixer300, and Mixer400 with the same names for all of the signals. This course only
uses Mixer100 and Mixer200, but you can use the other two for testing purposes, if needed.

Application Server 2017 Update 3

2-8 Module 2 – Application Planning

Simulated Process
The simulation for this training course runs a continuous process that has four steps or stages:
1. Adds the first ingredient up to 60% of the tank's volume.
2. Adds second ingredient until the tank is full.
3. Mixes the ingredients in the tank for certain amount of time; the time differs from mixer to
mixer.
4. Drains the tank.
After the tank is empty, the simulation automatically starts over.

y
op
During the running of a batch, a complete run of the four steps or stages from beginning to finish,
the following happens:
 The level and temperature of the tank are available, as well as the temperatures.

C
The tank's temperature is in direct proportion with the level of the tank: the higher the
level, the higher the temperature, and vice versa
 The speed of the agitator is 0 when it is off and a value close to the specified setpoint
ot

when running

Note: All analog values have a random coefficient applied to it to ensure that values from different
mixers and from batch to batch are different.
N
o
D

Wonderware Training
 y
op
Module 3 – Application Infrastructure
C
Section 1 – The Plant Model 3-3
ot

Section 2 – The Deployment Model 3-5

Lab 3 – Creating the Plant and Deployment Models 3-11
N

Section 3 – System Management Console 3-27

Section 4 – The Runtime Environment 3-35
o

Lab 4 – Using Object Viewer 3-41

D

Section 5 – Data Simulation 3-53

Lab 5 – Configuring for Data Simulation 3-55
3-2 Module 3 – Application Infrastructure

Module Objectives
 Explain the Plant and Deployment models
 Introduce Object Viewer, Platform Manager, and OI Server Manager tools
 Describe the WinPlatform, AppEngine, DDESuiteLinkClient, and OPCClient objects
 Introduce OI Servers and IO Servers
 Explain attribute referencing and I/O referencing

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – The Plant Model 3-3

Section 1 – The Plant Model

This section describes the importance of the plant model and explains the usage of area objects
and the Model view in the ArchestrA IDE.

The Plant Model

The plant model, or area model, as sometimes referred to, is a hierarchical representation of the
automation scheme of the application. It basically servers two functions: logical organization of all
the objects in the Galaxy; and the distribution of alarms within the system.
The automation scheme is usually based on the physical layout of the plant, where each section
and sub-section is represented by an object in the Galaxy.
While every plant and factory has its own particular layout, in general terms you could classify the
structure as follows:
 Plants and factories are divided in sections

y
 Sections are divided in areas

op
 Areas are divided in production lines
 Production lines are divided in manufacturing cells
C
ot
N

The plant model is also how alarms are distributed in the system; for example, if the production
area has two production lines, the operator for Line 1 will only want to see alarms for that area,
while the Production Supervisor might want to see alarms for both lines. This functionality is
o

inherent in the plant model.

D

Using the ArchestrA IDE, the plant model is built using the application Model view (for more
information see “The Model View” on page 1-24).

Application Server 2017 Update 3

3-4 Module 3 – Application Infrastructure

The plant or factory itself is usually represented by the Galaxy and not an actual object; the rest of
the layout is represented by instances of the $Area object, arranged in a hierarchy that represents
how each area is divided into its sub-areas.

y
op
C
ot

Afterwards, the rest of the objects (equipment, computers, engines, and so on) are organized
based on their physical location by assigning them to their corresponding areas.
N

Note: It is possible that the plant model might not include proper areas to assign non-equipment
objects, such as platforms, engines, and device integration objects. In these cases, you can simply
add an area to hold these objects; for example, a 'ControlSystem' or 'ControlRoom' area.
o

The Area Object

D

The Area object is one of the simplest objects to configure, but its functionality is key to the
implementation of the Galaxy, as it is the basis for the plant model.
The main characteristics of the Area object are:
 Represents an area of the plant or an automation process
 Can only be nested up to 10 levels
 Provides grouping and distribution of alarms
 Supports alarm count and status aggregation
 Used as filters by alarm clients
 On the plant model, the rest of the objects are assigned to it
 On the deployment model, it hosts all application objects

Wonderware Training
 Section 2 – The Deployment Model 3-5

Section 2 – The Deployment Model

This section describes the Deployment view of the ArchestrA IDE, discusses the hosting
relationship between objects, explains the usage of the $WinPlatform and $AppEngine objects,
and describes the Deployment options.

Deployment of Automation Objects

To run your application, the automation object instances in your Galaxy must be deployed to the
runtime environment. When an object is deployed, the underlined software that makes the object
(from the base template) and the object's configuration (I/O references, alarms, history, scripts,
and so on) are copied to the target computer; the software also gets installed or registered in that
computer and the object is run, or both.
In contrast, undeploying objects will stop them, uninstall them, and finally remove them (software
and configuration) form the computer they were deployed to.

y
Note: Only automation object instances can be deployed; templates are configuration-only and
cannot be deployed.

op
Changes made to the configuration of an object are not automatically deployed. When using the
ArchestrA IDE, deployment must be done by a user; until then, the configuration version of the
object is different between the development and the runtime environments. For example, a tank
C
object is deployed without alarms configured for the level value, and then afterwards, a Hi alarm is
added to the level; at this point, the deployed, running version of the object is still lacking any
alarms until the tank object is deployed again.
ot

To deploy changes to an object, usually referred to as redeploy, you just need to deploy the object
again. Depending on the changes, the currently deployed instance might get undeployed, and
then deployed again, or the changes are simply "pushed" to the currently deployed instance. Value
changes to attributes usually are "pushed", while changes that add/remove features (custom
N

attributes, alarms, scripts, and so on) require an undeploy.

In rare occasions, redeployment of the objects might be necessary due to a software upgrade; for
example, a new version of a base template will include a new version of its underlined software, so
o

even if you have not changed the configuration of its instances, redeployment will be necessary to
send the new software to the runtime environment.
D

Deployment occurs from the Galaxy Repository computer to the target runtime computers. If the
Galaxy Repository goes offline after the objects have been deployed, the runtime environment will
still run all objects and all runtime communication will still be in place.
All application views in the ArchestrA IDE will display a graphical representation of the deployment
status of the object in the form of an overlay over the object's icon (for more information see
“Object States” on page 1-39).
To be able to deploy automation objects, you must define the Deployment Model for the Galaxy.

Application Server 2017 Update 3

3-6 Module 3 – Application Infrastructure

The Deployment Model

The Deployment Model is a hierarchical representation of where your objects are going to run (or
are running); in other words, the distribution of all your objects across all the computers that are
part of your Galaxy.
The computers themselves are represented by the WinPlatform object. This is the first (and maybe
only) object that is deployed on computers that are part of the Galaxy. One, and only one
WinPlatform object, can be deployed to a computer; in other words, a computer can belong to one
and only one Galaxy at a given time.
How many computers you will use to host and run your objects will dictate the base of your
deployment model. Afterwards, you distribute the rest of your objects based on a hosting
relationship between all objects.

y
op
C
ot

For a computer to be able to receive a WinPlatform object, the Bootstrap service must be installed
first. The hosting relationship between the objects is as follows:
 The WinPlatform object is at the top of the hierarchy and the first to be deployed; it sets
the ArchestrA infrastructure for the Galaxy and manages all the off-node communications.
N

 WinPlatform objects host AppEngine objects, which are the primary runtime engines in
charge of running the rest of the objects in the Galaxy, as well as handling the
communication between objects hosted in the same engine.
o

 AppEngine objects host Area objects for alarm grouping and filtering.
Area objects host Application objects, which primarily represent the equipment in the
D


plant (valves, motors, tanks, conveyors, and so on).
 AppEngine objects also host Device Integration objects, which allow communication to
the field through drivers such as OI Servers, OPC Servers, and legacy IO Servers.
 AppEngine objects can host several areas and device integration objects.
 WinPlatform objects can host more than one AppEngine object; this allows for running
different objects at different speeds (scan rates).
For visualization purposes, WinPlatform objects also host ViewEngine objects and ViewEngine
objects host InTouchViewApp objects. An instance of the InTouchViewApp object represents a
visualization application or HMI; the ViewEngine object allows the deployment of the visualization
application to remote computers.

Wonderware Training
 Section 2 – The Deployment Model 3-7

Using the ArchestrA IDE, the deployment model is built using the application Deployment view
(for more information see “The Deployment View” on page 1-25).

y
op
C
ot
N
o

The deployment model hierarchy indicates the deployment dependencies between the objects;
hosted objects cannot be deployed, if the hosting object is not deployed first. For example, an
Area object cannot be deployed, if the hosting AppEngine object is not deployed first; in turn, the
D

AppEngine object cannot be deployed, if the hosting WinPlatform object is not deployed first.
To rearrange the deployment model, the objects need to be undeployed first. For example, to
move an Area from one AppEngine to another, the Area and its hosted application objects must be
undeployed first; the AppEngine objects can remain deployed, as well as any other objects
deployed to those AppEngine objects.

Application Server 2017 Update 3

3-8 Module 3 – Application Infrastructure

When deploying objects, an important setting regarding the deployment model is Cascade
Deploy; when set, it deploys the object and all its hosted objects. The Deploy Object Count field
indicates the number of objects to be deployed; "1" will be displayed, if Cascade Deploy is not
checked.
The Deploy dialog box also includes an option for preserving runtime changes. When the Preserve
Runtime Changes check box is checked, changes made to attribute values at runtime are
preserved on redeployment. This option is checked by default.

y
op
C
In contrast, when undeploying objects, the Cascade Undeploy setting is automatically checked, if
the object is hosting objects. The setting is read-only and cannot be unchecked because hosted
ot

objects cannot be deployed if the hosting object is not deployed. The Undeploy Object Count
field indicates the number of objects to be undeployed.
N
o
D

Wonderware Training
 Section 2 – The Deployment Model 3-9

The WinPlatform Object

The WinPlatform object is the first object that needs to be deployed on a target computer, as it is
the basis for the deployment model.
The main characteristics of the WinPlatform object are:
 Represents a computer in the Galaxy
 Monitors and calculate statistics related to computer node itself; such as CPU, RAM, and
hard drive usage
 Starts and stops hosted engines (AppEngines)
 Relays all off-node communications to other platforms in the Galaxy
 Can serve as the alarm provider to alarms clients
 Includes an embedded engine to handle its own runtime components, such as
historization and scripting
 It must be running (on scan) for the hosted objects to be on scan also
 On the plant model, no objects are assigned to it

y
 On the deployment model, engines are hosted on it
The Galaxy Repository requires a special instance of the WinPlatform object that handles GR-

op
specific operations. This instance must be the first object to be deployed from the Galaxy, and
must remain deployed for any other deployment-related operations to occur. It is identified by a
yellow icon (instead of white) in the different application views, within the ArchestrA IDE.
The first instance of the WinPlatform object that is created automatically becomes the Galaxy
C
Repository platform. If the Galaxy Repository platform is deleted, simply create another instance of
the WinPlatform object and it will become the Galaxy Repository platform.
Each WinPlatform instance created must be configured with their Network address, which is the
ot

computer name or IP address of the target node.

N
o

The Galaxy Repository platform is automatically configured with the computer name of the GR
hosting the Galaxy; the Galaxy Repository to which the ArchestrA IDE is connected to.
D

The AppEngine Object

The AppEngine object is the primary runtime application engine for the Galaxy; along with the
WinPlatform object, it is a key member of the deployment model.
The main characteristics of the AppEngine object are:
 It is the real-time, schedule driven execution engine for the application
 Runs application objects, device integration objects, and areas
 Scan-based execution engine
 Handles communication with the Historian Server for process data historization
 Can be configured for redundancy
 It must be running (on scan) for the hosted object to be on scan also
 On the plant model, no objects are assigned to it
 On the deployment model, areas and device integration objects are hosted on it

Application Server 2017 Update 3

3-10 Module 3 – Application Infrastructure

Important: Deploying more than sixteen AppEngine objects onto a single platform may
deteriorate system performance.

The AppEngine runs all objects hosted on it (application objects, device integration objects, and
areas) on a scan-based schedule set at a configurable speed. The engine will execute all hosted
objects once per scan, one at a time.

Each AppEngine object has its own Scan period setting that can be configured to go as fast as 10
milliseconds and up to 1 hour; the default value is 500 milliseconds.

Note: Careful consideration must be taken when setting the scan rate of an AppEngine. If the

y
objects hosted in the AppEngine take longer than the scan rate to execute, the engine will do a
scan overrun to finish running the objects, effectively skipping one or more scans.

op
C
ot
N
o
D

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-11

Lab 3 – Creating the Plant and Deployment

Models

Introduction
In this lab, you will create a plant model for the Galaxy by using instances derived from the $gArea
template created in the previous lab. These instances will be organized in the Model view and
used throughout the remainder of this course. The Model view will be used to represent the
physical relationship between these instances, which is good for alarm reporting purposes.
Also, in this lab, you will create a deployment model for the Galaxy by using instances derived
from the $gWinPlatform and $gAppEngine templates, also created previously. The Deployment
view will be used to represent the physical relationship of Application Server components as
deployed to specific nodes on a network. After building the deployment model, you will use the
Deployment view to deploy the instances.

y
op
C
ot
N

Objectives
Upon completion of this lab, you will be able to:
o

 Create instances
 Create a plant model for a Galaxy
D

 Create a deployment model for a Galaxy

 Deploy instances to the runtime environment

Application Server 2017 Update 3

3-12 Module 3 – Application Infrastructure

Create the Plant Model

First, you will create a plant model for the Galaxy using instances derived from $gArea.
1. In the bottom-left of the ArchestrA IDE, ensure the Model view is selected.

y
op
C
ot
N
o
D

2. If it is not selected, click the Model tab to display the Model view.

Note: The tabs allow you to change the way the objects are viewed, based on the type of
operation you are trying to run. Different application views are used throughout the remainder
of this course.

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-13

3. In the Template Toolbox, Training\Global toolset, right-click the $gArea template and select
New | Instance.

y
op
The instance appears in the Model view with the default name of gArea_001.
C
ot

4. Rename the instance Receiving.

N
o
D

Application Server 2017 Update 3

3-14 Module 3 – Application Infrastructure

Now, you will create additional instances by dragging the template into the Model view.
5. Drag the $gArea template into the Model view and rename the new instance Production.

y
op
 
C
6. Drag the $gArea template into the Model view five more times, renaming each of the
instances with the following names:
ot

 ControlSystem
 Line1
 Line2
N

 Packaging
 Shipping
o
D

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-15

In the plant model used in this course, the Production area consists of two lines, so you will now
assign these lines to the Production area.
7. In the Model view, drag the Line1 area object onto the Production area object.
Line1 is now assigned to the Production area.

You can also create an assignment by right-clicking on an instance and assigning it to an area.
8. Right-click Line2 and select Assign To.

y
op
C
ot
N
o

The Assign To dialog box appears.

9. In the drop-down list, select Production.
D

Application Server 2017 Update 3

3-16 Module 3 – Application Infrastructure

10. Click Assign.

Line2 is now assigned to the Production area.

The Model view now shows the logical layout of the plant that will be used throughout the
remainder of the course.

y
op
C
Create the Deployment Model
ot

Now, you will use the Deployment view, which displays how the application is distributed across
the available networked computers.
N

11. Click the Deployment tab to display the Deployment view, and then expand TrainingGalaxy
and the Unassigned Host folder, if necessary.
o
D

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-17

12. In the Template Toolbox, Training\Global toolset, right-click $gWinPlatform and select
New | Instance.

y
op
C
ot
N

13. In the Deployment view, rename the new instance GRPlatform.

o
D

Note: The first WinPlatform instance created is a special version of the WinPlatform object
that represents the Galaxy Repository (GR). The icon for the GR node object is always yellow,
instead of the standard white. Also, the GR platform object is automatically configured with the
computer name of the Galaxy Repository node.

Application Server 2017 Update 3

3-18 Module 3 – Application Infrastructure

14. Create another new platform instance and name the instance ProdPlatform.

Important: If you have a one-node environment, you will not create additional platforms and
all objects will be hosted on the GRPlatform.

The red error icon next to ProdPlatform indicates that there is a configuration error.

y
You will now configure the newly created platform with the remote computer name.

op
15. Double-click ProdPlatform to open its configuration editor.
In the Deployment view, a red check mark appears next to ProdPlatform indicating that the
object is currently checked out. C
ot
N
o

16. On the General tab, configure the Network address field with the computer name of the
D

remote PROD node that your instructor provides.

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-19

17. In the top-right corner of the pane, click the Save and Close button to close the editor.

The Check In dialog box appears.

y
op
18. In the Comment field, enter Changed Network Address and click OK.
C
The red check mark for ProdPlatform is no longer displayed because the ProdPlatform has
been checked in. The error icon is no longer displayed indicating the ProdPlatform has been
configured.
ot
N
o
D

Application Server 2017 Update 3

3-20 Module 3 – Application Infrastructure

19. In the Template Toolbox, Training\Global toolset, right-click $gAppEngine and select
New | Instance.

y
op
20. Rename the instance AppEngine1.
C
ot
N
o

Platforms host engines, so you will now move the engine instance to a platform.
21. Drag AppEngine1 to ProdPlatform.
D

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-21

Engines host areas, so you will now move all the areas to the engine.
22. Drag all the area instances from the Unassigned Host folder to the AppEngine1 instance.

y
The Deployment view now shows that all objects in the deployment model have been hosted.

op
Now, you will update the plant model.
23. Click the Model tab to display the Model view, and then expand the Unassigned Area folder.
C
ot
N
o

24. Assign the three objects in the Unassigned Area folder to the ControlSystem area.
D

The Model view now shows that all objects in the plant model have been assigned.

Assigning the platforms and engine to the ControlSystem area allows the control system to
act as a logical organization for filtering alarms.

Application Server 2017 Update 3

3-22 Module 3 – Application Infrastructure

Deploy the Application

Next, you will deploy all the objects in the Galaxy to the runtime environment. The platform for the
Galaxy Repository node must be deployed first in the Galaxy.
25. Click the Deployment tab to display the Deployment view.
The yellow boxes indicate that the objects need to be deployed.
26. Right-click GRPlatform and select Deploy.

Note: You can right-click the Galaxy and select Deploy. This will first deploy the
GRPlatform and then deploy the rest of the platforms in parallel.

y
op
C
ot

The Deploy dialog box appears.

N
o
D

27. Leave the default options and click OK.

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-23

The Deploy dialog box appears and displays the progress of the deployment.
This may take a few moments.
When complete, the progress displays 100% completed.

y
28. Click Close.

op
You will now deploy the second platform.
29. Right-click ProdPlatform and select Deploy.
C
ot
N
o
D

Application Server 2017 Update 3

3-24 Module 3 – Application Infrastructure

The Deploy dialog box appears. Notice that it is set to Cascade Deploy by default and that
nine objects will be deployed. This is because ProdPlatform hosts other objects.

y
op
30. Leave the default options and click OK.
When complete, the progress displays 100% completed. Notice that nine objects were
deployed.
C
ot
N
o
D

31. Click Close.

Wonderware Training
 Lab 3 – Creating the Plant and Deployment Models 3-25

The Deployment view now shows all objects in the Galaxy have been deployed.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

3-26 Module 3 – Application Infrastructure

y
op
C
ot
N
o
D

Wonderware Training
 Section 3 – System Management Console 3-27

Section 3 – System Management Console

This section describes the overall functionality of the System Management Console (SMC). It
explains how to back up and restore using the Galaxy Database manager, and includes how to
create a new Galaxy from a backup file. It discusses how to use the ArchestrA Logger and Log
viewer, and explains how to use Platform Manager.

About System Management Console

The System Management Console (SMC) provides Application Server diagnostics by allowing you
to view the runtime status of some system objects and to perform actions upon those objects. The
SMC is a Microsoft Management Console (MMC) container snap-in for all the diagnostic and
management utilities for your Galaxy application. 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

y
application infrastructure diagnostics by allowing the viewing of runtime status of some system
objects and the ability to perform actions upon those objects.

op
The console tree shows the items that are available in the console. Other snap-ins that may
appear below the ArchestrA SMC node include the Galaxy Database Manager, the Log Viewer,
and the DAServer Manager C
Use the System Platform Management Console shortcut to open the System Management
Console. The ArchestrA System Management Console appears.
ot
N
o
D

Application Server 2017 Update 3

3-28 Module 3 – Application Infrastructure

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)
 Operations Integration Server Manager (OI Server or WinPlatform deployed)
 Log Viewer (all Wonderware nodes)
 Platform Manager (all Application Server nodes)
 Other snap-ins (for example, Historian Server) will be available when other Wonderware
software is installed

y
op
C
ot
N

Each snap-in has its own toolbar, menu options, detail panel, and so on. The contents of these
o

items will change as you select different items in the console tree.
D

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

You use the Galaxy Database Manager to back up and restore a Galaxy. Backing up a Galaxy
creates a single backup file (.cab extension) containing all the files, configuration data, and object
deployment states required to recreate the Galaxy in an empty Galaxy Repository.
During the backup, no write operations are allowed to the Galaxy Repository. If write activity is
occurring, you should back up at a later time.
Restoring a Galaxy uses the backup file to overwrite an existing Galaxy or to create the backed up
Galaxy in a different Galaxy Repository. The restore process prompts you for confirmation before a
Galaxy is overwritten.

Wonderware Training
 Section 3 – System Management Console 3-29

All objects should be undeployed before beginning to restore a Galaxy. During the restore, no
clients can use the Galaxy Repository. If these conditions are not acceptable, you should restore
at a later time.

Galaxy Backup/Restore
You can 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.

Operations Integration Server Manager

The Operations Integration Server Manager provides the required interface for activation,
configuration, and diagnosis of the installed OI Servers.
The Simulator OI Server (OI.SIM) is automatically installed on the Galaxy Repository node, rather

y
than having to be selected for installation as in previous versions. The Simulator OI Server sends
data to attributes of instances configured for I/O automatic assignment in the Galaxy, the same

op
way that a PLC would. With it, you can develop and test a Galaxy before deploying it to your
production environment.

Log Viewer
C
You can use the ArchestrA Log Viewer to view messages logged to the ArchestrA Logger. The
ArchestrA Logger is a system service that records messages from ArchestrA enabled
components. For example, the ArchestrA Log Viewer records the date and time when ArchestrA
ot

components start and any error conditions that occur.

The Log Viewer can:
N

 Monitor messages on any machine in the system

 Send a portion of the log to notepad or e-mail
 Filter messages on a flag
o

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
D

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.

Application Server 2017 Update 3

3-30 Module 3 – Application Infrastructure

The following commands are available from the Action menu when you select a platform or
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 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 View menu when you select a platform in either

y
the console tree or the details pane.

op
C
ot
N

The ArchestrA Logger and Log Viewer are automatically installed when an ArchestrA component
is installed.
 ArchestrA 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
o

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
D

or Manual Service. 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, regularly check logged messages to determine whether all processes are functioning
well.

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.

Wonderware Training
 Section 3 – System Management Console 3-31

A good strategy for troubleshooting problems

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

y
op
C
ot
N

Using Bookmarks
o

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
D

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

Application Server 2017 Update 3

3-32 Module 3 – Application Infrastructure

Add a Regular Bookmark to a Message

To add a regular bookmark, right-click the message, and then on the Bookmark submenu, click
Add Bookmark. 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. Click OK to set the bookmark or Cancel to terminate the process.
Set a Fast Bookmark on a Message
To set a fast bookmark, right-click the message, and then on the Bookmark submenu, click Fast
Bookmark. 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. Change the bookmark name to
something more descriptive, if necessary, in the Bookmarks dialog box at a later time. See To
manage bookmarks below.
Go to a Bookmarked Message
To go to a bookmarked message, on the View menu, click Go To. In the Go To dialog box, enter

y
the name of the message's bookmark by entering it in the box or selecting it from the list. Click Go
To. The Go To dialog box remains open. Use the Previous and Next buttons to go to the nearest

op
bookmarked message above and below, respectively. When you are finished 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.
C
To Manage Bookmarks
On the View menu, click Bookmarks. In the Bookmarks dialog box, you can manage current
ot

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. For example, to rename a bookmark, select the
N

book, press F2 and enter the new name. Note that each bookmark must have a unique name, so
you cannot bookmark two messages with the same name.
To go to a bookmarked message, double-click it in the list or select it and click Go To. To remove
o

one or all bookmarks from your logged messages, select a message and click Remove, or
Remove All. To add a new bookmark, select the message you want to bookmark in the message
D

window and click Add. This function is comparable to a fast bookmark. Rename it by pressing F2.
When you are finished, 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.

Wonderware Training
 Section 3 – System Management Console 3-33

Platform Manager
Platform Manager is a tool that provides access and control to the runtime status of all deployed
platform and engine objects in the Galaxy; it also allows for the opening of the Object Viewer
application. The tool is targeted to application developers and maintenance personal; operators
and other users of the Galaxy should use a graphical interface such as an InTouch application.

y
op
C
The Platform Manager software is installed as part of the Application Server Bootstrap service as a
snap-in to the ArchestrA System Management Console (SMC); access to the runtime Galaxy is
provided through the local WinPlatform object. This means that from any computer that has a
ot

WinPlatform deployed, you will have access and control to all deployed platforms and engines in
the Galaxy.
If the Galaxy has security enabled, Platform Manager will ask for login credentials; access to the
N

tool, as well as operations within the tool will be dictated by the permissions assigned to the user.

Key Functions
o

Platform Manager provides access to the following deployed objects from the Galaxy:
WinPlatform
D

 AppEngine
 ViewEngine
Platform Manager allows you to:
 View the following information of deployed WinPlatform objects:
 Platform Name – The name of the platform object
 Node Name – The computer name where the platform is deployed to
 Platform ID – The internal unique ID of the platform
 Platform Status – Indicates the current status of the platform
 Operations Status – Indicates the progress status for a command that is placed on
the platform
 View the following information of deployed engine objects:
 Engine Name – The name of the engine object
 Engine Status – Indicates the current status of the engine

Application Server 2017 Update 3

3-34 Module 3 – Application Infrastructure

 Engine ID – The internal unique ID of the engine

 Engine Category – Indicates the type of engine; possible values are: Application and
View
 Operation Status – Indicates the progress status for a command that is placed on the
platform
 Sort platforms by object name, node name, or ID
 Set platform and engines off scan and on scan
 Shutdown and start platform and engines
 Launch Object Viewer from any platform or engine
 Remove the platform from the local computer
Platforms and engines can have one of the following statuses:
 Not Available – The computer is powered off
 Shutdown – The object has been shut down normally
 Shutdown - Failed – The object has been shut down due to failure
Running On Scan – The object is running and executing

y


 Running Off Scan – The object is running but not available for execution

op
 Various transitional statuses between (for example, Shutting Down)

Important: The Remove Local Platform option effectively removes the deployed platform object
and all hosted objects. The configuration project database for the Galaxy will not be updated and
C
the corresponding objects will still show as deployed in the ArchestrA IDE.
ot
N
o
D

Wonderware Training
 Section 4 – The Runtime Environment 3-35

Section 4 – The Runtime Environment

This section describes the runtime environment of the Galaxy, explains communication between
automation objects’ attribute references, and introduces Object Viewer and Platform Manager
tools.

The Runtime Environment

All deployed objects, as per the defined deployment model, constitute the runtime environment of
the Galaxy. This runtime environment is governed by the AppEngine objects running the
application objects, device integration objects, and areas from the Galaxy.
The AppEngine object execution system is based on a scheduled, scan-based system. The scan
period of the engine defaults to 500 milliseconds and can be configured to any value in the 10
millisecond to 1 hour range. The scans are scheduled and all objects hosted in the engine are run
once per scan.

y
op
C
ot

Objects are run one at a time; for example, in the figure above, object B will not be run until object
A has finished. After all objects have finished, whatever remaining time is left on the scan is spent
on housekeeping tasks by the engine; after that, the engine goes idle until the end of the scan.
N

If, for whatever reason, objects take longer to execute and the end of the scan is reached (for
example, the running of complex scripts or too many alarms conditions exist), the engine will go
over the next scan to continue executing the current set of objects; the remainder of the last scan
is spent in housekeeping tasks or idle, or both. This is called a scan overrun and it could span
o

multiple scans. The AppEngine provides attributes to monitor if scan overruns have occurred:
 Scheduler.ScanOverrun.Condition
D

 Scheduler.ScanOverrunsCnt
 Scheduler.ScanOverrunsConsecCnt
In general, objects are executed in the following order:
1. Device Integration objects, in alphabetical order.
2. Areas and Application objects; Application objects are run first, and then their hosting Area. By
default, they are executed in alphabetical order.
3. The AppEngine itself.

Application Server 2017 Update 3

3-36 Module 3 – Application Infrastructure

Consider the following hosting relationship within a given AppEngine object:

At any given scan, the objects are executed in the following order:

y
op
1. The Device Integration objects are executed first, in alphabetical order.
2. The Area objects, including their hosted Application objects are executed (by default) in
alphabetical order.
C
a.The Areas, in alphabetical order are: Area 1, Area 2 and then Area 3.
b.For each of the areas, the hosted Application objects are executed before their
corresponding Area object: X, Y, Z for Area 1; A, B, C for Area 2; and M, N, P for Area 3.
ot

3. Finally, the AppEngine object executes.

N
o
D

Wonderware Training
 Section 4 – The Runtime Environment 3-37

Attribute References
Access to runtime data in the deployed objects can be done either from other deployed objects in
the Galaxy, or from ArchestrA client tools, such as Object Viewer and InTouch. Communication
between computers handled by the WinPlatform objects deployed to each node and access to
runtime data is done through the local WinPlatform object; the location of the target object is not
required.
All automation objects provide data through their attributes; since an object has several attributes,
a reference to the specific looked-for attribute must be made. The reference to an attribute is
always the object name and the name of the attribute, separated by a dot:
<object name>.<attribute name>
Notice that the attribute reference does not includes the location of the object; this is automatically
handled by ArchestrA and the WinPlatform object.

y
op
C
ot

As soon as an attribute reference is submitted from Object Viewer or from a graphic in InTouch,
N

the local platform requests the value from the platform hosting the object; ArchestrA takes care of
handling the locations of all deployed objects. As long as there is network access between
computers, the real-time value is sent to the requested party.
The same behavior occurs when one object requests data from another object, object 1 will have a
o

reference to an attribute in object 2. The location of object 2 is handled by ArchestrA.

D

Application Server 2017 Update 3

3-38 Module 3 – Application Infrastructure

Object Viewer
Object Viewer is a runtime tool that allows you to test, diagnose, and troubleshoot the Galaxy by
providing read and write access to all deployed automation objects across all computers in the
Galaxy. The tool is targeted to application developers and maintenance personal; operators or
other users of the Galaxy should use a graphical interface such as an InTouch application.

y
op
C
ot

The Object Viewer software is installed as part of the deployment of the WinPlatform object. This
N

means that from any computer that has a WinPlatform object deployed you will have access to all
deployed automation objects in the Galaxy.
You can open the Object Viewer tool from two places:
o

 The ArchestrA IDE, as long as there is a local platform deployed

 The Platform Manager, from any computer with a platform deployed
D

If the Galaxy has security enabled, Object Viewer will require a logged in user to allow (or not)
writing values to automation objects. The Galaxy also includes a specific security permission to
allow writing values to objects using Object Viewer; meaning that even if you have security
permissions to, for example, change a setpoint, you will also need this additional permission to do
so from Object Viewer.

Wonderware Training
 Section 4 – The Runtime Environment 3-39

Key Functions
Upon opening Object Viewer, the currently logged in user from the ArchestrA IDE or the Platform
Manager is automatically logged in to the tool.
Object Viewer allows you to:
 Browse the deployment model for all currently deployed automation objects
 View a list of all the attributes in an automation object, including hidden attributes
 View updated/changing values of attributes (see note below)
 Write values to attributes
 Organize attributes you frequently monitor in watch windows
 Save watch windows in watch list files for quick access to frequently monitored attributes
 Change the currently logged in user
Some of the parameters of an attribute that can be viewed with Object Viewer are:
 Value – The value of the attribute
 Timestamp – Indicates the date and time the attribute value or quality last changed, or

y
both
Quality – Indicates the quality of the current value of attribute; possible values are: Good,

op

Uncertain, Initializing, and Bad.
 Status – Indicates the status of the last read or write operation on the attribute; possible
values are: OK, Pending, Warning, and several Error statuses
Security Classification – One of the seven permissions that can be assigned to an

C
attribute to allow users to write to it (for more information see Module 9, “Security
Overview”)
 Locked – Indicates if the attribute is locked at configuration time; this makes the attribute
ot

read-only in runtime
 Type – The ArchestrA data type of the attribute
N

Note: To minimize network traffic and resources used, Object Viewer does not display real-time
values for the attributes, instead it retrieves values at a constant speed of 1 second. This applies
only to attributes added to a watch window.
o
D

Application Server 2017 Update 3

3-40 Module 3 – Application Infrastructure

y
op
C
ot
N
o
D

Wonderware Training
 Lab 4 – Using Object Viewer 3-41

Lab 4 – Using Object Viewer

Introduction
In this lab, you will use Object Viewer as a diagnostic tool to test your application objects and
modify their attribute values. You will then create, rename, and save watch lists and add attributes
to the watch lists.

Objectives
Upon completion of this lab, you will be able to:
 Open Object Viewer from the ArchestrA IDE and the SMC
 Add attributes to a watch list
 Create and rename a watch list
 Save a watch list

y
op
C
ot
N
o
D

Application Server 2017 Update 3

3-42 Module 3 – Application Infrastructure

Open and Add Items to Object Viewer

First, you will open Object Viewer, which is a diagnostic tool used to monitor runtime data.
1. In the Deployment view, right-click ProdPlatform and select View in Object Viewer.

Note: If you are performing this lab using a single-node network configuration, you will use
the GRPlatform for this step.

y
op
C
ot

The Object Viewer window appears and displays the ProdPlatform attributes.
N
o
D

Notice that the console tree is in the top-left pane, the attributes of the selected object in the
top-right details pane, and the watch window in the bottom pane. To see updated runtime
values, you will now add attributes to the watch window.

Wonderware Training
 Lab 4 – Using Object Viewer 3-43

2. Click the Attribute Name column heading to sort the list based on the attribute names.

Note: You can click any column heading by which you would like to sort.

3. In the console tree pane, ensure that ProdPlatform is selected, and then in the details pane,
scroll down, and then right-click PlatformInfo and select Add to Watch.

y
op
C
ot
N

The attribute is added to the watch window.

o
D

Application Server 2017 Update 3

3-44 Module 3 – Application Infrastructure

Alternatively, you can drag and drop attributes to add them to the watch window.
4. In the console tree pane, click GRPlatform and in the details pane, drag PlatformInfo to the
watch window.

y
op
C
ot

5. In the watch window, expand the Value column to view the entire full value of the attributes.
N
o
D

The PlatformInfo attribute displays the processor and operating system information of the
computer to which the platform is deployed.
6. Add GR.TimeOfLastDeploy to the watch window.

This attribute shows the date and time of the most recent object deployment in the Galaxy.

Wonderware Training
 Lab 4 – Using Object Viewer 3-45

Rename the Watch List

Next, you will rename the watch list tab to give a better description of the attributes that were
added.
7. Right-click the empty space in the watch window and select Rename Tab.

y
op
The Rename Tab dialog box appears.
C
8. In the Tab Name field, enter Platforms.
ot
N
o
D

9. Click OK.
The watch window tab now displays the new name.

Application Server 2017 Update 3

3-46 Module 3 – Application Infrastructure

Save the Watch List

Now, you will save your watch list, which will allow you to access the information at any time.
10. On the File menu, select Save Watch List As.

The Save As dialog box appears.

11. Navigate to the C:\Training folder, and then in the File name field, enter
My Watch Window.xml.

Note: Adding the .xml file extension is optional. This allows you to edit the file with an XML

y
editor. Object Viewer does not require a file extension.

op
C
ot
N
o
D

12. Click Save.

13. Close Object Viewer.

Wonderware Training
 Lab 4 – Using Object Viewer 3-47

Use the SMC Platform Manager to Open Object Viewer

Next, you will start the SMC and use the Platform Manager feature to open Object Viewer.
14. Open the System Platform Management Console (SMC).
15. In the left pane of the SMC, click Platform Manager.
The Galaxy is displayed in the right pane.

y
op
C
ot

16. In the left pane, expand Platform Manager and select TrainingGalaxy.
Both platforms in the Galaxy are displayed in the right pane.
N
o
D

Application Server 2017 Update 3

3-48 Module 3 – Application Infrastructure

17. In the right pane, right-click ProdPlatform and select Launch Object Viewer.

Note: You can also select ProdPlatform in the right pane, and then on the toolbar, select
Launch Object Viewer .

Object Viewer reappears and displays the ProdPlatform attributes and the engine it hosts.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 4 – Using Object Viewer 3-49

Load the Saved Watch List

Now, you will load the Object Viewer watch list you saved earlier and observe platform attributes.
18. Click the blank area of the Watch List to change focus.
19. On the File menu, select Load Watch List.

The Open dialog box appears.

20. Navigate to C:\Training and select My Watch Window.
The name will show as My Watch Window.xml if your computer has extensions turned on.

y
op
C
ot
N
o

21. Click Open.

D

The Platforms watch list with the platform attributes you added earlier are now visible again.

Application Server 2017 Update 3

3-50 Module 3 – Application Infrastructure

Add a New Watch List

Multiple watch lists allow you to view attributes in organized groups. Each time you add a new
watch list, it creates a new tab at the bottom of the watch window. These tabs create a simple way
to switch between watch lists.
22. In Object Viewer, right-click the empty space in the watch window and select
Add Watch Window.

y
op
A new tab appears at the bottom of the watch window.
C
ot
N
o
D

Wonderware Training
 Lab 4 – Using Object Viewer 3-51

23. In the console tree pane, click AppEngine1, and then in the details pane, add the following
attributes to the watch window and adjust the column sizes to view your data:
 ScanState
 ScanStateCmd
 Scheduler.ScanPeriod

y
op
C
ot
N

The ScanState attribute shows if the AppEngine1 is on scan. The ScanStateCmd attribute
allows you to set AppEngine1 on or off scan. The Scheduler.ScanPeriod attribute is the
period of time, in milliseconds, in which AppEngine1 will run all its hosted objects.
o

24. Right-click the watch window and select Rename Tab.

25. In the Tab Name field, enter AppEngine.
D

26. Click OK.

Application Server 2017 Update 3

3-52 Module 3 – Application Infrastructure

The watch window tab displays the new name.

27. On the File menu, click Save Watch List.

28. Minimize Object Viewer.

y
op
C
ot
N
o
D

Wonderware Training
 Section 5 – Data Simulation 3-53

Section 5 – Data Simulation

This section describes the OI Simulation Server and explains the configuration of an $OPCClient
to the OI.SIM.

Simulator OI Server
The Simulator OI Server (OI.SIM) is automatically installed on the Galaxy Repository node, rather
than having to be selected for installation as in previous versions. The Simulator OI Server sends
data to attributes of instances configured for I/O automatic assignment in the Galaxy, the same
way that a PLC would. With it, you can develop and test a Galaxy before deploying it to your
production environment.
Simulator is a reserved keyword for naming device integration objects. You can create a DI Object
named Simulator and configure it with a corresponding Server node, Server name (Device
integration application name), and at least one topic or Scan Group named Fast. Then, new
instances are automatically assigned to the Simulator in the topic or scan group named Fast.

y
To gather simulated I/O data, you need to make sure that all the I/O references of attributes in

op
instances all exist in the DI Object or Device Integration Server. Specifically, if connecting an
OPCClient instance named Simulator with the OI.SIM and an added Scan Group named Fast, it
connects with the OI.SIM automatically to provide simulated I/O data to any instances that are
assigned to the Fast scan group. It does not need to have I/O references added to the DI Object
and OI.SIM server.
C
Note that a new starter cab file (Default.cab) includes a DI Object named Simulator that is
configured to connect to OI.SIM.
ot
N
o
D

Application Server 2017 Update 3

3-54 Module 3 – Application Infrastructure

y
op
C
ot
N
o
D

Wonderware Training
 Lab 5 – Configuring for Data Simulation 3-55

Lab 5 – Configuring for Data Simulation

Introduction
In this lab, you will configure an instance of the $OPCClient and activate the OI.SIM Simulator.
You will connect the instance of the $OPCClient to the OI.SIM, and then will use Object Viewer to
monitor the connection status in runtime.

Objectives
Upon completion of this lab, you will be able to:
 Configure an $OPCClient to the OI.SIM
 Monitor the connection status to the OI.SIM

y
op
C
ot
N
o
D

Application Server 2017 Update 3

3-56 Module 3 – Application Infrastructure

Create a Connection to a Field Device

First, you will create an instance of the $gOPCClient and configure it to connect to the OI.SIM
Simulator.
1. In the ArchestrA IDE, Template Toolbox, Training\Global toolset, right-click $gOPCClient
and select New | Instance.

y
op
C
ot

2. Rename the instance Simulator.

N
o
D

3. Double-click Simulator to open its configuration editor.

Wonderware Training
 Lab 5 – Configuring for Data Simulation 3-57

4. On the General tab, configure the instance as follows:

Server node: <Instructor will provide Production node>

Server name: OI.SIM.1

5. On the Scan Group tab, in the Available scan groups area, click to add a scan group.
6. Name the group Fast and press Enter.

y
op
C
7. Click the Save and Close button to close the editor.
The Check In dialog box appears.
ot

8. In the Comment field, enter Simulator and click OK.

9. In the Model view, assign the Simulator instance to the ControlSystem area.
N
o
D

Application Server 2017 Update 3

3-58 Module 3 – Application Infrastructure

10. In the Deployment view, assign the Simulator instance to ProdPlatform\AppEngine1.

11. Right-click Simulator and select Deploy.

y
op
C
ot

12. Leave the default options and click OK.

N
o
D

Wonderware Training
 Lab 5 – Configuring for Data Simulation 3-59

When complete, the progress displays 100% completed.

13. Click Close.

y
Next, you will use the SMC to check the activation status of the OI.SIM.

op
14. In the SMC, expand Operations Integration Server Manager\TrainingGalaxy\
ProdPlatform.
Note that OI.SIM.1 has been activated automatically.
C
ot
N
o
D

Application Server 2017 Update 3

3-60 Module 3 – Application Infrastructure

View the Attributes in Runtime

You will now return to Object Viewer to view the attribute values in runtime.
15. In the ArchestrA IDE Deployment view, right-click Simulator and select View in Object
Viewer.

y
op
C
ot

Object Viewer appears and refreshes.

16. Right-click the empty area of the watch window and select Add Watch Window.
N

17. Right-click the watch window and select Rename Tab.

18. Name the tab Simulator and click OK.
o
D

Wonderware Training
 Lab 5 – Configuring for Data Simulation 3-61

19. From the Attribute Name column, add the following attributes to the watch window:
 ConnectionStatus
 ScanState
 ScanStateCmd

y
op
C
ot

The ConnectionStatus attribute displays the communication status between the topics
N

configured in the device integration object and the topics in the Device Integration Server.
20. Add the ScanGroupList attribute to the watch window.
The Array for Simulator.ATTRIBUTE(ScanGroupList) dialog box appears.
o

This appears because ScanGroupList is an array and requires an index to be entered.

D

You will now configure the array to display the entire array dimension.
21. In the Enter an array index field, enter -1.

22. Click OK.

Application Server 2017 Update 3

3-62 Module 3 – Application Infrastructure

The ScanGroupList is added to the watch window.

23. In the Attribute Reference field, enter Simulator.Fast.$Sys$Status.

y
op
C
24. Click Go.
ot

The Attribute dialog box appears.

The Attribute Reference to display in the watch window has automatically been selected.
N
o
D

25. Click OK.

Wonderware Training
 Lab 5 – Configuring for Data Simulation 3-63

The Simulator.Fast.$Sys$Status attribute reference is added to the watch window.

The $Sys$Status item for the scan group reports the communication status between the OI
Server and the PLC associated with the scan group. The OI.SIM is a data simulator, so does
not have an actual connection to a PLC. This value will always be True.
26. Right-click the empty area in the watch window and select Save.

y
27. Minimize Object Viewer.

op
C
ot
N
o
D

Application Server 2017 Update 3

3-64 Module 3 – Application Infrastructure

y
op
C
ot
N
o
D

Wonderware Training
 y
op
Module 4 – Application Objects
C
Section 1 – Introduction to Application Objects 4-3
ot

Section 2 – Object Attributes 4-7

Lab 6 – Modeling Meters 4-15
N

Section 3 – Change Control and Propagation 4-27

Lab 7 – Configuring Change Control and Propagation 4-31
o

Section 4 – Containment 4-41

D

Lab 8 – Modeling the Mixer 4-45

4-2 Module 4 – Application Objects

Module Objectives
 Introduce Application Objects
 Explain and configure Attributes in objects
 Describe propagation of changed templates to derived objects
 Explain and configure a containment relationship between objects

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Introduction to Application Objects 4-3

Section 1 – Introduction to Application Objects

This section describes the application objects in the Galaxy and discusses the basic configuration
of the $UserDefined object.

Application Objects
Application Server is designed as an Object Oriented Application. The objects are fundamental to
Application Server. Application Objects can be configured to do a number of things in Application
Server. They can store process data in the Historian. Application Server provides the following
Application objects:
 AnalogDevice
 DiscreteDevice
 Sequencer
 SQLData

y
 UserDefined

op
AnalogDevice Object
The AnalogDevice object can act as either a basic analog input device (with optional output) or as
an analog regulator device that provides an external representation of a Proportional-Integral-
C
Derivative (PID) controller that exists elsewhere, typically a Programmable Logic Controller (PLC)
or a Distributed Control System (DCS).
ot

DiscreteDevice Object
The DiscreteDevice object is a general purpose Application Object that represents a large class of
physical equipment common in manufacturing, such as pumps, valves, motors, and conveyors.
N

These devices have two or more discrete physical states (for example, Open, Closed, and
Traveling). The actual state of a device is monitored via a combination of discrete inputs and a
device can be optionally controlled using a combination of discrete outputs.
o

Sequencer Object
D

The Sequencer object is an ArchestrA application object that lets you configure, execute, and
manipulate a sequence of operations associated with ArchestrA attributes, within an 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 Object
The SQLData object provides an interface to a Microsoft SQL Server running on any computer in
the network. You can configure the SQLData object to either connect to an existing SQL Server
database table or you can create a new SQL Server database and table(s).

Application Server 2017 Update 3

4-4 Module 4 – Application Objects

UserDefined Object
The UserDefined object provides the basic functionality you need to develop an ArchestrA
supervisory application. The UserDefined object provides this functionality as configurable
attributes, scripts, and graphics. For this reason, it will be used as the template for many objects in
the application used in this training course.
In the following image there is a field device. In this example, you can acquire either Boolean or
Analog values from the field device:
 For the Boolean values, there are a couple of attributes where we save the input source
and the input value. The input source will save the I/O address of that data point and the
input value will save the actual value. The object saves the data to a discrete field
attribute.
 For Analog values, we also have a couple of attributes related; one that saves the I/O
address, which is the input source and one that saves the value, which is the input value.
Since these are analog values, they can be scaled and saved in an analog field attribute.
Scaling needs to be configured with the Engineering Units Maximum and Minimum and
the Raw Values Maximum and Minimum.

y
op
C
ot
N
o
D

Note: The Input/Output direction in Application Server is opposite of that in the PLC.
In Application Server, plant data comes “in” and settings go “out” to the PLC.

Wonderware Training
 Section 1 – Introduction to Application Objects 4-5

You can configure Attributes as an Analog or Discrete type with one of the following access
modes:
 Input: The Attribute only accepts input. The Attribute is updated based on the value that is
read from the configured input address.
 InputOutput: The 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 Attribute only sends output. The Attribute writes to the specified output
destination. The Output mode supports the following categories:
 Calculated
 Calculated retentive
 User writeable
 Object writeable
The Attribute supports the following data types:
 Boolean

y
 Integer
 Float

op
 Double
 String
 Time
 ElapsedTime
C
 InternationalizedString
The Attribute provides the enabling and configuration for the following functionality:
ot

 Scaling of Input and Output values

 History
 HiHi, Hi, Lo and LoLo Limit Alarms
N

 Rate of Change Alarms

 Target Deviation Alarms
 Bad Value Alarm
o

 Statistics
D

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.

Application Server 2017 Update 3

4-6 Module 4 – Application Objects

UserDefined Object as a Template

Use the UserDefined object as a template containing 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 Attributes that
represent variables associated to the tank system:
 LT100 - Analog Attribute - Input from a level transmitter configured with options such as:
Scaling, Limit alarms and Statistics (Min/Max/Avg).
 TT100 - Analog Attribute - Input from a temperature transmitter configured with options
such as Rate of Change alarm and Statistics (Min/Max/Avg).
 SW100a - Discrete Attribute - Input from a limit switch configured with options such as
State Labels and State alarm.
 SW100b - Discrete Attribute - Input from a limit switch configured with options such as
State Labels and State alarm.
 XV100a - Discrete Attribute - InputOutput to a solenoid valve configured with options such

y
as State Labels, State alarm, and Statistics (Open/Close time).
 XV100b - Discrete Attribute - InputOutput to a solenoid valve configured with options such

op
as State Labels, State alarm, Statistics (Open/Close time).

UserDefined Object as a “Container” C

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. For more details, refer to Section 4 on the
subject of Containment.
ot
N
o
D

Wonderware Training
 Section 2 – Object Attributes 4-7

Section 2 – Object Attributes

This section describes the Attributes tab and the features of an attribute. It also discusses the
configuration options available for application objects, including automatic and manual I/O
binding capabilities.

Creating and Working with Attributes

When you add an attribute to a template, the attribute, its data type, and writeability are
automatically locked in the child instances.
If attribute 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

y
scripting and attribute configuration functions.
On the Attributes tab, you can define the following initial information and parameters for the

op
attribute:
 Add a new attribute to an object.
 Name the attribute and provide a description.
Configure its data type.

C
For a Boolean data type, you can specify different text strings for the “False” label and
“True” label. For example, if a Boolean attribute is associated with the status of a motor,
you can specify the states as “Stopped” and “Running.” Text boxes appear for you to enter
ot

these strings when you select a Boolean data type.

These labels are also shown in the Value and Limit columns of the Alarm and Event
database and InTouch AlarmView control.
N

 Specify the attribute writeability.

 Set initial values if the attribute is user writeable.
 Enable and set locks and security on the new attribute.
o

 Set whether the new attribute is an array and how many elements are in the array.
D

Attribute Naming Conventions

Attribute names can have up to 32 alphanumeric characters, including periods. Attribute names
must include at least one letter.
 An attribute name that starts with an underscore (_) as the first character of the name is a
hidden attribute. Hidden attributes do not appear in the Attribute Browser, the
Properties>Attributes dialog box, or the Object Viewer unless you select to view Include
Hidden.
 Using the word “quality” as an attribute name is not supported. “Quality” is used by
InTouch HMI in a set of dotfields to show the reliability of data values assigned to an I/O
tag. An attribute named “Quality” cannot be accessed through FS Gateway or InTouch
due to a naming conflict.

Application Server 2017 Update 3

4-8 Module 4 – Application Objects

Attributes and Scripting

When using attributes in scripting, keep the following guidelines in mind.
 If you use Calculated and Calculated retentive attributes as counters, they must be
manually initialized. For example, if you use me.Attribute=me.Attribute+1 as a counter in a
script, you must also initialize the attribute with something like me.Attribute=1 or
me.Attribute=<some attribute value>.
 Calculated attributes can be initialized in scripts with Execution type triggers of On Scan
and Execute, but not initialized in Startup scripts.
 You must initialize Calculated retentive attributes in Startup scripts and you can initialize
these attributes in On Scan and Execute scripts. A Calculated retentive attribute 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 attribute. If the value is FALSE, initialize the attribute.

y
About the Attributes Tab

op
If the object you are editing does not have any attributes defined, the Attributes tab will be empty,
except for buttons for adding, filtering, duplicating, deleting, and viewing attributes and attribute
features. C
You can activate various features, such as I/O, History, State alarm and Statistics. When you add
an attribute to an object, information about the attribute is shown.
ot
N
o
D

When you add an attribute to an object, the Attributes tab divides into three sections. The left side
of the page lists attributes, the top right shows information about the currently selected attribute,
and the bottom of the right side contains fields for configuring features.

Wonderware Training
 Section 2 – Object Attributes 4-9

Adding Features to Attributes

The Attributes tab allows you to configure an existing attribute for I/O, alarms, and history
functionality not embedded in the original object.

About Features Inheritance

You can add features to attributes that are in either derived templates or in instances. You cannot
add features to attributes in Base templates. The following parent-child object characteristics also
apply to features added to objects:
 If you add a feature to an attribute in a derived template that has objects derived from it, all
child objects inherit the feature.
 You cannot add a feature to attributes on derived objects that duplicate parent object
features in name and type.
 You cannot add a feature with the same name as an existing feature.
 Renaming a feature on an attribute in the template to which it was originally added
renames all other objects derived from the template. This change happens when the

y
template is checked in.
You can check in a template with an attribute configured with a new feature with the same

op

name as an existing feature on an attribute in a derived object. The template definition of
the feature overrides the feature in the derived object.
 If you remove a feature on an attribute from a template, that feature is removed from any
child object. You see the change when you check in the template.
C
Using the I/O Feature
ot

The I/O feature allows you to configure all aspects of data input and output for an attribute.
You can configure I/O type and you can specify input sources and output destinations. The I/O
types you can specify are:
N

 Read (Input)
 Read/Write (InputOutput)
 Write (Output)
o

You can also configure advanced properties. The attribute’s data type and I/O type determine
what Advanced I/O properties are available.
D

Using Read/Write I/O in Scripts

Two common types of scripts can be written on an attribute configured with a Read/Write I/O
feature: One can look at the input side and one can look at the output side.
The input side script uses the current value coming from the input source location and performs
logic or calculations on it. This script refers directly to the attribute in its expressions. For example,
if the attribute is “me.attribute1”, the script refers directly to “me.attribute1” for data change
conditions and for expressions within the script.
The output side script can modify output or validate a new requested output value. This script
refers to the “WriteValue” attribute configured on the attribute: “me.attribute1.WriteValue”.

Quality of Read, Read/Write, and Write I/O

When the object is On Scan, the value and quality of an attribute configured with a Read I/O
feature mirrors the quality of the externally referenced attribute in the case of successful reads.

Application Server 2017 Update 3

4-10 Module 4 – Application Objects

The data quality of the configured attribute is set to Bad when reads fail because of
communication errors or datatype conversion failures.
While the extended object is On Scan, it behaves as follows: If an external set (for example, from a
user) to the configured attribute causes either the value or quality to change, then a write of the
configured attribute’s value to the destination occurs during the next execute phase.
The quality must be Good or Uncertain for a write to occur. For writes to occur because of a quality
change, the quality change must be a transition from Bad or Initializing to Good or Uncertain. The
attribute called WriteValue is publicly exposed.
When the configured object is Off Scan, quality is always Bad and user sets are accepted.

Using the History Feature

Any attribute that exists at runtime and is not already historized can be configured with a history
feature.
A history feature can be added to a template or an instance attribute. If added to a template
attribute, the existence of the history feature is automatically locked in derived objects.

y
You can configure Writeable and Calculated attributes of the following data types with a history

op
feature:
 Float, Double (stored as a Float)
 Integer
Boolean

C
 String stored as Unicode, 512 character limit
 Custom Enumeration stored as an Integer
ElapsedTime stored as seconds
ot

Using the Limit Alarms Feature

N

Select the Limit alarms feature to add and configure a Limit Alarm on an attribute of Integer, Float,
or Double data type. You can add a Limit alarm feature to a template or instance. If added to a
template attribute, the Limit alarm feature is automatically locked in derived objects. Limit alarm
features cannot be added to attribute arrays.
o

You can enable up to four categories of Limit alarms. When enabled, alarms will be triggered when
D

the value reaches the configured limit.

 HiHi
 Hi
 Lo
 LoLo

Wonderware Training
 Section 2 – Object Attributes 4-11

Using the ROC Alarms Feature

Select the ROC alarms feature to add and configure a Rate of Change (ROC) alarm on an
attribute of Integer, Float, or Double data type. You can add a ROC alarm feature to a template or
instance. If added to a template attribute, the ROC alarm feature is automatically locked in derived
objects. ROC alarm features cannot be added to attribute arrays.
You can enable up to two categories of ROC alarms. When enabled, alarms will be triggered when
the value reaches the configured limit.
 Up: Rate of increase
 Down: Rate of decrease

Using the Deviation Alarms Feature

Select the Deviation alarms feature to add and configure a Deviation alarm on an attribute of
Integer, Float, or Double data type. You can add a Deviation alarm feature to a template or
instance. If added to a template attribute, the Deviation alarm feature is automatically locked in
derived objects. Deviation alarm features cannot be added to attribute arrays.

y
You can enable up to two categories of Deviation alarms. When enabled, an alarm will be

op
triggered when the attribute level deviates from a target value by a configured amount.
 Major: The major alarm deviation tolerance
 Minor: The minor alarm deviation tolerance
C
Using the State Alarm Feature
Select the State alarm feature to add and configure a State alarm on an attribute of Boolean data
type. You can add a State alarm feature to a template or instance. If added to a template attribute,
ot

the State alarm feature is automatically locked in derived objects. State alarm features cannot be
added to attribute arrays.
N

Using the Bad Value Alarms Feature

Select the Bad Value alarms feature to add and configure a Bad Value alarm on an attribute of
Boolean, Integer, Float, or Double data type. If enabled, alarms will be triggered when the attribute
o

has bad data value or data quality.

You can add a Bad Value alarm feature to a template or instance. If added to a template attribute,
D

the Bad Value alarm feature is automatically locked in derived objects. Bad Value alarm features
cannot be added to attribute arrays.
In the Alarm message box, you can browse and select an existing attribute or you can type a text
string as an alarm message. This text string appears in the InTouch alarm view.
Specify a Priority for this alarm, a numeric value for the urgency of the alarm. Valid values are 1
through 999, with 1 being the most urgent.

Application Server 2017 Update 3

4-12 Module 4 – Application Objects

Using the Statistics Feature

Select the Statistics feature to add and configure calculation of statistics on an attribute of
Boolean, Integer, Float, or Double data type. If enabled, the following statistics are calculated:
 Time since last transition: If no change in the input value, the elapsed time value
increments to show the total elapsed time since the last transition. A change in input value
resets the elapsed time since last transition.
 Average: Defined as the sum of the sample size divided by the number of sample size
attributes in the data set.
 Standard deviation: Defined as the amount of variation or “scatter” from the average.

Using the Log Change Feature

Select the Log Change feature to log system events for an attribute of Boolean, Integer, Float, or
Double data type.
When enabled, the Log Change feature logs data change events as well as user events.

y
Using I/O Auto Assignment

op
Instead of configuring I/O references manually, or writing scripts to set them at runtime, you can
use I/O auto assignment. Manual configuration of I/O references can be time consuming. Scripting
these references eliminates the issues of manual configuration, but can significantly increase the
time needed for deploying objects. With I/O auto assignment, you do not need to check out
C
individual objects to configure I/O references, and you do not experience the runtime penalties
associated with scripting.
ot

Note: Note: I/O auto assignment is the default setting for application and other system objects,
such as area objects. Device Integration (DI) objects must be manually configured.

When you add input or output attributes to an area or application object in the Attributes tab of the
N

Object Editor, the default setting prepares these attributes for I/O automatic assignment. The auto
assignment reference appears in the I/O section of the Attributes tab if you have enabled the I/O
attribute feature. The default string for an input reference is:
o

<IODevice>.[ObjectName].[AttributeName].InputSource
where [ObjectName] is the hierarchical name of the application or system object, and
D

[AttributeName] is the name of the attribute.

The default string for an output reference is:
<IODevice>.[ObjectName].[AttributeName].OutputDest
The string <IODevice> is a placeholder that indicates the I/O reference will be built automatically.
The reference is created when you link the object to a scan group and DI object, without the need
to manually enter or script the reference.
The following is an example of an I/O reference string before the object has been assigned to a
scan group and DI object:
<IODevice>.Mixer.Tank.Inlet.InputSource
Once you assign the object to a scan group, the reference resolves to include the assigned Device
Integration (DI) object and scan group.

Wonderware Training
 Section 2 – Object Attributes 4-13

For example, assigning the object to the scan group “Fast” under DI object “OPC001” will change
the reference to:
OPC001.Fast.Mixer.Tank.Inlet.InputSource

Important: Do not lock InputSource or OutputDest attributes when using I/O auto assignment. If
either InputSource or OutputDest attributes, or both, are locked in the parent template, the
attributes cannot be updated with the resolved reference when the object is deployed, and the
runtime value will be “---Auto---”.

I/O auto assignment is configured in the IO Devices view. Use this view to associate application
and system objects with DI objects and scan groups.
Scan groups are contained by DI objects and help categorize devices that are associated with
them on the basis of how often their I/O points are scanned.

Validating and Editing I/O Assignments

The IO Device Mapping view is a table that displays I/O auto assignment references for application

y
and system objects that are linked to DI object scan groups. Manually configured references are
not displayed in the IO Device Mapping view, nor are attributes associated with application and

op
system objects that have not yet been assigned to a scan group. The attributes shown in this view
are determined by what is selected in the IO Devices view.
When you initially open the IO Device Mapping view after starting the IDE, the table will scroll so
the far right column is in view.
C
 Selecting a DI object in the IO Devices view lists I/O auto assignment attributes for all
objects linked to all scan groups under it.
 Selecting individual scan groups restricts the scope of the information displayed in the IO
ot

Device Mapping view to the objects that have been linked to the selected scan groups.
 Selecting individual application or system object further restricts the scope of attributes
displayed to only those associated with the selected object.
N

Note: You can select multiple items in the IO Devices view. Selected items can be at
different hierarchical levels. Selecting a subordinate object will exclude non-selected objects
within the device hierarchy, even though the parent object is selected.
o

In the IO Device Mapping view, you can view and validate I/O references for each automatically
D

generated attribute, and you can override the automatically generated I/O references. As is the
case in the IO Devices view, you do not have to check out objects to change their I/O assignments.

Using the IO Mapping View

The IO Mapping view is divided into columns, each of which displays information for an I/O
attribute that has been auto assigned.
You can change how I/O attributes are displayed by sorting, grouping, or filtering the attributes.

Validating I/O References

You can validate I/O attributes that have been auto assigned in the IO Device Mapping view. To
begin I/O reference validation, press the Validate References button.

Application Server 2017 Update 3

4-14 Module 4 – Application Objects

Writeability
This drop-down list can be set to one of four possible options: Calculated, Calculated retentive,
Object writeable, and User writeable. The following are descriptions of each of these options:
 Calculated: Permits only scrips within the same object to write to the attribute. Calculated
attributes are now saved across engine restarts. If you select Calculated for an attribute,
only scripts running on the same object can write to the attribute.
 Calculated retentive: Permits only scripts within the same object to write to the attribute.
Calculated retentive attributes are saved across engine restarts.
 Object writeable: Permits other objects to write to this attribute, in addition to being set by
scripts within the same object. Object writeable attributes are saved across engine
restarts. The category in not user writeable.
 User Writeable: Permits other users to write to this attribute, in addition to being set by
scripts and objects throughout the system. User writeable attributes are saved across
engine restarts. The can be locked during configuration. If locked, they are read only.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-15

Lab 6 – Modeling Meters

Introduction
In this lab, you will configure and use object templates that will inherit configurations from other
object templates. You will create instances of application objects from templates. In addition, for
rapid prototyping purposes, you will acquire data from the OI Simulator and monitor the attribute
data in Object Viewer.

Objectives
Upon completion of this lab you will be able to:
 Configure and use object templates
 Create instances of application objects
 Acquire data from an OI Simulator

y
 Monitor attribute data in Object Viewer

op
C
ot
N
o
D

Application Server 2017 Update 3

4-16 Module 4 – Application Objects

Create and Configure the Meter Template

First, you will use the $UserDefined object to create the $Meter template.
1. In the ArchestrA IDE, Template Toolbox, expand the Application toolset.
2. Right-click the $UserDefined template and select New | Derived Template.

y
op
C
ot
N
o

3. Name the new template $Meter.

D

Wonderware Training
 Lab 6 – Modeling Meters 4-17

4. Move the $Meter derived template object to your Training\Project template toolset.

y
Now, you will configure the $Meter template.

op
5. Double-click the $Meter template to open its configuration editor.

6. Click the Configure Wizard Options button to close the wizard option panes.
C
ot
N
o
D

Application Server 2017 Update 3

4-18 Module 4 – Application Objects

7. On the Attributes tab, click the Add button to add a new attribute.
8. Configure the new attribute as follows:

Name: PV
Data type: Float
Writeability: Object writeable

y
op
C
ot

The Float data type selection allows the object to store single-precision floating-point
numbers, when 6–7 significant digits are needed. Object writeable allows other objects to
N

write to this attribute.

9. In the Available features area, click the I/O button.
10. In the I/O area, select Read.
o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-19

11. Click the Save and Close button to close the editor.
The Check In dialog box appears.
12. In the Comment field, enter Meter.PV and click OK.
The Check In dialog box reappears with an Object 1 of 1 completed message.

y
op
13. Click Close.
C
Create Additional Templates and Instances
Now, you will derive additional templates from the $Meter template. These new templates will
ot

inherit the configuration of the $Meter template.

14. Right-click the $Meter template and select New | Derived Template.
N
o
D

15. Name the new template $Level.

Application Server 2017 Update 3

4-20 Module 4 – Application Objects

16. Repeat Steps 14 and 15 for $Temperature.

Next, you will use the Template Toolbox and the Model view, to create instances of Level and
Temperature.
17. In the Project toolset, right-click the $Level template and select New | Instance.

y
op
18. Rename the new instance L1.
C
In the Model view, the new instance appears under the Unassigned Area folder.
19. In the Model view, assign the L1 instance to the Production area.
ot
N
o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-21

20. In the Project toolset, right-click the $Temperature template and select New | Instance.
In the Model view, the new instance appears under the Unassigned Area folder.
21. Rename the new instance T1 and assign it to the Production area.

y
op
22. On the ArchestrA IDE View menu, click IO Devices.
C
ot
N
o

The IO Devices pane opens on the right side of the ArchestrA IDE.
D

Application Server 2017 Update 3

4-22 Module 4 – Application Objects

23. On the ArchestrA IDE View menu, click IO Device Mapping.

y
The IO Device Mapping pane opens in the center pane of the ArchestrA IDE at the bottom.

op
C
ot
N
o
D

24. In the IO Devices pane, expand TrainingGalaxy\Simulator\Fast.

Note the auto assignment of L1 and T1 to Simulator\Fast.

Wonderware Training
 Lab 6 – Modeling Meters 4-23

Deploy the Objects

Next, you will deploy the L1 and T1 instances.
25. In the Deployment view, expand the Production area, if necessary, and then select L1 and
T1.
Notice that they display yellow boxes, indicating that the objects need to be deployed.

y
op
C
26. Right-click the instances and select Deploy.
ot
N
o
D

Application Server 2017 Update 3

4-24 Module 4 – Application Objects

The Deploy dialog box appears. By default, the system will set the initial scan state to On
Scan as soon as the objects are deployed.

y
op
27. Click OK to accept the default settings.
When complete, the progress displays 100% completed.
C
ot
N
o
D

28. Click Close.

Wonderware Training
 Lab 6 – Modeling Meters 4-25

Notice that the yellow boxes next to the L1 and T1 have disappeared, indicating a successful
deployment.

y
op
View the Meter Data in Runtime
Now, you will return to Object Viewer to view the attribute values in runtime.
C
29. Click L1, and then right-click L1 and select View in Object Viewer.
ot
N
o
D

Application Server 2017 Update 3

4-26 Module 4 – Application Objects

30. Select L1, and then in the Simulator watch list, add the following attributes:
 PV
 PV.InputSource
31. Repeat the previous step to add the following attributes for T1:
 PV
 PV.InputSource

When the mixer is running, observe the attribute values changing in real time. There is nothing

y
wrong if the numbers are static for a few moments.
32. Expand the Value column to view the full value of the input sources.

op
C
ot

These values represent where the data is coming from for each of the attributes.
N

33. Right-click the blank area of the watch window and select Save to save the watch list.
o
D

34. Minimize Object Viewer.

Wonderware Training
 Section 3 – Change Control and Propagation 4-27

Section 3 – Change Control and Propagation

This section describes attribute locking and unlocking. It also discusses how template changes
can propagate to previously derived objects.

Locking and Unlocking Template Attributes

When you create derived templates, you can lock or unlock some or all of the attributes. Locking
an attribute prevents the attribute from being changed in derived templates or instances. You can
only lock attributes in templates.
Locking an attribute in a template specifies that its value or setting is inherited by all derived
objects, both templates and instances. Locking an attribute also makes the attribute act as a
constant during run time.

y
op
C
ot
N
o
D

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.

Application Server 2017 Update 3

4-28 Module 4 – Application Objects

Locking an Attribute
Locking an attribute prevents changes to that attribute on derived templates and instances. This
helps to establish standards in the Galaxy.
To lock a Template attribute, you select the desired Template in the ArchestrA IDE and start its
editor. Next, you enter a value in an attribute field in the object's editor, and then click 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. Save and close the
object editor.
The locked attribute in any derived templates and instances created from this template is 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
Unlocking an attribute releases the locking control only one level down.

y
op
C
ot
N
o
D

Notice that unlocking an attribute within the $Valve template releases the locking control of the
attribute within the $Inlet and $Outlet templates, otherwise known as ‘locked in me’, meaning that
they will still stay locked within the template until manually unlocked.

Wonderware Training
 Section 3 – Change Control and Propagation 4-29

However, if you unlock an attribute within a template that has instances derived from it, the
previously locked attribute is now unlocked within the instances. Hence, instances can only be
unlocked or locked in a parent object.

y
op
C
To unlock a Template attribute, you select the desired Template in the ArchestrA IDE and start its
editor. Next, you click the locking mechanism for the locked attribute in the object's editor. Some
ot

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. Save and close the object editor.
N

Locking Groups of Attributes

There are a number of places where Application Server allows you to click a single lock icon to
lock an entire group of attribute extensions. This adds efficiency, but there are times when not
o

every item in the group should be locked. You still have the option of locking the group and then
unlocking any specific extension.
D

When this occurs, the group lock icon will appear as Indeterminate . This icon indicates
different lock states for individual options in the group.

Application Server 2017 Update 3

4-30 Module 4 – Application Objects

y
op
C
ot
N
o
D

Wonderware Training
 Lab 7 – Configuring Change Control and Propagation 4-31

Lab 7 – Configuring Change Control and

Propagation

Introduction
In this lab, you will control the changes made to derived objects by locking attributes. Additionally,
you will use this feature to propagate changes from templates to existing derived objects. This
practice helps establish standards in the Galaxy, such as standards for engineering units and
scaling values.

Objectives
Upon completion of this lab, you will be able to:
 Control changes to derived objects by locking attributes

y
 Propagate changes from templates to derived objects

op
C
ot
N
o
D

Application Server 2017 Update 3

4-32 Module 4 – Application Objects

Lock the Attributes in a Template

First, you will lock attributes, which prevents changes to those attributes on derived objects. You
will then observe that the changes have been propagated down through the derivation hierarchy.
1. In the ArchestrA IDE, at the bottom-left of the window, click the Derivation tab and notice the
$UserDefined hierarchy.

y
op
C
2. Double-click the $Meter template to open its configuration editor.
3. Verify that the PV attribute is selected.
ot
N
o
D

Wonderware Training
 Lab 7 – Configuring Change Control and Propagation 4-33

4. In the I/O area, expand Advanced.

5. Check Enable I/O scaling.

6. In the Enable I/O scaling area, Maximum: Raw value field, enter 4095.0, and then click the
lock icon to lock the field.

y
op
C
7. Configure the other Enable I/O scaling parameters as follows:
ot

Minimum: Raw value: 0.0 (default) locked

Minimum: EU value: 0.0 (default) unlocked (default)
Minimum: Extended EU range: -6.0 (default) unlocked (default)
N
o
D

The EU value and Extended EU range parameters are being left unlocked so they can be set
in the derived templates.
8. Save and close the configuration editor.
9. In the Check In dialog box, Comment field, enter Locking Raw Values.

Application Server 2017 Update 3

4-34 Module 4 – Application Objects

10. Click OK.

The Check In dialog box reappears with an Object 1 of 1 completed message.
Notice the details display that the $Level and $Temperature derived templates and the L1
and T1 instances were updated. This is because the changes made to the $Meter template
were inherited by these derived templates and instances.

y
op
11. Click Close. C
Configure the Level and Temperature
Next, you will configure the attributes of the Level and Temperature templates.
ot

12. On the Derivation tab, double-click the $Level template to open its configuration editor.
13. Verify that the PV attribute is selected.
N
o
D

14. In the Description field, enter Level Indicator and press Enter.
You must press Enter or click elsewhere for the lock icon to appear.
15. Click the lock icon to the right of the field to lock the description.

Wonderware Training
 Lab 7 – Configuring Change Control and Propagation 4-35

16. On the right side of the pane, in the Eng units field, enter Gallons and press Enter, and then
lock the field.

17. In the I/O area, expand Advanced.

Notice that the Enable I/O Scaling check box is unavailable and no changes can be made to

y
it. This is because it was enabled at the $Meter level and the setting was inherited.
18. Configure the Enable I/O Scaling parameters as follows:

op
Minimum: EU value: locked
Minimum: Extended EU range: locked
C
ot
N
o

The EU value and Extended EU range parameters are now being set and locked, since there
will be no further derived templates.
D

19. Save and close the configuration editor.

20. In the Check In dialog box, Comment field, enter Locking Attribute Properties.

Application Server 2017 Update 3

4-36 Module 4 – Application Objects

21. Click OK.

The Check In dialog box reappears with an Object 1 of 1 completed message.
Notice the details display that the L1 instance was updated.

y
op
22. Click Close.
23. On the Derivation tab, double-click the $Temperature template to open its configuration
editor.
24. Verify that the PV attribute is selected.
C
ot
N
o
D

25. In the Description field, enter Temperature Indicator and press Enter.
26. Click the lock icon to the right of the field to lock the description.

Wonderware Training
 Lab 7 – Configuring Change Control and Propagation 4-37

27. On the right side of the pane, in the Eng units field, enter Deg F and press Enter.
28. Lock the field.

29. In the I/O area, expand Advanced.

30. Configure the Enable I/O Scaling parameters as follows:

Maximum: EU value: 250.0 locked

Maximum: Extended EU range: 255.0 locked

y
op
C
ot

31. Save and close the configuration editor.

N

32. In the Check In dialog box, Comment field, enter Locking Attribute Properties.
33. Click OK.
The Check In dialog box reappears with an Object 1 of 1 completed message.
o

Notice the details display that the T1 instance was updated.

D

34. Click Close.

Application Server 2017 Update 3

4-38 Module 4 – Application Objects

Some Temperature indicators may have different ranges, but the desired default ranges are 250
for the Maximum: EU value and 255 for the Maximum: Extended EU range. The initial edit
pushed the default when you locked Maximum: EU value and Maximum: Extended EU range,
but now they need to be unlocked to allow changes.
35. On the Derivation tab, double-click the $Temperature template to open its configuration
editor.
36. In the I/O area, expand Advanced.
37. Configure the Enable I/O Scaling parameters as follows:

Maximum: EU value: unlocked

Maximum: Extended EU range: unlocked

y
op
C
38. Save and close the configuration editor.
39. In the Check In dialog box, Comment field, enter Unlocking Attribute Properties.
ot

40. Click OK.

The Check In dialog box reappears with an Object 1 of 1 completed message.
N

Notice the details display that the T1 instance was updated.

o
D

41. Click Close.

Wonderware Training
 Lab 7 – Configuring Change Control and Propagation 4-39

On the Derivation tab, notice that L1 and T1 need to be deployed.

42. Select L1 and T1, and then right-click and select Deploy.
43. In the Deploy dialog box, click OK to accept the default settings.
When complete, the progress displays 100% completed.
44. Click Close.
Now, you will view the data in Object Viewer.
45. Click L1, and the right-click L1 and select View in Object Viewer.
Notice the new values.

y
op
The Simulator provides raw values within a fixed EU range of 0 – 20. L1 and T1 have EU
ranges of 0 to 4095, so the values do not match the expected EU values. This will be
addressed in a subsequent lab.
46. Minimize Object Viewer.
C
ot
N
o
D

Application Server 2017 Update 3

4-40 Module 4 – Application Objects

y
op
C
ot
N
o
D

Wonderware Training
 Section 4 – Containment 4-41

Section 4 – Containment

This section describes containment with templates and application objects, and explains different
modeling approaches. It also discusses the naming conventions of contained objects.

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:
 Tagname

y
 Contained Name
Hierarchical Name

op


Name Description
Tagname The unique name of the individual object. For example, Valve1.
C
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
ot

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

For example, if:

“Mixer1” contains Tank1 (also known within Mixer1 by its contained name “Tank”).
“Tank1” contains Valve1 (also known within Tank1 by its contained name “Outlet”).
o

Valve1 could be referred to as:

“Valve1”
D

“Tank1.Outlet”
“Mixer1.Tank.Outlet”

For example, an instance of a $Mixer is named Mixer_001. An instance of $Valve called

Valve_001 is contained within the instance of $Mixer.
Change the contained name of Valve_001 to Inlet1. Now Valve_001 can also be referred to by its
hierarchical name Mixer_001.Inlet1. The name of the contained object can be changed, though,
within the scope of the hierarchy.

Application Server 2017 Update 3

4-42 Module 4 – Application Objects

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.

You can nest templates up 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.
An example of a containment hierarchy is a mixer that contains the following objects:

y
 2 Inlet Valve
 Agitator

op
 Outlet

C
ot
N
o
D

Wonderware Training
 Section 4 – Containment 4-43

To enable referencing and flexibility within scripting, these objects can be referenced in several
different ways. Each object has a unique Tagname, such as:
 Agitator = Agitator_001
 Inlet1 = Inlet1_001
 Inlet2 = Inlet2_001
 Outlet = Outlet_001

y
op
C
ot
N
o
D

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 Mixer_001, the contained names are:
 Mixer_001.Agitator
 Mixer_001.Inlet1
 Mixer_001.Inlet2
 Mixer_001.Outlet
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.Inlet1: Allows a script running in any of the children instances to reference
another child instance named Inlet1 that belongs to the same parent.

Application Server 2017 Update 3

4-44 Module 4 – Application Objects

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

To rename an object's contained name, select the object in an Application view: Model,
Deployment, or Derivation. On the Edit menu, click Rename Contained Name. Enter a new
contained name. All IDEs connected to the Galaxy show the object's new contained name. You

y
can also right-click an object and select Rename Contained Name.

op
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:

C
Non-contained instances show their tagnames
 Contained instances show their tagnames and hierarchical names
 Non-contained templates show their object name
ot

 Contained templates show their hierarchical name

Containment of instances is limited to Areas containing other Areas and AppObjects containing
other AppObjects.
N

Renaming can be done on an instance's tagname and contained name. A template only has a
template name.
It is also important to note that adding or removing an element to/from a container at the template
o

level, does not affect previously created instances.

D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-45

Lab 8 – Modeling the Mixer

Introduction
In this lab, you will configure analog and discrete attributes in a series of contained $UserDefined
objects to model a mixer device. You will also use the I/O Binding to map attributes and build
references. You will use the Simulator object you created in a previous lab to provide the
connection to live values from the Simulator. These are only simulated values for rapid
prototyping purposes, not actual simulated process data.

Objectives
Upon completion of this lab, you will be able to:
 Create a containment relationship using templates
 Create instances of contained objects

y
 View the attribute data of contained objects in Object Viewer
 Use the Area model to handle I/O assignments

op
C
ot
N
o
D

Application Server 2017 Update 3

4-46 Module 4 – Application Objects

Create the Mixer Template

First, you will configure the mixer and valve templates.
1. In the ArchestrA IDE, Template Toolbox, Application toolset, right-click the $UserDefined
template and select New | Derived Template.

y
op
C
2. Rename the derived template $Mixer.
ot
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-47

3. Drag the $Mixer template to the Training\Project toolset.

y
op
4. Select the following derived template objects from the previous lab and move them to the
$Mixer template to create a contained mixer object:
C
 $Level
 $Temperature
ot
N
o
D

Application Server 2017 Update 3

4-48 Module 4 – Application Objects

5. Repeat Steps 1 to 3 for a template named $Valve.

y
op
6. Double-click the $Valve template to open its configuration editor.
C
7. On the Attributes tab, click the Add button and name the new attribute OLS, and then
press Enter.
ot

8. In the Description field, enter Open Limit Switch and press Enter, and then lock the field.
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-49

9. With the OLS attribute selected, configure the attribute parameters as follows
(leave all other attributes as default):

Data type: Boolean (default)

Writeability: Object writeable
‘False’ label: Closed and locked
‘True’ label: Open and locked
I/O selected
I/O area
Read: selected

y
op
C
ot
N

10. Click the Add button and name the new attribute CMD, and then press Enter.
o

11. In the Description field, enter Valve Command and press Enter, and then lock the field.
D

Application Server 2017 Update 3

4-50 Module 4 – Application Objects

12. With the CMD attribute selected, configure the attribute parameters as follows
(leave all other attributes as default):

Data type: Boolean (default)

Writeability: User writeable
‘False’ label: Close and locked
‘True’ label: Open (default) and locked
I/O selected
I/O area
Write: selected

y
op
C
ot
N
o

13. Save and close, and then check in the object with an appropriate comment.
D

The Check In dialog box reappears with an Object 1 of 1 completed message.

14. Click Close.

Wonderware Training
 Lab 8 – Modeling the Mixer 4-51

15. Using the $Valve template, create three new derived templates named:
 $Inlet1
 $Inlet2
 $Outlet

16. Contain the templates in $Mixer.

y
op
C
ot

Create the Motor Template

N

Now, you will create the motor template that will be used later to create the agitator and pumps.
17. Create another $UserDefined derived template named $Motor.
18. Move the new template to the Training\Project toolset.
o
D

Application Server 2017 Update 3

4-52 Module 4 – Application Objects

19. Open the $Motor template and create an attribute named CMD.
20. In the Description field, enter Command and press Enter, but leave it unlocked.
21. Configure the attribute as follows:
Attribute Data
Writeability ‘False’ label ‘True’ label I/O
Name Type
CMD Boolean User writeable Stop locked Start locked Read/Write
(default) (default) (default)

y
op
C
ot
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-53

22. Add another attribute named PV.

23. In the Description field, enter State, and leave it unlocked.
24. Configure the attribute as follows:
Attribute Data
Writeability ‘False’ label ‘True’ label I/O
Name Type
PV Boolean Object writeable Stopped locked Running locked Read
(default)

y
op
C
ot
N

25. Save and close, and then check in the object with an appropriate comment.
o

The Check In dialog box reappears with an Object 1 of 1 completed message.

D

26. Click Close.

Application Server 2017 Update 3

4-54 Module 4 – Application Objects

Create the Agitator Template

Now, you will create the $Agitator template and add attributes to the agitator to control and
monitor the agitator speed.
27. Using the $Motor template, create a derived template named $Agitator.

y
28. Open the $Agitator configuration editor.
29. For the CMD attribute, change the Description to Agitator Command and lock the field.

op
C
30. For the PV attribute, change the Description to Agitator State and lock the field.
ot
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-55

31. Create two new attributes and configure as follows:

Data
Name Description Writeability Eng units I/O
Type
Speed.PV Agitator Speed locked Float Object writeable RPM locked Read
(default)
Speed.SP Agitator Speed Setpoint locked Float User writeable RPM locked Write
(default) (default)

y
op
C
ot
N
o
D

Application Server 2017 Update 3

4-56 Module 4 – Application Objects

All the attributes are now visible in the attributes list.

y
32. Save and close, and then check in the object with an appropriate comment.

op
Create the Pump Templates C
Now, you will derive templates from the motor template, which you will use to create pumps.
33. Using the $Motor template, create two new derived templates named:
 $Pump1
ot

 $Pump2
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-57

34. Open the $Pump1 configuration editor.

35. For the CMD attribute, change the Description to Pump 1 Command and lock the field.

36. For the PV attribute, change the Description to Pump 1 State and lock the field.

37. Save and close, and then check in the object with an appropriate comment.

y
38. Open the $Pump2 configuration editor.
39. For the CMD attribute, change the Description to Pump 2 Command and lock the field.

op
C
40. For the PV attribute, change the Description to Pump 2 State and lock the field.
ot
N

41. Save and close, and then check in the object with an appropriate comment.
o
D

Application Server 2017 Update 3

4-58 Module 4 – Application Objects

Create a Mixer Instance

Next, you will contain the templates that make up the mixer template. Then, you will create a mixer
instance that also contains all the instances that make up the mixer.
42. Select the following derived template objects and move them to the $Mixer template to
contain them in the mixer object.
 $Agitator
 $Pump1
 $Pump2

y
op
C
43. Right-click $Mixer and select New | Instance.
ot
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-59

44. Rename the new instance Mixer100.

45. In the Deployment view, assign Mixer100 to Line1.

y
op
Apply I/O Binding
Now, you will assign the instances to their I/O data source to autobind their I/O references to their
proper data points. You will first have to undeploy the objects because you cannot change the
C
autobind assignment of an object while the object being assigned is deployed.
46. Select Line1 and Line2, and then right-click and select Undeploy.
ot
N
o
D

47. The Undeploy dialog box appears.

48. Leave the default options and click OK.

Application Server 2017 Update 3

4-60 Module 4 – Application Objects

When complete, the progress displays 100% completed.

49. Click Close.

y
50. Expand Mixer100.

op
Notice that all the instances you created to build the mixer have a warning icon, indicating they
do not have an I/O connection.
C
ot
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-61

51. Collapse Mixer100 view, and then select Line1 and Line2.
52. Drag Line1 and Line2 to the IO Devices pane to Simulator\Fast.
This assignment is to autobind their I/O references to their proper data points.

y
op
Notice that the warning overlay icons have disappeared. This is due to the autobinding
feature.
Now, you will verify the references created using I/O Binding.
C
53. In the Deployment view, expand Mixer100.
54. Deploy Line1, Mixer100 and all its contained objects, and Line2.
ot
N
o
D

Application Server 2017 Update 3

4-62 Module 4 – Application Objects

The Deploy dialog box appears.

y
op
55. Leave the default options and click OK.
When complete, the progress displays 100% completed.
C
ot
N
o
D

56. Click Close.

Wonderware Training
 Lab 8 – Modeling the Mixer 4-63

The Deployment view now displays that Line1, Line2, and all objects in the containment
relationship have been deployed.

y
op
57. Click Mixer100, and then right-click Mixer100 and select View in Object Viewer.
58. Load the watch list you saved earlier, if necessary.
C
59. Add a new watch window and rename the tab Mixer100.
60. Add the following attributes to the watch window:
 Level_001.PV
ot

 Temperature_001.PV
 Agitator_001.CMD
 Agitator_001.PV.Msg
N

 Agitator_001.Speed.PV
 Agitator_001.Speed.SP
 Inlet and Outlet CMDs and OLS.Msgs
o

 Pump CMDs and PV.Msgs

D

Application Server 2017 Update 3

4-64 Module 4 – Application Objects

As this is all data from the Simulator data source, the data is not interactive and changing any
value will have no impact.
61. Save the watch list.
62. Minimize Object Viewer.

y
op
C
ot
N
o
D

Wonderware Training
 y
op
Module 5 – Device Integration
C
Section 1 – Device Integration Servers 5-3
ot

Lab 9 – Configuring the OI Server 5-7

Section 2 – Device Integration Objects 5-15
N

Lab 10 – Configuring the Device Integration Object 5-21

Section 3 – Connecting Application Objects to Field Data 5-29
o

Lab 11 – Connecting the Mixer to the Field 5-31

D

Section 4 – Device Integration Redundancy 5-37

Lab 12 – Configuring the Redundant DI Object 5-41
5-2 Module 5 – Device Integration

Module Objectives
 Introduce OI Servers
 Describe the DDESuiteLinkClient
 Explain attribute referencing and I/O referencing
 Explain autobind capabilities of object attributes
 Configure redundancy for DI Objects

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Device Integration Servers 5-3

Section 1 – Device Integration Servers

This section describes available DI servers, discusses OI servers, and explains the configuration
of an OI Server to a Controller.

Communication to Field Devices

Connectivity from the Galaxy to field devices is needed to supervise and control processes and
equipment; for this, application objects representing equipment in the field need to communicate
with controllers, such as PLCs and RTUs. These concepts extend to any automation object in the
Galaxy.
The communication between automation objects in the Galaxy and the controllers is done through
device integration objects that reside in the Galaxy and field protocol-specific drivers external to
the Galaxy, such as OI, legacy IO, and OPC servers.

y
op
C
The communication between all these components is done through different protocols:
ot

 Communication between automation objects in the Galaxy, such as the communication

between an application object (AO) and a device integration object (DIO), is managed by
ArchestrA
N

 Communication between device integration objects in the Galaxy and external drivers
(Windows applications or services) is accomplished by the DDE, SuiteLink, or OPC
protocols
 The drivers (for example, OI Servers) communicate with the controllers through the
o

device-specific protocol, such as Modbus TCP or DH+.

D

OI Servers
The OI Server Manager is a part of the SMC suite of utilities. It enables the configuration,
diagnosis, activation, or deactivation of a local OI Server or a remote OI Server located on a
different node from the OI Server Manager.
You can open multiple instances of the OI Server Manager at the same time; however, you can
only use the first instance to create device hierarchies and configure an OI Server. In all other
instances of the OI Server Manager hierarchy and configuration settings are set to read-only.

Application Server 2017 Update 3

5-4 Module 5 – Device Integration

Navigating the OI Server Manager

Within the SMC the OI Server Manager has a hierarchical tree of items named the Console Tree,
and a configuration pane named the Details pane. The configuration pane on the right, also
named a faceplate, will vary depending on the type of OI Server being configured. The OI Server
Manager has one or more node groups in its hierarchy and each node group comprises one or
more nodes. A node represents a computer that hosts at least one OI Server.

y
op
C
ot

Server Groups
N

A server group comprises one or more server instances that use the same OI Server protocol,
such as a Modbus-MBTCP. When you install a specific OI Server on a computer, a server group
and default server instance are automatically created for that OI Server in the OI Server Manager.
Since there is a limit of one server group per OI Server per computer node, that server group
o

effectively is the OI Server.

Where the server group appears in the OI Server Manager depends on what type of OI Server it is
D

for. For the purpose of this course, the MBTCP is optimized and is contained in the Operations
Integration Supervisory Servers folder.

Server Instances
Each server instance has its own configuration and diagnostics, can be activated and deactivated
separate from all other server instances, and appears as a separate application to external clients.
When you install an OI Server on a computer, a server group and a default server instance are
automatically created for that OI Server in the OI Server Manager. The name of the default server
instance is based on the short name of the OI Server installed. For example, for the Wonderware
Simulation OI Server, the default server instance is named OI.SIM.1. All server instance names
follow this basic format.
The middle part of a server instance name becomes the application name that external clients will
use to access OI Server data. For example, if a server instance is named OI.SIM_0001.1, the

Wonderware Training
 Section 1 – Device Integration Servers 5-5

corresponding application name will be SIM_0001. This middle part of the server instance name is
used in the InTouch runtime client, WindowViewer, to connect to this data source.

Configuring the OI Server

The Configuration node is used to configure an OI Server for runtime. The Configuration node has
two functions. First, it has several global parameters that can be configured to adjust the OI Server
runtime performance. These parameters apply to all server instances in the server group.
Second, the Configuration node has its own hierarchy of configurable objects. Each object
represents a physical device, such as a channel, port, bridge, or PLC. Some OI Servers have two
levels of objects in the hierarchy. For example, a parent object may represent a network channel,
port, or bridge, while a child object may represent an individual device on that network.

Configuring Global Parameters

Each OI Server has a unique set of parameters that you can configure for an environment. These
parameters are unique to each type of field device, such as a PLC. For descriptions of these

y
configuration parameters see your OI Server-specific documentation.
Using the OI Server Manager, you can also configure a set of common or global parameters for

op
each OI Server. For example, the IP address of the device you are connecting to.

Configuring Device Groups C

Device groups are labels used by client applications when accessing the OI Server.
The Device Group Update Interval determines how often the OI Server polls the device and sends
data to the client application. If this is not specified, all unnamed device groups have an update
ot

interval of 1,000 milliseconds. If you configure multiple device groups with different update
intervals, the client application can receive data at various intervals.
Smaller update intervals quicken the turnaround for data changes and a increase overhead
N

because a large amount of data is being transmitted between the device and the OI Server. Large
update intervals slow turnaround for data changes.

Configuring Device Items

o

Defining device items provides a more user-friendly way to name data in the device. Defining
device items is optional, unless you will be taking advantage of the autobind capabilities of object
D

attributes. Use device items to access data in the OI Server and devices connected to the OI
Server. Device items consist of two pieces: a name and an item reference. After it is defined in the
OI Server, you can access it in the client program either through item name or the item reference.
The device Item name is an alternative name for the item reference. It is an alias, or a label, for the
data in the device. You can use this label instead of the item reference when you create the client
application.
The item reference identifies data in the device. The item reference is a PLC memory reference.
Each device’s memory reference can have a different format. For more information, see your OI
Server specific documentation. The actual item reference can be entered as the device Item
name. In this case, the item reference value can be left empty.
You can add device items while the OI Server is active, and these new items are immediately
available to client applications.
You can make changes to items while the OI Server is active. Changes take effect immediately.
OPC clients that are already connected to the item are not affected until they release and re-
acquire the item.

Application Server 2017 Update 3

5-6 Module 5 – Device Integration

Activating the OI Server

After the configuration of the OI Server is complete, and the changes have been saved, the OI
Server can then be activated. There are several modes of activation. These modes are Auto
Service, Manual Service, and Not a Service.
Running the OI Server as a service allows the OI Server to start automatically when the operating
system starts, without the presence of a human user to log in. This is a good mode for disaster
recovery or following server restarts. The final step is to perform the activation which runs the OI
Server. After an OI Server runs as an auto or manual service, it stays running until stopped in the
OI Server Manager or the computer shuts down.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 9 – Configuring the OI Server 5-7

Lab 9 – Configuring the OI Server

Introduction
In this lab, you will use the Operations Integration Server Manager in the SMC. You will configure
the Modbus OI Server to connect to the PLC simulator that provides PLC data throughout the
remainder of this training course. As a part of this configuration, you will import aliases for the
device items through a .csv file.

Objectives
Upon completion of this lab, you will be able to:
 Configure the Operations Integration Server Manager using the SMC
 Configure an OI Server using the SMC
 Activate and deactivate an OI Server using the SMC

y
op
C
ot
N
o
D

Application Server 2017 Update 3

5-8 Module 5 – Device Integration

Launch and Configure the OI Server

First, you will configure the Operations Integration Server Manager on your development
computer. You will use the SMC to do this configuration, which will allow you to connect to the PLC
simulator that provides PLC data.
1. In the SMC, if necessary, expand Operations Integration Server Manager, and then expand
TrainingGalaxy\ProdPlatform\OI.MBTCP.1 and select Configuration.
Notice the red error icon next to OI.MBTCP.1, which indicates a configuration error.

y
op
C
ot

2. Right-click Configuration and select Add TCPIP_PORT Connection.

N
o
D

Wonderware Training
 Lab 9 – Configuring the OI Server 5-9

3. Rename the TCPIP_PORT Connection to PORT1.

y
op
C
4. Right-click PORT1 and select Add ModbusPLC Connection.
ot
N
o
D

Application Server 2017 Update 3

5-10 Module 5 – Device Integration

5. Rename the ModbusPLC Connection to PLC1.

With PLC1 selected, you will see the parameters for PLC1 in the right pane.

y
op
C
6. In the Network address field, enter the node name of the computer where the PLC simulation
ot

is running (your instructor will provide this name).

Note: This will be a remote computer if you are using a two-node architecture, or your
development computer if you are using a single-node architecture.
N
o
D

Wonderware Training
 Lab 9 – Configuring the OI Server 5-11

7. Click the Device Groups tab.

8. Right-click inside the table and select Add.

y
9. Rename the topic to Topic1.

op
C
ot

10. Click the Device Items tab.

11. Right-click inside the table and select Import.
N
o
D

Application Server 2017 Update 3

5-12 Module 5 – Device Integration

12. Navigate to the C:\Training folder and select PLCItemList.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 9 – Configuring the OI Server 5-13

13. Click Open.

The list will be populated from the imported .csv file.

y
op
C
ot
N
o
D

14. Click the Save button in the top-right corner.

Application Server 2017 Update 3

5-14 Module 5 – Device Integration

15. Right-click OI.MBTCP.1 and select Activate.

Notice that the red error icon next to OI.MBTCP.1 has changed to a green check mark when
the OI Server is running, and Diagnostics now appears.

y
op
C
ot
N

16. Minimize the SMC.

o
D

Wonderware Training
 Section 2 – Device Integration Objects 5-15

Section 2 – Device Integration Objects

This section describes DI objects, explains the configuration of a DI object to an OI Server, and
discusses how to monitor the connectivity of a DI object in Object Viewer.

Device Integration Products

Device Integration Products separate the application code (the Galaxy) from device
communication (the driver) allowing both to be independently configured, updated, and managed.
Device Integration Products are comprised of:
 Device Integration Objects that reside in the Galaxy and provide the connection to the
drivers; a device integration object can communicate with one, and only one driver
 Device Integration Servers (or "drivers") that are external to the Galaxy and provide the
communication to the controllers; a device integration server can communicate with one
or more controllers

y
Application Server includes the following device integration objects for communication with the
drivers:

op
 $DDESuiteLinkClient
 $OPCClient
These device integration objects can be deployed to any platform in the Galaxy as long as they
have network access to the drivers. They support the following client protocols:
C
Product DDE SuiteLink OPC
$DDESuiteLinkClient  
ot

$OPCClient 
N

Note: The $OPCClient object supplied with Application Server supports the OPC DA (OPC
Classic) standard. It is possible to add client support for OPC UA to the Galaxy by means of the
ArchestrA Service Bus. Visit the Wonderware Knowledge and Support Center for more
information.
o

Each Device Integration Server speaks a particular device-specific protocol; for example, to
D

communicate with a PLC that speaks the Modbus TCP protocol, you can use Modbus TCP OI
Server. Multiple drivers might be necessary if communicating with different types of controllers.
Device Integration Servers are categorized as:
 OI Servers and other third-party OI Servers created with toolkits
 Legacy IO Servers and other third-party IO Server created with toolkits
 Third-party OPC Servers with support for OPC DA or OPC UA, or both.

Application Server 2017 Update 3

5-16 Module 5 – Device Integration

These drivers are installed in the computers that have direct access to the controllers (Device
Integration Servers computer role). They support the following protocols for communication with
the clients:

Product DDE SuiteLink OPC

OI Server   
IO Server (legacy)  
OPC Server (third-party) 

Note: For OPC, DA Servers support the OPC DA standard (OPC Classic).

Application Communication Protocols

Communication between device integration objects and device integration servers is achieved by
way of an application protocol. Application protocols implement a client-server relationship

y
between two concurrently running applications. The server application accepts requests from and
provides data to any client application. Some applications can simultaneously be both a client and

op
a server.
The supported application protocols are:
 DDE (Dynamic Data Exchange) - a Microsoft communications protocol that lets
applications send and receive data and instructions to and from each other. DDE
C
communications between Wonderware applications are optimized by packaging multiple
Wonderware-specific DDE messages into a single Microsoft DDE message. Application
Server supports DDE communications through the $DDESuiteLinkClient object.
ot

 SuiteLink is a TCP/IP-based protocol designed by Wonderware specifically for industrial

applications. It provides data integrity, high throughput, and simple diagnostic procedures.
Application Server supports SuiteLink communication through the $DDESuiteLinkClient
object.
N

 OPC is an interoperability standard for the exchange of data between devices; these
devices can be software or hardware, or both. While not technically a "protocol", it is
commonly referred to as such for convenience. Application Server supports OPC
o

communications. There are two OPC standards: OPC DA (OPC Classic) and OPC UA;
Application Server supports OPC DA through the $OPCClient object and OPC UA through
the ArchestrA Service Bus (for more information on OPC UA support, visit the
D

Wonderware Knowledge and Support Center).

Important: Communication using the DDE protocol can only be done on the same computer.
NetDDE, the version of the protocol that allows DDE communications across computers on a
network, has been discontinued and it is not possible in the latest Windows operating Systems.

These communication protocols allow for time and quality propagation. If the server passes a
value, time, and quality (VTQ) triplet to the client, the timestamp and quality associated with the
value is updated in the corresponding data point in the client. In the Galaxy, the device integration
object will receive the VTQ triplet from the driver and the attribute of the requesting application
object will be updated accordingly.

Wonderware Training
 Section 2 – Device Integration Objects 5-17

When using these protocols for real-time communications, the client application needs to open a
communication channel with the server application through which items can be requested. This
channel is defined by three parameters:
 Node – Name of the computer where the server application is running. This parameter
can be usually omitted, if the client and server are running on the same computer.
 Application – Name of the server application.
 For the DDE and SuiteLink protocols, it is the name of the server's executable file
without the file extension; for example, the OI Server for Modbus TCP executable file
name is dasmbtcp.exe, so for this parameter only dasmbtcp will be used.
 For the OPC protocol, it is the registered name of the server. The name varies
according to the type; for example, the OI Server for Modbus TCP registered name for
OPC is ArchestrA.DASMBTCP.3.
 Device Group – The sub-group of items to be accessed on a common update interval.
 For the DDE and SuiteLink protocols, it is a server-defined sub-group of items called
Topic. The update interval is specified in the server.
 For the OPC protocol, it is a client-defined subscription request called Scan Group

y
that includes the update interval.

op
I/O Referencing from Automation Objects
The real-time communication channel opened between the client and the server using one of the
DDE, SuiteLink, or OPC protocols allows for the request of individual data items.
C
In the context of device integration products, the client application is a device integration object
and the server application is a device integration server connected to a controller. The data items
are the data points within the controller namespace; for example, the register addresses in a PLC
ot

or their corresponding mnemonic name.

Within the Galaxy, items from a controller will be requested through the corresponding device
integration object. As any other automation object in the Galaxy, data is provided through
N

attributes by using the following convention: <object name>.<attribute name>. In the case of
device integration objects, attributes that represent I/O points in the field are generated
dynamically per the device group (communication channel) and the data item (controller I/O data
point) requested; the attribute name becomes a compound of these two pieces:
o

<di object name>.<device group name>.<item name>

The item name can be customized through the device integration objects to accommodate any
D

necessary naming conventions. Both, device integration objects and device integration servers
allow adding a list of aliases for the item names.

Note: Naming conventions for item names are important for automatic I/O binding to work.

Application Server 2017 Update 3

5-18 Module 5 – Device Integration

The DDESuiteLinkClient Object

The DDESuiteLinkClient object allows real-time access to any DDE or SuiteLink server
application, including OI Servers and legacy IO Servers. There is a one-to-one relationship
between an instance of the $DDESuiteLinkClient object and a running server application; to
reference data points in more than one server application, you must configure and deploy more
than one instance of the $DDESuiteLinkClient object.

The main characteristics of the DDESuiteLinkClient object are:

 Support for multiple topics which allows one instance of the object to access multiple

y
controllers connected to the same device integration server
 Allows definition of aliases for item names; this is done on a per topic basis

op
 The rate at which the data items are updated depends on how the topics are configured
within the device integration server
 Support for advanced communication management to address network traffic and other
resources
C
Each DDESuiteLinkClient instance created must be configured with the Server name; the name of
the server application the object will connect to. If the server is located on a different computer, the
Server node must also be configured; leaving this field empty will have the object look for the
ot

server on the same computer the object is deployed.

N
o
D

By default, the DDESuiteLinkClient object will communicate with the server using the SuiteLink
Communication protocol; if DDE is to be used, ensure this is configured accordingly.

Wonderware Training
 Section 2 – Device Integration Objects 5-19

At least one Topic must also be configured for the DDESuiteLinkClient object to establish a
communication channel with the server application. The topic name(s) must match the name(s) of
the topic(s) in the server application.

Aliases list for the data items can be loaded into the DDESuiteLinkClient object as Associated
attributes for each topic. Adding aliases for data items provide browsing capabilities within the
ArchestrA IDE when configuring attribute references manually.

y
op
The OPCClient Object
The OPCClient object allows real-time access to any OPC server that complies with the OPC OI
standard (OPC Classic), including OI Servers and third-party OPC Servers. There is a one-to-one
relationship between an instance of the $OPCClient object and a running server application; to
C
reference data points in more than one server application, you must configure and deploy more
than one instance of the $OPCClient object (for information on connectivity with OPC UA servers
visit the Wonderware Knowledge and Support Center).
ot
N
o

The main characteristics of the OPCClient object are:

D

 Support for multiple scan groups which allows one instance of the object to access items
from controllers connected to the device integration server at different update intervals
 Support for read and write transactions through blocks
 Allows definition of aliases for item names; this is done on a per scan group or block basis,
or both
 Support for advanced communication management to address network traffic and other
resources

Application Server 2017 Update 3

5-20 Module 5 – Device Integration

Each OPCClient instance created must be configured with the Server name; the name of the OPC
server application the object will connect to. If the server is located on a different computer, the
Server node must also be configured; leaving this field empty will have the object look for the
server on the same computer the object is deployed.

At least one Scan Group must also be configured for the OPCClient object to establish a
communication channel with the server application.

y
op
C
Aliases list for the data items can be loaded into the OPCClient object as Associated attributes for
each scan group or block. Adding aliases for data items provide browsing capabilities within the
ArchestrA IDE when configuring attribute references manually.
ot
N
o
D

Wonderware Training
 Lab 10 – Configuring the Device Integration Object 5-21

Lab 10 – Configuring the Device Integration

Object

Introduction
In this lab, you will configure an instance of the $gDDESuiteLinkClient template to connect to the
OI Server you configured in the previous lab, using the SuiteLink protocol. You will then use Object
Viewer to monitor the connection status of the instance in runtime.

Objectives
Upon completion of this lab, you will be able to:
 Configure a device integration object
 Monitor the connection status of a device integration object

y
op
C
ot
N
o
D

Application Server 2017 Update 3

5-22 Module 5 – Device Integration

Create a Connection to a Field Device

First, you will create an instance of the $gDDESuiteLinkClient template and configure it to
connect to the OI Server you configured in the previous lab.
1. In the ArchestrA IDE, Template Toolbox, Training\Global toolset, right-click
$gDDESuiteLinkClient and create a new instance.

y
op
C
ot

2. In the Deployment view, rename the instance ProdPLC.

N
o
D

3. Double-click ProdPLC to open its configuration editor.

Wonderware Training
 Lab 10 – Configuring the Device Integration Object 5-23

4. On the General tab, configure the instance as follows:

Server node: <Instructor will provide>

Server name: MBTCP

The Server name shown in this example is for the Modbus simulator used in the training
rooms. This will be different for the data source in your plant.

y
op
5. Click the Topic tab.

6. In the Available topics section, click the ScanGroupList button to add a topic.
7. In the Topic field, enter Topic1 and press Enter.
C
ot
N
o

8. Save and close, and then check in the object with an appropriate comment.
D

Application Server 2017 Update 3

5-24 Module 5 – Device Integration

9. In the Model view, assign the ProdPLC instance to the ControlSystem area.

y
op
10. In the Deployment view, assign the ProdPLC instance to AppEngine1.
C
ot
N
o
D

Wonderware Training
 Lab 10 – Configuring the Device Integration Object 5-25

11. Deploy ProdPLC.

y
op
12. In the Deploy dialog box, click OK to accept the default settings.
When complete, the progress displays 100% completed.
13. Click Close.
C
View the Attributes in Runtime
ot

Now, you will return to Object Viewer to view the attribute values in runtime.
14. In the Deployment view, right-click ProdPLC and select View in Object Viewer.
N

15. Add a new watch window and rename it ProdPLC.

16. Add the following attributes to the watch window:
 ConnectionStatus
o

 Reconnect
 ScanState
D

 ScanStateCmd

The ConnectionStatus attribute displays the communication status between the topics
configured in the device integration object and the topics in the Device Integration Server.
The Reconnect attribute, when set to true, will attempt to reconnect to the Device Integration
Server.

Application Server 2017 Update 3

5-26 Module 5 – Device Integration

17. Add the ScanGroupList attribute to the watch window.

The Array for ProdPLC.ATTRIBUTE(ScanGroupList) dialog box appears.
This appears because ScanGroupList is an array and requires an index to be entered.
You will now configure the array to display the entire array dimension.
18. In the Enter an array index field, enter -1.

y
19. Click OK.

op
The ScanGroupList is added to the watch window.

C
ot

20. In the Attribute Reference field, enter ProdPLC.Topic1.$Sys$Status and click Go.
N
o
D

Wonderware Training
 Lab 10 – Configuring the Device Integration Object 5-27

The Attribute dialog box appears with the Attribute Reference to display in the watch
window automatically selected.

21. Click OK.

y
The ProdPLC.Topic1.$Sys$Status attribute reference is added to the watch window.

op
C
ot

The $Sys$Status item for the Topic1 scan group reports the communication status between
the OI Server and the PLC associated with the scan group.
22. Save the watch list.
N

23. Minimize Object Viewer.

o
D

Application Server 2017 Update 3

5-28 Module 5 – Device Integration

y
op
C
ot
N
o
D

Wonderware Training
 Section 3 – Connecting Application Objects to Field Data 5-29

Section 3 – Connecting Application Objects to Field Data

This section describes how to change the data source for objects using the autobind capabilities
of application objects.

You can enhance and extend an object by using features, attributes, scripts, and graphics. You
can add scripts on the Scripts page of the Object Editor. You can add graphics on the Graphics
page of the Object Editor.

Using the I/O Feature

The I/O feature allows you to configure all aspects of data input and output for an attribute.
You can configure I/O type and you can specify input sources and output destinations. The I/O
types you can specify are:
 Read (Input)
Read/Write (InputOutput)

y


 Write (Output)

op
You can also configure advanced properties. The attribute’s data type and I/O type determine
what Advanced I/O properties are available.

Using I/O Auto Assignment

C
Instead of configuring I/O references manually, or writing scripts to set them at runtime, you can
use I/O auto assignment. Manual configuration of I/O references can be time consuming. Scripting
ot

these references eliminates the issues of manual configuration, but can significantly increase the
time needed for deploying objects. With I/O auto assignment, you do not need to check out
individual objects to configure I/O references, and you do not experience the runtime penalties
associated with scripting.
N

Note: Note: I/O auto assignment is the default setting for application and other system objects,
such as area objects. Device Integration (DI) Objects must be manually configured.
o

When you add input or output attributes to an area or application object in the Attributes tab of the
Object Editor, the default setting prepares these attributes for I/O automatic assignment. The auto
D

assignment reference appears in the I/O section of the Attributes tab if you have enabled the I/O
attribute feature. The default string for an input reference is:
<IODevice>.[ObjectName].[AttributeName].InputSource
where [ObjectName] is the hierarchical name of the application or system object, and
[AttributeName] is the name of the attribute.
The default string for an output reference is:
<IODevice>.[ObjectName].[AttributeName].OutputDest
The string <IODevice> is a placeholder that indicates the I/O reference will be built automatically.
The reference is created when you link the object to a scan group and DI object, without the need
to manually enter or script the reference.
The following is an example of an I/O reference string before the object has been assigned to a
scan group and DI object:
<IODevice>.Mixer.Tank.Inlet.InputSource

Application Server 2017 Update 3

5-30 Module 5 – Device Integration

Once you assign the object to a scan group, the reference resolves to include the assigned Device
Integration (DI) object and scan group.
For example, assigning the object to the scan group "Fast" under DI object "OPC001" will change
the reference to:
OPC001.Fast.Mixer.Tank.Inlet.InputSource

Important: Do not lock InputSource or OutputDest attributes when using I/O auto assignment. If
either InputSource or OutputDest attributes, or both, are locked in the parent template, the
attributes cannot be updated with the resolved reference when the object is deployed, and the
runtime value will be "---Auto---".

I/O auto assignment is configured in the IO Devices view. Use this view to associate application
and system objects with DI objects and scan groups.
Scan groups are contained by DI objects and help categorize devices that are associated with
them on the basis of how often their I/O points are scanned.

y
Validating and Editing I/O Assignments
The IO Device Mapping view is a table that displays I/O auto assignment references for application

op
and system objects that are linked to DI object scan groups. Manually configured references are
not displayed in the IO Device Mapping view, nor are attributes associated with application and
system objects that have not yet been assigned to a scan group. The attributes shown in this view
are determined by what is selected in the IO Devices view.
C
When you initially open the IO Device Mapping view after starting the IDE, the table will scroll so
the far right column is in view.
Selecting a DI object in the IO Devices view lists I/O auto assignment attributes for all
ot


objects linked to all scan groups under it.
 Selecting individual scan groups restricts the scope of the information displayed in the IO
Device Mapping view to the objects that have been linked to the selected scan groups.
N

 Selecting individual application or system object further restricts the scope of attributes
displayed to only those associated with the selected object.
o

Note: You can select multiple items in the IO Devices view. Selected items can be at
different hierarchical levels. Selecting a subordinate object will exclude non-selected objects
within the device hierarchy, even though the parent object is selected.
D

In the IO Device Mapping view, you can view and validate I/O references for each automatically
generated attribute, and you can override the automatically generated I/O references. As is the
case in the IO Devices view, you do not have to check out objects to change their I/O assignments.

Using the IO Mapping View

The IO Mapping view is divided into columns, each of which displays information for an I/O
attribute that has been auto assigned.
You can change how I/O attributes are displayed by sorting, grouping, or filtering the attributes.

Validating I/O References

You can validate I/O attributes that have been auto assigned in the IO Device Mapping view. To
begin I/O reference validation, press the Validate References button.

Wonderware Training
 Lab 11 – Connecting the Mixer to the Field 5-31

Lab 11 – Connecting the Mixer to the Field

Introduction
In this lab, you will work with the Production area and change the I/O assignment of Mixer100
objects. You will connect the objects to live controller data, and then change the agitator speed
and monitor the data acquisition.

Objectives
Upon completion of this lab, you will be able to:
 Change the I/O assignment of objects
 Connect objects to live controller data
 Monitor data acquisition

y
op
C
ot
N
o
D

Application Server 2017 Update 3

5-32 Module 5 – Device Integration

Reassign the I/O

First, you will undeploy the Production area and all its contained areas and objects. Then, you will
make the I/O assignments.
1. In the ArchestrA IDE, Model View, fully expand the Production area, and then undeploy
Production and all its contained areas and objects.

y
op
C
The Undeploy dialog box appears.
ot
N
o

2. Leave the default options and click OK.

D

Wonderware Training
 Lab 11 – Connecting the Mixer to the Field 5-33

When complete, the progress displays 100% completed.

3. Click Close.

y
4. In the IO Devices pane, expand ProdPLC.

op
C
ot
N
o
D

Application Server 2017 Update 3

5-34 Module 5 – Device Integration

5. Assign Production and all its contained areas and objects you just undeployed, except L1
and T1, which should remain with Simulator\Fast, to ProdPLC\Topic1.
The L1 and T1 objects were not moved to ProdPLC\Topic1, as they are not part of the Mixer
process and do not have any item addresses in the Modbus simulator.

y
op
6. Deploy the Production area and all its contained areas and objects.
C
ot
N
o
D

7. In the Deploy dialog box, click OK to accept the default settings.

When complete, the progress displays 100% completed.
8. Click Close.

Wonderware Training
 Lab 11 – Connecting the Mixer to the Field 5-35

View the Attributes in Runtime

Now, you will return to Object Viewer to change the agitator speed in runtime and monitor the data.
The agitator speed is represented by Speed.PV and controlled by Speed.SP. The agitator speed
will match the setpoint speed only when the agitator is on. The process data is now coming from
the Mobus OI server and represents actual process data, not just random simulated values. See
Module 2, Section 2, “Case Study” for a description of the process.
9. In Object Viewer, in the Mixer100 watch window, double-click Agitator_001.Speed.SP.
The Modify Numeric Value dialog box appears.
10. In the Value field, change the speed to 50.0.

y
op
11. Click OK.
Wait for the mixer to be full, which causes the agitator to start, and note the
Agitator_001.Speed.PV.
C
ot
N
o
D

12. Minimize Object Viewer.

Application Server 2017 Update 3

5-36 Module 5 – Device Integration

y
op
C
ot
N
o
D

Wonderware Training
 Section 4 – Device Integration Redundancy 5-37

Section 4 – Device Integration Redundancy

This section describes DI redundancy and explains how to configure a Redundant DI Object.

Working with Data Acquisition Redundancy

The RedundantDIObject monitors and controls the redundant DIObject data sources at the object
level. Unlike redundant AppEngines, individual DIObject data sources do not have redundancy-
related states. For all practical 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 OI Server groups. These must be
reflected in and channeled through the RedundantDIObject, which monitors the two DIObject data
sources. It also determines which one is Active at any given time. Both data sources must also
have the same item address space.

RedundantDIObject

y
The RedundantDIObject provides you with the ability to configure a single object with connections

op
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.
C
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,
ot

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
N

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
o

implemented via block reads (when available in the source DIObject). Write transactions,
which are implemented via block writes (when available in the source DIObject).
D

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 OI Server groups and must have the same item address space.

Note: The RedundantDIObject checks the state of its source DIObjects on every scan cycle.

Application Server 2017 Update 3

5-38 Module 5 – Device Integration

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.
RedundantDIObjects belong to a family of objects called DINetwork objects. Refer to the
Redundancy Module for more details.

Configuring Data Acquisition Redundancy

Data acquisition redundancy objects involve two DIObjects and the RedundantDIObject. In data
acquisition redundancy, you must configure all three components:
 Primary DIObject data source
 Backup DIObject data source

y
 Redundant DIObject data source

op
C
ot
N
o
D

Because data acquisition redundant components are essentially standalone objects, all valid
operations that apply to any other ApplicationObjects apply to the three objects.
All IDE commands, Galaxy Dump and Load functions, and import and export operations are valid
on the two DIObject data sources and the RedundantDIObject.
Before you can deploy the RedundantDIObject, you must configure at least one scan group. Also,
configure only scan, block read, and block write groups shared by the Primary and Backup
DIObjects in the RedundantDIObject.
To configure the Redundant DIObject, on the General tab of the Object Editor, set the Primary DI
Source and Backup DI Source. Set up the common scan groups. Set up the common block read
and block write groups on the tabs of the Object Editor.

Wonderware Training
 Section 4 – Device Integration Redundancy 5-39

Deploying Redundant DIObjects

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 Runtime

The three objects in the data acquisition redundancy scheme (RedundantDIObject and its two
DIObject data sources) work like any other ArchestrA object when deploying, alarming, and
historizing. They have no special redundancy-related states or restrictions.
During runtime, the RedundantDIObject monitors the status of the DIObject data sources, and
handles the switching from Active to Standby object if failure conditions occur.

RedundantDIObject and PLC Connectivity

For the RedundantDIObject, you can use the scan group PingItem attribute to monitor the
connection status of the PLC at runtime. If you are using the redundancy feature of the

y
RedundantDIObject to communicate with DIObjects, you should configure the PingItem attribute
for each scan group.

op
C
ot
N
o
D

Application Server 2017 Update 3

5-40 Module 5 – Device Integration

y
op
C
ot
N
o
D

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-41

Lab 12 – Configuring the Redundant

DI Object

Introduction
In this lab, you will configure the Galaxy for redundancy at the Device Integration level. This is
accomplished by using the Redundant DI Object, which monitors two Device Integration objects.
You will then create a deployment model for the Redundant DI Object and force a failover on a
redundant DI system.
If you are on a single-node network configuration, you will skip this lab.

Objectives
Upon completion of this lab, you will be able to:

y
 Configure an instance of a Redundant DI Object
 Create a deployment model for a Redundant DI Object

op
 Force a failover on a redundant DI system

C
ot
N
o
D

Application Server 2017 Update 3

5-42 Module 5 – Device Integration

Configure Redundant DI Objects

First, you will create and configure the DI objects for the redundant DI system. You will then create
the deployment model for the redundant DI objects.
1. In the ArchestrA IDE, Model view, undeploy ProdPLC.
2. Undeploy Production, Line1, Line2, and all their hosted objects.
Notice that the objects display yellow boxes, indicating that the objects have been
undeployed.

y
op
C
ot

3. Rename ProdPLC to R_ProdPLC1.

N
o
D

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-43

4. In the Template Toolbox, Training\Global toolset, create a new instance of

$gDDESuiteLinkClient.

y
op
C
ot
N

5. Rename the instance R_ProdPLC2.

o
D

Application Server 2017 Update 3

5-44 Module 5 – Device Integration

6. Open the R_ProdPLC2 configuration editor.

7. On the General tab, configure the instance as follows:

Server node: <Instructor will provide node (for example, X00Prod)>

Server name: MBTCP

The Server name shown in this example is for the Modbus simulator used in the training
rooms. This will be different for the data source in your plant.

y
op
8. Click the Topic tab.

9. In the Available topics section, click the ScanGroupList button to add a topic.
C
10. In the Topic field, enter Topic1 and press Enter.
ot
N
o

11. Save and close, and then check in the object with an appropriate comment.
D

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

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-45

13. In the Deployment view, assign the R_ProdPLC2 instance to AppEngine1.

y
op
C
Now, you will create the Redundant DI Object.
14. In the Template Toolbox, Training\Global toolset, create a new instance of
$gRedundantDIObject and rename the instance ProdPLC.
ot
N
o
D

15. Open the ProdPLC configuration editor.

Application Server 2017 Update 3

5-46 Module 5 – Device Integration

16. On the General tab, in the Primary DI source drop-down list, select R_ProdPLC1.
17. In the Backup DI source drop-down list, select R_ProdPLC2.

18. On the Scan Group tab, click the Copy Common Scan Groups button.
The Copy Common Scan Groups dialog box appears and displays Topic1 in the Identically
named area.

y
op
C
ot
N
o
D

19. Click OK.

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-47

In the Available scan groups area, Scan Group column, Topic1 appears.

y
20. Save and close, and then check in the object with an appropriate comment.

op
Now, you will deploy the objects.
21. In the Model view, assign the ProdPLC instance to the ControlSystem area.
C
ot
N
o
D

Application Server 2017 Update 3

5-48 Module 5 – Device Integration

22. In the Deployment view, assign the ProdPLC instance to AppEngine1.

y
op
23. In the IO Devices pane, expand ProdPLC.
C
24. Expand R_ProdPLC1\Topic1, if necessary.
Notice that the objects are all undeployed.
ot
N
o
D

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-49

25. Select all the objects in R_ProdPLC1\Topic1 and drag them to ProdPLC\Topic1.

y
26. Select all undeployed objects.

op
C
ot
N
o
D

Using the Shift key to select all objects will include some objects that are already deployed.
Application Server will be able to determine which objects are already deployed.

Application Server 2017 Update 3

5-50 Module 5 – Device Integration

27. Deploy the objects.

y
op
C
View the Redundancy Functionality and Data in Runtime
Now, you will return to Object Viewer to add Redundant DI Object attributes to a new watch
ot

window. Then, you will force a failover condition and observe the behavior.
28. In the Deployment view, open ProdPLC in Object Viewer.
29. Verify data in the Mixer100 watch window.
N
o
D

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-51

30. Add a new watch window named DIO Redundancy.

31. Select ProdPLC and add the following attributes to the watch window:
 ConnectionStatus
 DISourceActive
 DISourceBackup
 DISourcePrimary
 DISourceStandby
 ForceFailoverCmd
 StatusBackupDISource
 StatusPrimaryDISource
 SwitchCnt
 SwitchReason
The watch window displays that R_ProdPLC1 is currently the active DI source and
R_ProdPLC2 is the standby DI source.

y
op
C
ot
N

You will now force a failover and observe that the active DI source changes from R_ProdPLC1 to
R_ProdPLC2.
o

32. In the watch window, double-click ProdPLC.ForceFailoverCmd.

D

33. In the Modify Boolean Value dialog box, click the True option.

Application Server 2017 Update 3

5-52 Module 5 – Device Integration

34. Click OK.

The watch window now displays R_ProdPLC2 as the active DI source and R_ProdPLC1 as
the standby DI source. The redundancy has switched once, as indicated by the
ProdPLC.SwitchCnt attribute, and the ProdPLC.SwitchReason is ForceFailover.

y
op
35. Click the Mixer100 tab to verify that all of the data is still displaying good quality.
36. On the DIO Redundancy tab, trigger ProdPLC.ForceFailoverCmd again to switch back to
R_ProdPLC1 as the active DI source.
C
ot
N
o
D

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-53

Now, you will trigger a failover by setting the DI object off scan. For this section, DISourceActive
should be R_PRODPLC1.
37. Select R_ProdPLC1 and add ScanStateCmd to the watch list.

y
op
C
ot
N
o
D

38. Double-click R_ProdPLC1.ScanStateCmd.

.

Application Server 2017 Update 3

5-54 Module 5 – Device Integration

39. In the Modify Boolean Value dialog box, click the False option.

40. Click OK.

The watch window now displays R_ProdPLC2 as the active DI source and R_ProdPLC1 as
the standby.
Notice that the SwitchCnt is now 3 and the SwitchReason is Offscan.

y
op
C
ot
N

41. Click the Mixer100 tab and verify that all data is still displaying good quality.
42. On the DIO Redundancy tab, set the R_ProdPLC1.ScanStateCmd value to True.
Notice that Failover does not change. This is because the Redundant DIO Object does not
o

automatically switch back to the Primary DI Source.

D

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-55

43. Trigger ProdPLC.ForceFailoverCmd again to switch back to R_ProdPLC1 as the active DI

source.

y
44. Save the watch list and minimize Object Viewer.

op
C
ot
N
o
D

Application Server 2017 Update 3

5-56 Module 5 – Device Integration

y
op
C
ot
N
o
D

Wonderware Training
 y
op Module 6 – History
C
Section 1 – Historizing Data for Application Server 6-3
ot

Lab 13 – Configuring and Retrieving History 6-11

N
o
D
6-2 Module 6 – History

Module Objectives
 Configure the $AppEngine object to store Historian to a Historian Server
 Configure history in objects
 Retrieve process history in Insight

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Historizing Data for Application Server 6-3

Section 1 – Historizing Data for Application Server

This section describes how Historian historizes data. It explains how to configure engines and
platforms for historization and describes how to configure objects to historize attributes. It also
discusses how to retrieve historical data with Insight.

Historization Background
You can configure application objects to store process data in the Historian. Historical data from
Application Server can be retrieved and viewed using standard Historian database utilities. Also,
you can use historical data to produce reports shown from your client applications.

Application Server History Components

To save your process data to a historical database, you must install the Historian. A Historian can
be installed on any computer outside the Galaxy, but on the same network. In a production

y
environment, the Historian should be installed on a dedicated computer.

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

C
ot
N
o
D

A single Historian installation can receive historical data from a single Galaxy. A push model is
used to send and save new historical updates to Historian. Each system Object Engine (Platform,
AppEngine, ViewEngine) includes a historian primitive that sends all history updates for all hosted
objects to the historian. All Engine objects include an attribute to specify the node name of the
computer hosting Historian.
The figure shows a single Historian. This may be a common configuration, but other Application
Server configurations support multiple Historian databases for a Galaxy. However, each Engine
Object only sends its historical data to one Historian.

Application Server 2017 Update 3

6-4 Module 6 – History

The following figure shows the major ArchestrA components to save process data from a
production device to the Historian.

There is a one-to-one relationship between a historical Object attribute and a tag in Historian.

y
For storage, the story is similar. When an Object decides to store a new VTQ to Historian, it

op
pushes that storage update message, with the new VTQ, to Historian using a Historian supplied
interface. 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.

Historian Installation and Deployment

C
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
ot

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

A single Historian can receive historical data from a single Galaxy only.

Store and Forward

o

If the Historian shuts down or the network connection to it is lost while an application is running,
historical data continues to be stored locally on the computer hosting the WinPlatform Object.
D

When the Historian node recovers, data is forwarded from the local node to the Historian node at a
low priority.
If an AppEngine loses connectivity to the Historian node, the Historian reports bad data quality to
clients. When you undeploy an Object with attributes configured for history, the Historian stores the
final data points with Bad quality.

History Configuration

Saving Object Attribute Data to the Historian

Attribute values can be saved as historical data when values change. Data quality and time are
also associated with attribute values. When available, Application Server uses the extended
attribute’s value, the timestamp when the value changed, and the calculated quality of the data to
create a Value, Time, Quality (VTQ) packet sent to the Historian. If there is no timestamp

Wonderware Training
 Section 1 – Historizing Data for Application Server 6-5

associated with the attribute value, the current scan time from the AppEngine hosting the Object is
used instead.

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 Historian node. For each Object, you can configure attributes of the following data
types to be saved to the 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.

y


 Enum type attributes are saved as Historian integer ordinal values.

op
 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 Historian are in the engineering units specified for the
attribute. The Historian does not scale numerical values.
C
Configuration of a Non-Numerical Attribute for Historization
For an Object that has non-numerical historizable attributes, the ArchestrA IDE user can enable
ot

history for each attribute. No other configuration data is provided, except for a Boolean Object, 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.
N

Configuration of a Numerical Attribute for Historization

For an Object that has numerical historizable attributes, the ArchestrA IDE user can enable history
o

for each attribute. Once enabled, certain configuration settings can be specified. These settings
determine how often data is historized.
D

The following configuration settings can then be specified:

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.
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.
Trend Hi - Initial maximum trend value in engineering units for clients. The default is 10.0.
Trend Lo - Initial minimum trend value in engineering units for clients. The default is 0.0.

Application Server 2017 Update 3

6-6 Module 6 – History

The following are advanced configuration settings that require a knowledge of Historian Server
and will not be discussed in this course:
 Interpolation Type
 Rollover Value
 Sample Count
 Enable Swinging Door Rate Deadband

Dynamic, Automatic Configuration of 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.

y
Reconfiguration of Historian at Object Redeploy Time

op
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.
C
Reconfiguration of Historian at Object Undeploy Time
When an AutomationObject that has been historized is undeployed, the Object does not cause
ot

any dynamic reconfiguration of the Historian product. In other words, the Historian tag and all its
history is left in the Historian. This means the history data can still be examined in the future even
if the AutomationObject is no longer deployed.
N

NaN Handling
For Float and Double attributes, a potential value is the IEEE NaN encoding for the float or double
o

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
D

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.

Wonderware Training
 Section 1 – Historizing Data for Application Server 6-7

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
Historian 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

y
in the VTQ packet. Both Application Server and Historian use UTC time.

op
C
ot
N
o
D

Application Server 2017 Update 3

6-8 Module 6 – History

Configuring Common Historical Attributes

Each application or system Object that you select from the Template Toolset include a set of
common attributes you configure to save data to the Historian. These are configured after
activating the History feature in the Attributes tab.
The historical attributes you configure are based on the data type of the Object. For example, the
following figure shows the common historical attributes for numerical attributes (integer, float, or
double).

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Historizing Data for Application Server 6-9

Configuring the WinPlatform Object to Store Historical Data

A WinPlatform Object contains attributes to configure how historical store-and-forward data is
cached locally and then pushed to the Historian. Also, you can select the WinPlatform Object’s
Platform, scheduler, and engine data to be saved to the Historian. Finally, you can select the
WinPlatform’s attribute values to be saved to the Historian.

Configuring an AppEngine Object to Store Historical Data

If an AppEngine is deployed before Historian Server is started, history data can be stored locally
by HCAL until the objects successfully register with the Historian Server.

Note: Except for Late Data, the ViewEngine Object contains the same historical attributes as the
AppEngine Object.

Insight

y
Historian Insight provides web-based access to Historian Server. It is installed with Historian as an
on-premise application. It helps to retrieve historical data through the web browser and present

op
data in different formats, such as trends and tables. On a remote client node, you can connect to
Historian Insight using a web browser.
C
ot
N
o
D

Application Server 2017 Update 3

6-10 Module 6 – History

With Historian Insight, you can present your data in a chart, work with data using dashboards,
save and share content, and view and reuse content. You can search for specific saved-content,
tags, or keywords and view the results in a chart. You can choose the chart type, add or remove
tags from the chart, and fine-tune how content is displayed. You can save, download, and share
the content. You can also embed the content in a web page or other HTML-based document.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-11

Lab 13 – Configuring and Retrieving History

Introduction
In this lab, you will configure the Galaxy for historization to the Historian Server. Specifically, you
will configure the AppEngine Object to store historical data to a Historian Server.
Additionally, you will configure the object attributes to be historized.

Objectives
Upon completion of this lab, you will be able to:
 Configure the AppEngine object to store historical data on a Historian Server
 Configure objects to historize attributes
 Retrieve historical process data with Insight

y
op
C
ot
N
o
D

Application Server 2017 Update 3

6-12 Module 6 – History

Configure the Galaxy for Historization

First, you will configure the Galaxy to allow historization of process data and alarm logging.
1. In the ArchestrA IDE, open the ProdPlatform configuration editor.
2. On the General tab, in the History storeforward directory field, enter C:\S&F.

y
op
C
3. Save and close, and then check in the object with an appropriate comment.
ot

4. Open the AppEngine1 configuration editor.

5. On the General tab, History area, check the Enable storage to historian check box.
6. In the Historian field, enter the node where the Historian is installed <instructor will provide
N

(for example, X00Eng)>.

o
D

7. Save and close, and then check in the object with an appropriate comment.

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-13

Configure Attributes for Historization

Next, you will configure the object attributes to historize process data and log alarms.
8. In the Template Toolbox, Training\Project toolset, open the $Meter configuration editor.
The PV attribute is selected by default.
9. Click the History button, which will add a check mark that indicates the History group has
been enabled.

y
op
C
ot

10. Scroll down, if necessary, and lock the History group.

N
o
D

Application Server 2017 Update 3

6-14 Module 6 – History

11. Scroll down and unlock Trend high and Trend low.

12. Save and close, and then check in the object with an appropriate comment.
The Check In dialog box reappears with an Object 1 of 1 completed message.

y
op
C
ot

Notice that the change was also propagated to the mixer instance.
13. Click Close.
N
o
D

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-15

14. In the Template Toolbox, Training\Project toolset, open the $Mixer.Level configuration
editor.
15. Scroll down to the History group.
16. In the Trend high field, enter 100.0 and lock it.

y
op
C
17. Save and close, and then check in the object with an appropriate comment.
The Check In dialog box reappears with an Object 1 of 1 completed message.
ot
N
o
D

Notice that the change was also propagated to the Level_001 instance.
18. Click Close.

Application Server 2017 Update 3

6-16 Module 6 – History

19. In the Template Toolbox, Training\Project toolset, open the $Mixer.Temperature

configuration editor.
20. In the History group, in the Trend high field, enter 250.0 and lock it.

21. Save and close, and then check in the object with an appropriate comment.

y
The Check In dialog box reappears with an Object 1 of 1 completed message.

op
C
ot
N
o

Notice that the change was also propagated to the Temperature_001 instance.
D

22. Click Close.

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-17

23. In the Template Toolbox, Training\Project toolset, open the $Valve configuration editor.
24. In the attributes list, select OLS.

25. Click the History button.

y
26. Lock the History group.

op
C
ot
N
o
D

27. Save and close, and then check in the object with an appropriate comment.
Notice that the change was propagated to other instances.
28. When the Check In dialog box displays the Object 1 of 1 completed message, click Close.

Application Server 2017 Update 3

6-18 Module 6 – History

29. In the Template Toolbox, Training\Project toolset, open the $Mixer.Agitator configuration
editor.
30. Select the Speed.PV attribute.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-19

31. Click the History button, and then lock the History group.
32. In the History group, Trend high field, enter 100.0.

y
op
C
ot
N
o

33. Save and close, and then check in the object with an appropriate comment.
D

Notice that the change was propagated to the agitator instance.

34. When the Check In dialog box displays the Object 1 of 1 completed message, click Close.
35. You may configure other objects of your choice for historization.

Application Server 2017 Update 3

6-20 Module 6 – History

The Deployment view now displays several objects that need to be redeployed.

y
op
C
36. Deploy ProdPlatform and keep the default options.
37. When the Deploy progress displays 100% completed, click Close.
ot
N
o
D

All the objects you configured are now being historized.

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-21

View the Historical Process Data with Insight

Now, you will use Insight to provide a visual display of plant historical data in a trend format.
38. Start Wonderware Historian | InSight.
After a few seconds, Insight appears.

y
op
C
39. In the Search field, enter Level and wait for Data to appear.
ot

40. Click the arrow to the right of whichever entry you would like to see.
In this example, we use name includes Level (1).
Level_001.PV and other level attributes appear.
N
o
D

41. Click Level_001.PV.

Application Server 2017 Update 3

6-22 Module 6 – History

The Insight Trend appears for the selected tag. You may have to scroll to the right to see the
trend.
42. Click the blue trend.

y
op
C
ot

The tag details appear with another trend indicator.

43. Click the trend indicator in the tag details.
N
o
D

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-23

The full trend appears.

You can see the trend for different time periods by clicking the preferred option in the timeline
at the bottom of the window.

y
44. Set the time to the last hour.

op
C
ot
N
o
D

45. On your own, explore the features of Insight.

Application Server 2017 Update 3

6-24 Module 6 – History

y
op
C
ot
N
o
D

Wonderware Training
 y
op
Module 7 – Alarms and Events
C
Section 1 – Alarms and Events Overview 7-3
ot

Lab 14 – Configuring and Interacting with Alarms 7-23

N
o
D
7-2 Module 7 – Alarms and Events

Module Objectives
 Configure alarms in objects
 Interact with alarms in Object Viewer
 View historical alarms in Insight
 Query for historical alarms in MS SQL Server

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Alarms and Events Overview 7-3

Section 1 – Alarms and Events Overview

This section describes alarms and events. It explains alarms and events reporting of objects
through areas, the alarm options for attributes, and how to monitor alarm attributes and states
with Object Viewer. It discusses the historization of alarms and events with Historian, as well as
how to retrieve alarm history from SQL Server.

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 and events. Alarms and events are occurrences 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, are a special type of
event that represent the occurrence of a condition that is considered abnormal (generally bad) in

y
nature and requiring immediate attention from a user. The system handles the real-time reporting
of alarms in a special manner and provides special clients for their viewing.

op
Examples of alarms include:
 A process measurement has exceeded a predefined limit, such as a high temperature
alarm. C
 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.
ot

Examples of events include:

 A plant process has started; for example, a new batch or campaign starts.
N

 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.
o

 The system engineer has started or stopped a system component; for example, stopping
an engine.
D

 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 ArchestrA Logger. Note, sometimes certain software events may
log a message in addition to generating an event, but this is ancillary. Logger messages
are not events.

Application Server 2017 Update 3

7-4 Module 7 – Alarms and Events

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 Distributed Alarm
subsystem. A Boolean check box is provided in the Platform AutomationObject indicating whether
it subscribed to Areas or not for alarm and event reporting.

y
op
C
ot

The Platform is responsible for routing all alarms and events for all Areas subscribed to by that
N

Platform to the 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 acknowledgments, enables and disables received from distributed
o

alarming back to the appropriate AutomationObject. Alarm acknowledgments, enables, and

disables carry along the User information for security purposes. An alarm generated by Application
D

Server contains fields that are generated by the alarm functions inside the AutomationObject.

Wonderware Training
 Section 1 – Alarms and Events Overview 7-5

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.

Types of Alarms
Application Server supports the following types of alarms:
 Limit alarms
 Deviation alarms
 Diagnostic alarms
 Rate of change alarms
 Bad value alarms

y
The type of alarm that you can configure is based on the data type of the attribute’s value.

op
Limit Alarms
A limit alarm compares the current value to one or more predetermined alarm limits within the
attribute’s full range of values. If the value exceeds a limit, an alarm occurs.
C
ot
N
o

In the AnalogDevice Object, these limit alarms are configured in the Level alarms area.
You can individually select and configure values and priorities for the LoLo, Lo, Hi, and HiHi alarm
D

limits. You can set individual messages for each alarm limit.

Application Server 2017 Update 3

7-6 Module 7 – Alarms and Events

You can also configure alarm and time deadbands for limit alarms. The alarm deadband is
expressed as engineering units of the attribute’s full value range. The deadband range sets the
percentage of the total range that the attribute value must change to reset a limit alarm to the
inactive state. For example, if the HiHi alarm limit is 80 and the alarm deadband is 5, then the
attribute value must decrease below 75 to reset a HiHi alarm to an inactive state.
The time deadband sets the length of time that an attribute value must continuously remain in an
alarm or unalarmed condition. The process variable must remain above or below the indicated
limit for at least the indicated deadband time before the application Object updates the status of
the alarm CONDITION Boolean. Then, standard Alarm Primitive logic determines whether to take
that updated alarm condition and report changes to the alarm state or not.
The timestamp when a limit alarm becomes active or inactive is the most current timestamp of the
corresponding input value. If there is no timestamp associated with the alarmed value, the
AppEngine timestamp is used instead.

Deviation Alarms
A deviation alarm compares the current attribute value to a target Engineering Units value. Then,

y
the absolute value of the difference is compared to one or more alarm deviation limits expressed in
EngineeringUnits.

op
C
ot
N

You can individually select and configure values and priorities for the minor deviation limit and the
major deviation limit. You can set individual messages for the minor and major deviation alarm
limits.
o
D

The deviation alarm’s settling period is the time allowed for the attribute value to reach an
expected target value after a device starts. No alarm can occur during the settling period.
You can also configure a value for a deviation deadband, which is expressed in Engineering Units.
The deadband range sets a threshold that an attribute value must change from a deviation limit to
reset the alarm to the inactive state.

Wonderware Training
 Section 1 – Alarms and Events Overview 7-7

The timestamp when a deviation alarm becomes active or inactive is the most current timestamp
of the corresponding input value. If there is no timestamp associated with the alarmed value, the
AppEngine timestamp is used instead.

Rate of Change (ROC) Alarms

A rate of change alarm identifies when an attribute value is changing too quickly over time. For
example, you can set a rate of change alarm for a tank level that indicates when the pump inlet
pressure is too high.
Rate of change is the calculated slope, which is the absolute difference between the current and
previous attribute values divided by a specified interval. When the slope (positive or negative)
exceeds a specified value, a rate of change alarm occurs. For example, if a tank volume increases
from 17 to 45 liters over a 5 minute interval, the calculated slope is 5.6 liters per minute. If you set
your rate of change alarm limit to 5.0 liters per minute, a rate of change alarm condition exists.

y
op
C
ot

Alarm limits are expressed in the Engineering Units of the attribute’s value over an interval, which
can be per second, minute, hour, or day.
N
o
D

You can select and configure the value and priority for the upward and downward ROC limits. You
can set individual messages for ROC alarms that exceed the upward or downward limits.
The timestamp when a rate of change alarm becomes active or inactive is the most current
timestamp of the corresponding input value. If there is no timestamp associated with the alarmed
value, the AppEngine timestamp is used instead.

Application Server 2017 Update 3

7-8 Module 7 – Alarms and Events

Bad Value Alarms

The Bad value alarm feature adds an alarm if the value returned from the attribute is determined to
be bad quality.

Configuring Plant State-Based Alarms

You can map alarm modes on a per-Galaxy basis to different plant states to control how alarms
are reported. Five plant states are pre-defined, and have default alarm states associated with
them:
Default

y
Plant State Available Alarm States
Alarm State

op
Running Enable Enable
Maintenance Disable Enable / Disable / Silence
Startup Silence Enable / Disable / Silence
Shutdown Disable Enable / Disable / Silence
Testing Silence
C
Enable / Disable / Silence
ot
N
o
D

You can define new plant states, rename plant states, or remove existing plant states, except the
“Running” state (you can, however, rename “Running”). The alarm state for Running is read-only
and cannot be changed from Enable.

Wonderware Training
 Section 1 – Alarms and Events Overview 7-9

After you have defined plant state-based alarm configurations for the Galaxy, you can assign plant
state-based alarming to area objects in the Galaxy. This is done by setting the PlantState attribute
for each area Object that will use plant state-based alarming. The area Object will automatically
update its PlantAlarmMode attribute to match the alarm state that is set for the PlantState currently
assigned to it.

Attribute Definition
PlantState The name of the currently assigned plant state (InProduction,
Maintenance, etc.).
PlantStateAlarmMode The alarm state of the assigned plant state (enable, silence, or disable).
This attribute is read-only at runtime.

Enabling, Silencing, and Disabling Alarms

Alarms can be enabled, disabled, or silenced while an application is running. 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.

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

op
To enable an Object’s alarms, you must ensure that the AlarmModeCmd and AlarmInhibit
attributes are enabled for the Object, its container, and its area. An event, including the user’s
name, is generated indicating the Object’s alarms are enabled. When Object alarms are enabled,
you can enable, silence, or disable an individual alarm.
C
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.
ot

When Object alarms are silenced, an individual alarm that is enabled or silenced is forced to be
silenced. When Object alarms are silenced, an individual alarm can be disabled.
Disabled: No alarms for the Object are detected. The alarm is return-to-normal until the alarm is
N

re-enabled. The disabled state is more restrictive than the silenced and enabled alarm states. A
disabled alarm does not require acknowledgment.
When Object alarms are disabled, an individual alarm that is enabled or silenced is forced to be
o

disabled.
When Object alarms are enabled and an individual alarm is enabled or silenced, the individual
D

alarm can be inhibited. This forces the individual alarm to be disabled.

When Object alarms are silenced and an individual alarm is enabled or silenced, the individual
alarm can be inhibited. This forces the individual alarm to be disabled.
When Object alarms are inhibited, an individual alarm that is enabled or silenced is forced to be
disabled.

Setting Alarm State with Object Attributes

The Application Server alarm enable/disable mechanism includes four attributes to set an Object
alarm mode and report alarm status:
 AlarmModeCmd Attribute
 AlarmInhibit Attribute
 AlarmMode Attribute
 _AlarmModeEnum Attribute

Application Server 2017 Update 3

7-10 Module 7 – Alarms and Events

AlarmModeCmd Attribute
AlarmModeCmd is a writeable attribute that sets the current commanded alarm mode for the
Object. You can set the AlarmModeCmd to enabled, silenced, or disabled with a script, user input,
or from an input extension.

AlarmInhibit Attribute
The AlarmInhibit attribute disables one or more alarms when set to TRUE. The value of the
AlarmInhibit attribute is typically set by a script, manually by the user, or from an input extension. If
the AlarmInhibit attribute is set TRUE, all alarms of the Object and of any contained objects are
disabled.
When the AlarmInhibit attribute is set to FALSE, alarms are not inhibited and the Object
AlarmMode and parent Object AlarmMode determine whether alarming is enabled, silenced, or
disabled.

AlarmMode Attribute

y
The AlarmMode is a calculated attribute that identifies the Object alarm mode and is based upon
the current values of an Object’s:

op
 AlarmModeCmd attribute
 AlarmInhibit attribute
C
ot
N

Application Server checks the AlarmModeCmd and AlarmInhibit attributes of an Object and the
o

AlarmMode status of the parent Object. Application Server then updates the Object's AlarmMode
attribute to reflect the most restrictive setting.
D

All individual alarms use the Object's AlarmMode status to determine whether they are enabled,
silenced, or disabled.
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.

Wonderware Training
 Section 1 – Alarms and Events Overview 7-11

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 typeStringof
InternationalizedString, with a maximum length of 329 characters. The

y
DescAttrName attribute can contain a static alarm description or a reference to
another string attribute within the same Object containing the alarm

op
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 runtime.
<Attribute>.InAlarm The alarm state. This is exactly the same as the attribute in the host primitive
C
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
ot

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
N

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

<Attribute>.TimeAlarmAcked The timestamp indicating the last time this alarm was acknowledged. The date
format reflects the current locale setting for the operating system.
D

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

Application Server 2017 Update 3

7-12 Module 7 – Alarms and Events

Alarm Severities
Alarm Severities are rankings with a descriptive label that can be mapped to a customizable
priority range at the Galaxy level. By default, starting with the most important are:
Default
Severity Description
Priority Range
1 Critical 1 - 250
2 High 251 - 500
3 Medium 501 - 750
4 Low 751 - 999

y
op
C
ot
N
o

Understanding How Alarms Are Ranked at Runtime

D

The most important alarm has the lowest severity number, but other criteria are taken into account
when ranking alarms by urgency at runtime.

Alarm Mode Enabled is more urgent than silenced

InAlarm TRUE (InAlarm) is more urgent than FALSE (normal)
Acked FASLSE (unacked) is more urgent than TRUE (acked)
Severity Level 1 is more urgent; 4 is least urgent

Aggregating Alarm State Information

Alarm aggregation provides an efficient way to identify whether any alarms on an Object are
currently in the InAlarm state, the overall status of the most important of those alarms, and how
many alarms are active at each level of alarm severity and at each level of containment. This
makes it possible to follow a trail from one level to the next to find the underlying cause of a
complex Object’s alarms.

Wonderware Training
 Section 1 – Alarms and Events Overview 7-13

You can view alarm aggregation statuses in runtime clients such as Object Viewer. You can model
alarm aggregation in Managed InTouch applications by using animations such as the alarm border
animation with Situational Awareness Library symbols or with ArchestrA symbols.
Alarm aggregation functionality can be described for an Object, Area, or attribute.

Attribute Aggregation represents the alarms on a specific attribute, within any Object.
If the Area’s AlarmMode is silenced, all alarms on all Objects in that Area
will be silenced.
Note: Alarm aggregation on an attribute applies only to Analog Attributes.
Object Aggregation represents all alarms on the Object, on all contained objects,
and on their descendents down to the lowest level of the Model view.
Alarm aggregation values on child objects are added to the values of the
parent Object or objects.
All objects have this alarm aggregation functionality.

y
Area Aggregation represents the alarms on the Area Object itself, on all objects
assigned to the area, and on all sub-Areas, down to the lowest level of the

op
Model view.
If the Area’s AlarmMode is silenced, all alarms on all Objects in that Area
will be silenced. C
Alarms are aggregated if they are in one of three states:
 UNACK_ALM
 ACK_ALM
ot

 UNACK_RTN
Alarms in the ACK_RTN state are not aggregated.
Alarms in silenced mode are aggregated, even though they do not appear in the runtime client.
N
o
D

Application Server 2017 Update 3

7-14 Module 7 – Alarms and Events

Alarm Aggregation Attributes

A set of five attributes provide runtime aggregated alarm status information. These attributes are
available for all objects. If alarm aggregation is enabled on the Area, the following attributes
aggregate their respective alarm status values for the Area, for all sub-Areas, contained objects,
and their descendants assigned to the Area. If alarm aggregation is disabled, these attributes
remain at their default values. Alarm aggregation attributes on objects behave similarly to alarm
aggregation attributes specific to Analog Attributes.

Runtime
Attribute Description
Access
<Attribute>.AlarmCntsBySeverity Array of counts of all alarms that are in Read-Only
UNACK_ALM, ACK_ALM, or UNACK_RTN states
on the Object, aggregated by severity levels 1-4.
<Attribute>.AlarmMostUrgentAcked TRUE (default) indicates that no alarms are in the Read-Only
InAlarm state or waiting to be Acked.
A value of TRUE also indicates that the most urgent
alarm(s) on the Object and its descendants in the

y
InAlarm state have been acknowledged, whether or
not they are currently InAlarm.

op
<Attribute>.AlarmMostUrgentInAlarm FALSE (default) indicates that no alarms are in the Read-Only
InAlarm state or waiting to be Acked.
A value of FALSE indicates whether the most urgent
alarm(s) on the Object and its descendants are in
C
the InAlarm state, whether or not they have been
acknowledged.
<Attribute>.AlarmMostUrgentMode The AlarmMode of the most urgent alarm(s) on this Read-Only
ot

Object and its descendants. If no alarms are in the

InAlarm state or waiting to be Acked, the value is the
same as the AlarmMode for the Object.
<Attribute>.AlarmMostUrgentSeverity Severity level expressed as an integer 1-4 of the Read-Only
N

most urgent alarm(s) on the Object and its

descendants. If no alarm is in the InAlarm state or
waiting to be Acked, the value is 0 (zero).
o
D

Wonderware Training
 Section 1 – Alarms and Events Overview 7-15

Configuring Alarm State Aggregation

Configuring alarm state aggregation consists of normal alarm configuration procedures, plus an
added step of enabling the aggregation feature on each relevant Area Object.
 Check the Aggregate Alarms check box on the Area Object editor to enable alarm
aggregation. This sets the value of the AlarmAggregationStateCmd attribute to True.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

7-16 Module 7 – Alarms and Events

Monitoring Alarm State Information at Runtime

You can obtain runtime alarm state information using clients such as Object Viewer. You can also
create InTouch applications with Situational Awareness Library symbols configured with alarm
border animations that display alarm state aggregation status information.
When your objects are configured with alarms, you can watch the aggregated alarm severity
counts at each containment level in Object Viewer.

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Alarms and Events Overview 7-17

Shelving Alarms
You can shelve alarms to temporarily hide them from displays for a fixed period of time. Alarms
continue to be historized, even when they are shelved. Shelving typically is used to reduce alarm
“noise”, or to temporarily suppress alarms that might be triggered during system modifications or
repairs, allowing you to focus on correcting other more urgent alarms.
Shelving is similar to silencing an alarm, but shelved alarms differ from silenced alarms in the
following ways:
 Shelved alarms have a built-in associated timeout. Shelved alarms are automatically
unshelved when the configured shelving period expires. You can also manually unshelve
alarms and return them to an active, displayed state.
 Alarm shelving must be enabled at an area level, but shelving applies only to individual
alarms. You cannot shelve a hierarchy of alarms for an entire area or for an entire Object.
You cannot propagate alarm shelving through the Model View hierarchy.
 The system enforces role-based limitations on permission to shelve alarms, alarm severity
levels that can be shelved, and the total number of alarms a user can shelve.

y
The system tracks who shelved the alarm, from what workstation, the reason for shelving the
alarm, when shelving began, and when shelving will expire. Shelved alarms aggregate in similar

op
fashion to silenced alarms.
A set of seven attributes provide runtime alarm shelving information and control:

AlarmShelveCmd User writeable. Use this attribute to shelve or unshelve an alarm.

C
Default values: Duration = 0, Reason = ""
AlarmShelved Read-only, Boolean value. Shows True if alarm is shelved, False if
ot

alarm is unshelved.
Default value: False
AlarmShelveStartTime A read-only date/time stamp indicating when alarm shelving began,
N

based on the engine time when the shelving request was received.
Default value: Blank
AlarmShelveStopTime A read-only date/time stamp equal to the AlarmShelveStartTime plus
o

the duration for which the alarm is to be shelved.

D

Default value: Blank

AlarmShelveReason A read-only string value providing the reason for which the alarm was
shelved or unshelved by the Alarm Shelve command.
Default value: Blank (See AlarmShelveCmd attribute.)
AlarmShelveUser Read-only, the name of the user who most recently shelved or
unshelved the alarm with the Alarm Shelve command.
Default value: Blank
AlarmShelveNode Read-only, the name of the computer node from which the user most
recently shelved or un-shelved the alarm with the Alarm Shelve
command.
If the node is hosted in a Terminal Server client session, the node and
the TSE ID are both identified.
Default value: Blank

Application Server 2017 Update 3

7-18 Module 7 – Alarms and Events

Enabling Alarm Shelving

Alarm shelving is configured from the IDE Galaxy menu in Alarms and Events Configuration.
(Galaxy | Configure | Alarms and Events Configuration).

y
op
C
Shelving is enabled on the Area Object as shown in the image on page 7-15.
ot

Shelving Alarms at Runtime

Use a runtime client to shelve and unshelve alarms. From Application Server, you can use Object
Viewer to monitor and control shelved alarm attributes.
N
o
D

The six read-only alarm shelving attributes will display the current shelving status information and
the AlarmShelveCmd attribute can be used to change the status.

Wonderware Training
 Section 1 – Alarms and Events Overview 7-19

Using the Log Change Feature for an Attribute

The Attributes tab allows you to configure an existing attribute for I/O, alarms, and history
functionality no embedded in the original Object.
To enable this feature, select the Log Change feature to log system events for an attribute of
Boolean, Integer, Float or Double data type. When enabled, the Log Change feature logs data
change events as well as user events.

Obtaining Aggregated Alarm Severity Status Information at Runtime

Obtain aggregated alarm severity status information by:
 Mapping alarm severity levels to priority ranges,
 Configuring alarms on objects,
 Enabling alarm aggregation by Area,
 Viewing aggregated alarm status information by means of runtime clients and
applications.

y
Mapping Alarm Severity to Priority

op
Use the IDE to map each of four alarm severities to priorities expressed as numeric ranges.
Alarms can then be aggregated and displayed with the specified severity at runtime.

Note: Mapped alarm severities are not shared across galaxies in a multi-Galaxy environment.
C
Each Galaxy in the environment will have its own priority to severity mapping.

Configuring Alarm Severity to Priority Mapping

ot

The Alarms and Events Configuration dialog allows you to map alarm severities to priority ranges,
to enable alarm shelving by priority range, and to enable or disable historization of both alarm
severities and event types.
N

Default Alarm Mapping and Historization Values

From Priority To Priority
Severity Description Shelve Historize
Range Range
o

1 Critical N Y 1 250
2 High N Y 251 500
D

3 Medium Y Y 501 750

4 Low Y Y 751 999

An example is shown in the image on page 7-18.

Monitoring Alarm Severities at Runtime
Monitor alarms by severity, expressed as integers 1–4, using clients such as Object Viewer and
InTouch applications in WindowViewer. You can monitor individual alarms and you can monitor
alarms aggregated by containment level.
Typically, alarm priorities and priority to severity mapping are not changed during runtime, but it is
possible to change alarm priority configuration and severity mapping without closing the client
application.

Application Server 2017 Update 3

7-20 Module 7 – Alarms and Events

Alarm Features
Alarm configuration choices can be added to a template or instance on the Attributes tab for the
following three Data types:
 Boolean
 Float
 Integer
 Double
The configuration Available features and Advanced choices will be different depending on the
data type selected.
If you select a Boolean data type for an attribute, you will be able to select either a Bad value
alarm or a State alarm. If you select a State alarm, you will be able to select from the following
configuration Categories:

 Discrete
Value LoLo

y

 Value Lo

op
 Value Hi
 Value HiHi
 DeviationMinor
 DeviationMajor
 ROC Lo
C
 ROC Hi
 SPC
 Process
ot

 System
 Batch
 Software
N

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

o

Saving Alarms and Events as Historical Data

D

Alarms and events detected by the Application Server at runtime are saved as historical data to
the Historian for the host engine. In addition, alarm-related events such as Acknowledge are also
saved as historical alarm data.

Wonderware Training
 Section 1 – Alarms and Events Overview 7-21

What alarms and events are to be historized to Historian is configured in the Alarms and Event
Configuration dialog box.

y
op
C
Configuring an Area Object to Save Alarm Counts as Historical Data
ot

An Area Object represents a plant area to group objects for modeling and report alarms. You can
configure a set of attributes to save the counts of an area’s alarm states to the historian. An Area
Object contains a set of attributes to save the counts of the following alarm states to the historian:
N

 Active alarms
 Unacknowledged alarms
 Disabled or silenced alarms
o

In runtime, when you hover your mouse over the chart, a cursor appears with values for all tags.
You can move the cursor along the x-axis to see values for specific points in time.
D

When the associated tags in the InSightApp have alarms and events, the trend displays with
additional indicators.

Application Server 2017 Update 3

7-22 Module 7 – Alarms and Events

For alarms, the trend lines display with highlights. You can click on the highlighted area on the
trend line to see additional information about that alarm.

y
op
For events, trend lines display with event icons. You can click on an icon to see additional
information related to that event.
C
ot
N
o
D

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-23

Lab 14 – Configuring and Interacting with

Alarms

Introduction
In this lab, you will add a high- and a low-level alarm to the mixer level and a new attribute to
monitor an alarm condition triggered from the PLC. You will interact with alarm attributes in Object
Viewer and use Insight and Microsoft SQL Server Management Studio to view the latest recorded
alarms.

Objectives
Upon completion of this lab, you will be able to:
 Configure alarms in objects

y
 Interact with alarm attributes in Object Viewer
 View alarm and process history in Insight

op
 Retrieve alarm history from SQL Server

C
ot
N
o
D

Application Server 2017 Update 3

7-24 Module 7 – Alarms and Events

Configure Alarming for the Galaxy

First, you will configure two of the $Mixer templates for alarms.
1. In the ArchestrA IDE, Template Toolbox, Training\Project toolset, open the $Mixer.Level
configuration editor.
2. Click the Limit alarms button.

y
op
C
3. Scroll down and configure the Limit alarms group as follows:

Limit alarms: locked

ot

Hi: checked and locked (default)

Hi: Limit: 80.0 and unlocked
Hi: Priority: 100 and locked
N

Hi: Alarm message: Mixer Hi Level Alarm and locked

Lo: checked and locked (default)
o

Lo: Limit: 25.0 (default) and unlocked

Lo: Priority: 500 (default) and locked
D

Lo: Alarm message: Mixer Lo Level Alarm and locked

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-25

4. Save and close, and then check in the object with an appropriate comment.
5. In the Training\Project toolset, open the $Mixer configuration editor.
6. Add an attribute named Alarm.Condition and configure it as follows:

Description: Mixer Malfunction and locked

Data type: Boolean (default)
Writeability: Object writeable
I/O: checked
Read: selected
State alarm: checked and locked
Category: Process and locked (default)
Priority: 700 and locked (default)
Alarm message: me.Alarm.Condition.Description (default) and locked (default)
Active alarm state: True (default) and locked (default)

y
op
C
ot
N
o
D

7. Save and close, and then check in the object with an appropriate comment.
You may configure other data points for alarming.

Application Server 2017 Update 3

7-26 Module 7 – Alarms and Events

In the Deployment view, notice that the Mixer100 object now has changes that have not been
deployed.

y
op
C
8. Deploy Mixer100.
ot
N
o
D

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-27

View the Alarm States in Runtime

Now, you will return to Object Viewer to view alarm conditions, as well as high and low alarms.
9. View Mixer100 in Object Viewer.
10. Add a new watch window and name it Mixer100Alarms.
11. Add the following attributes to the watch window:
 Mixer100.Alarm.Condition
 Mixer100.Alarm.Condition.InAlarm
 Mixer100.Alarm.Condition.AckMsg
 Mixer100.Alarm.Condition.TimeAlarmOff
 Mixer100.Alarm.Condition.TimeAlarmOn
 Level_001.PV.Hi.InAlarm
 Level_001.PV.Lo.InAlarm
 Level_001.PV

y
 Level_001.PV.Hi.Limit
 Level_001.PV.Lo.Limit

op
 Level_001.PV.Hi.AckMsg
 Level_001.PV.Lo.AckMsg
C
ot
N
o
D

Notice Level_001.PV.Hi.InAlarm is true, when Level_001 is above 80 and

Level_001.PV.Lo.InAlarm is true, when Level_001 is below 25.

Application Server 2017 Update 3

7-28 Module 7 – Alarms and Events

12. For Mixer100, add AlarmCntsBySeverity to the watch list.

The Array for Mixer100.AlarmCntsBySeverity dialog box appears.

13. In the Enter an array index field, enter -1.

y
op
C
14. Click OK.
ot
N
o
D

There are 13 counts available:

1-4: Active Alarms Per Severity
5-8: UNACK_ALM Per Severity
9-12: UNACK_RTN Per Severity
13: Which Alarm Severity and Status applies to the local object
Sum of the bit values of 1-12

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-29

Acknowledge an Alarm in Runtime

Next, you will acknowledge the one of the Level_001 alarms.
15. Double-click Level_001.PV.Hi.AckMsg.
16. Add a comment to acknowledge the alarm.

y
op
17. Click OK.
When an alarm has been acknowledged, the severity count for the object should decrease.
C
ot
N
o

The message must change if you wish to acknowledge the alarm again later.
D

18. Save the watch list and minimize Object Viewer.

Application Server 2017 Update 3

7-30 Module 7 – Alarms and Events

View the Alarm History in Insight

Now, you will view alarm history in Insight. Alarm history is only visible in Insight for an attribute
that is historized. If an attribute is only alarmed and not historized, the alarm history is not visible in
Insight. If you closed Insight, first see Lab 13, View the Historical Process Data with Insight on
page 6-21.
19. Switch back to Insight in your browser and ensure Level_001.PV is on trend.

y
op
C
20. Click Refresh to refresh the trend to the most recent data.
ot
N
o
D

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-31

21. Hover over the trend and use your mouse wheel to zoom in until the trend shows a red
highlight color for the peak of Level_001.PV.
The zoom level must be detailed enough to show the alarm limit colors associated with alarm
severity. For Level, this is configured as Alarm Hi limit set to a priority of 100, which is Severity
1 (red color) and Alarm Lo limit of 500, which is Severity 2 (yellow color).

y
op
C
Note: Since Mixer.Alarm.Condition has no historized process data, it cannot be added to
the trend to view alarm states.
ot

View the High-Speed Alarm History Data

N

Now, you will use Microsoft SQL Server Management Studio to view the latest recorded alarms
and events.
22. Open Microsoft SQL Server Management Studio.
o

Note: You can find this in the Windows menu, under Microsoft SQL Server 2014.
D

The splash screen appears.

Application Server 2017 Update 3

7-32 Module 7 – Alarms and Events

After a slight delay, the Connect to Server dialog box appears.

y
23. Keep the default settings and click Connect.

op
24. On the File menu, click Open | File.

C
ot
N

25. Navigate to C:\Training, and select SQLQuery1.

o
D

26. Click Open.

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-33

In the middle pane, the following SQL query appears:

use Runtime
select * from Events
where EventTime > DATEADD(hh, -1, GETDATE())
27. On the toolbar, click Execute.

y
The data appears in the bottom-middle pane.

op
C
ot
N
o
D

28. Scroll to the right and down to view all the data.
29. Exit Microsoft SQL Server Management Studio.

Application Server 2017 Update 3

7-34 Module 7 – Alarms and Events

y
op
C
ot
N
o
D

Wonderware Training
 y
op
Module 8 – Object Management
C
Section 1 – Object Export and Import 8-3
ot

Lab 15 – Exporting and Importing Objects 8-11

Section 2 – Galaxy Dump and Galaxy Load 8-29
N

Lab 16 – Configuring Instances Using a .CSV File 8-35

o
D
8-2 Module 8 – Object Management

Module Objectives
 Export objects
 Import Objects
 Upgrade objects
 Revert to previous versions

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Object Export and Import 8-3

Section 1 – Object Export and Import

This section describes how to export and import objects from and to a Galaxy. It also explains
how to upgrade objects to new versions or revert to previous configurations.

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

y
backup. Also, the backup process retains security model settings for objects while exporting them
does not.

op
When exporting an object instance, it will also include the parents of that object all the way back to
and including the base template.
C
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.
ot
N
o
D

Application Server 2017 Update 3

8-4 Module 8 – Object Management

Export Objects
To export an object, select an object in the Template Toolbox or Application Views pane, and then
on the Galaxy menu, select Export | Object(s).

y
op
C
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 the objects in the Galaxy, click Export, and then
ot

click All Objects.

N
o
D

Wonderware Training
 Section 1 – Object Export and Import 8-5

The Export Automation Object(s) dialog box appears. In the dialog box, browse to the path and
add a file name (.aaPKG extension) for the export file.

y
op
Click Save. Click Cancel to terminate the export function. If you click Save, a progress box is
displayed.
C
ot
N
o
D

Note: Export maintains containment and hierarchy 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.

When the export process is finished, click Close. The resulting .aaPKG file can be used to import
the chosen objects into another existing Galaxy.

Application Server 2017 Update 3

8-6 Module 8 – Object Management

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.

Import Objects
To import Automation objects, on the Galaxy menu, select lmport | Object(s).

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Object Export and Import 8-7

The Import AutomationObject(s) dialog box appears.

y
op
Browse for the file with either a .aaPKG or a .aaPDF extension. You can select more than one file.
Click Open.
C
ot
N
o
D

Application Server 2017 Update 3

8-8 Module 8 – Object Management

The Import Preferences dialog box appears.

y
op
C
In the Objects with same Tagname and Codebase as an existing object area, select one of the
following:
Skip: Do not import leaves the existing object unchanged.
ot

Overwrite existing objects if the imported configuration version is higher (default)

replaces the existing object with the object being imported if the imported object has a newer
configuration.
N

Overwrite objects regardless of configuration version replaces the existing object

regardless of whether the existing object has an older configuration or the same configuration.
In the Base Templates with a different revision number in the Codebase or a different minor
o

version area, select one of the following:

Skip: Do not migrate does not migrate objects with an older Codebase when a newer
D

Codebase exists in the Galaxy.

Migrate (default) migrates an older codebase when the replacement object is available.
In the Objects with same Tagname but with a different Codebase area, select one of the
following:
Skip: Do not import (default) leaves the existing object unchanged.
Rename object in Galaxy imports an object with a matching tagname but a different
codebase from the existing one. The existing object is not overwritten but is renamed.
Rename importing object imports an object with a matching tagname but a different
codebase from the existing one. The existing object is not overwritten. The imported object is
renamed.
Click OK to start the import process. When the import process is complete, you can start using the
objects you imported.

Wonderware Training
 Section 1 – Object Export and Import 8-9

After You Import

Imported templates are listed in the proper toolset in the Template Toolset as defined in the object.
Imported instances are shown in the Application views.
The following post-import rules apply:
 If a toolset does not exist, it is created.
 If the object belongs to a security group that does not exist, it is associated with the
Default security group.
 If the object belongs to an area that does not exist, it is associated with the Unassigned
Area.
 If the host to which the object is assigned does not exist, it is assigned to the Unassigned
Host.
 If you selected Migrate from the Import Preferences dialog box, the migrated objects are
marked with “software upgrade required” if they are deployed. These objects will be
upgraded when the objects are redeployed.

y
Note: If you import a new version of an existing instance, the new version is marked as requiring
deployment if the existing object is already deployed.

op
C
ot
N
o
D

Application Server 2017 Update 3

8-10 Module 8 – Object Management

y
op
C
ot
N
o
D

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-11

Lab 15 – Exporting and Importing Objects

Introduction
In this lab, you will use the Export Objects and Import Objects features of the ArchestrA IDE.
Specifically, you will use these features to upgrade and downgrade object versions. Then, you will
make copies of objects within the Galaxy.

Objectives
Upon completion of this lab, you will be able to:
 Use the Export Objects and Import Objects features of the ArchestrA IDE

y
op
C
ot
N
o
D

Application Server 2017 Update 3

8-12 Module 8 – Object Management

Upgrade and Downgrade Objects

First, you will create new objects to use with the Import/Export features.
1. In the ArchestrA IDE, Template Toolbox, Application template toolset, create a new derived
template from the $UserDefined template named $Storage.
2. Move the new $Storage template to the Training\Project template toolset.

y
op
C
ot
N

3. Right-click $Storage and select Properties.

o
D

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-13

The $Storage Properties dialog box appears.

4. Click the Attributes tab.
5. Scroll down to confirm that the ConfigVersion attribute displays 1 in the Value column.

y
op
C
ot

The 1 indicates that this is the first version of the object.

6. Click Close.
N

Now, you will make changes to the $Storage object and view the version changes.
7. Open the $Storage configuration editor.
o

8. Add an attribute named Pressure.

9. Configure Pressure as follows:
D

Data type: Integer

Category: User writeable (default)

Application Server 2017 Update 3

8-14 Module 8 – Object Management

10. Add and configure another attribute named Density as follows:

Data type: Integer (default)

Category: User writeable (default)

11. Save and close, and then check in the object with an appropriate comment.
12. Right-click $Storage and select Properties.
13. Click the Attributes tab.

y
The ConfigVersion has changed to version 2.

op
C
ot
N
o
D

The ConfigVersion increases by 1 each time changes to the object are checked in.
14. Click Close.

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-15

Next, you will save a copy of the object by exporting the object.
15. Ensure $Storage is selected.
16. On the Galaxy menu, select Export | Object(s).

y
op
C
The Export Automation Object(s) dialog box appears.
ot

17. Navigate to C:\Training.

18. In the File name field, enter $StorageV2.
This corresponds with ConfigVersion 2.
N
o
D

19. Click Save.

Application Server 2017 Update 3

8-16 Module 8 – Object Management

The Export Automation Object(s) progress appears with an Object 1 of 1 completed

message. The $Storage object has been exported, as well as all parent objects in the
derivation hierarchy.

y
20. Click Close.

op
21. Open the $Storage configuration editor.
22. Add and configure two new attributes as follows:
Attribute
Name Data type Category
C
Viscosity Integer User writeable (default)
Hardness Integer (default) User writeable (default)
ot

All four attributes are now visible in the attributes list.

N
o
D

23. Save and close, and then check in the object with an appropriate comment.

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-17

24. Right-click $Storage and select Properties.

25. Click the Attributes tab.
The $Storage object has been upgraded to version 3.

y
op
C
ot

26. Click Close.

N
o
D

Application Server 2017 Update 3

8-18 Module 8 – Object Management

Now, you will export this version of the object by using an alternative method of right-clicking
directly on the object.
27. Right-click $Storage and select Export | Object(s).

y
op
C
28. In the Export Automation Object(s) dialog box, File name field, enter $StorageV3.
ot
N
o
D

29. Click Save.

30. When the Export Automation Object(s) progress is complete, click Close.

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-19

Next, you will delete the $Storage object and import the previously exported $StorageV2.
31. Right-click $Storage and select Delete.

y
The Delete dialog box appears.

op
C
ot
N

32. Click Yes to confirm deletion of the $Storage object.

o
D

Application Server 2017 Update 3

8-20 Module 8 – Object Management

The $Storage object no longer appears in the Project toolset.

33. On the Galaxy menu, select Import | Object(s).

y
op
C
ot
N
o
D

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-21

The Import Automation Object(s) dialog box appears.

34. Select $StorageV2.aaPKG.

y
op
35. Click Open.
The Import Preferences dialog box appears.
C
ot
N
o
D

36. Leave the default options and click OK.

Application Server 2017 Update 3

8-22 Module 8 – Object Management

The Import Automation Object(s) progress appears with an Object 2 of 2 completed

message. The $Storage object has been imported.

y
37. Click Close.
$Storage appears again in the Project toolset.

op
C
ot
N
o
D

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-23

38. Open the $Storage properties.

39. On the Attributes tab, verify configuration version 2 was imported.

y
op
C
ot

40. Click Close.

N
o
D

Application Server 2017 Update 3

8-24 Module 8 – Object Management

Upgrade Objects
Now, you will import the $StorageV3.aaPKG file.
41. On the Galaxy menu, select Import | Object(s).
42. In the Import Automation Object(s) dialog box, select $StorageV3.aaPKG.

y
op
C
43. Click Open.
44. In the Import Preferences dialog box, leave the default options and click OK.
ot

45. Click Close when the import is complete.

46. Open the $Storage properties.
N
o
D

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-25

47. On the Attributes tab, verify configuration version 3 was imported.

y
op
C
48. Click Close.
ot

49. In the $Storage configuration editor, verify that all four attributes are now visible in the
attributes list.
N
o
D

50. Close the configuration editor.

Application Server 2017 Update 3

8-26 Module 8 – Object Management

Downgrade Objects
Now, you will downgrade the $Storage object by importing a previous version of the object.
51. Use the Galaxy menu to import $StorageV2.aaPKG.
52. In the Import Preferences dialog box, Objects with same Tagname and Codebase as an
existing object area, select the Overwrite objects regardless of configuration version
option.

y
op
C
ot
N

53. Click OK.

The Import Automation Object(s) progress appears with an Object 2 of 2 completed
message. The import progress displays the objects that were skipped and those that were
overwritten. Specifically, the base template was skipped, while the derived template was
o

overwritten.
D

54. Click Close.

Wonderware Training
 Lab 15 – Exporting and Importing Objects 8-27

55. Open the $Storage properties, and on the Attributes tab, verify configuration version 2 was
imported.

y
op
C
ot

56. Click Close.

57. In the $Storage configuration editor, verify that the two attributes that were added in version 3
no longer exist.
N
o
D

58. Close the configuration editor.

Application Server 2017 Update 3

8-28 Module 8 – Object Management

Duplicate an Object
Next, you will import an object to create a duplicate of the object.
59. Right-click $Storage and rename the object $Storage1.

y
60. Use the Galaxy menu to import $StorageV2.aaPKG file.

op
61. In the Import Preferences dialog box, keep the default options and click OK.
The Import Automation Object(s) progress shows that $Storage was not found, so the
object was created. C
ot
N
o
D

62. Click Close.

Both objects now appear in the Project toolset. They are identical, except for their tag names.

Wonderware Training
 Section 2 – Galaxy Dump and Galaxy Load 8-29

Section 2 – Galaxy Dump and Galaxy Load

This section describes how to use the Galaxy Dump and Galaxy Load features of the ArchestrA
IDE. It explains how to use these features to modify and create instances of objects.

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-writable, one column per attribute. Attributes
that are locked or runtime writable only are not saved to the file. The following are not exported:
 Scripts libraries are not exported. Scripts within an object are exported.

y
 Attributes that are not text based are not exported.
For example, type QualifiedStruct is not exported.

op
 Custom object online help files are not exported.
To export objects to a Galaxy dump file, 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.
C
On the Galaxy menu, select Export, and then click Galaxy Dump.
ot
N
o
D

Application Server 2017 Update 3

8-30 Module 8 – Object Management

The Galaxy Dump dialog box appears.

Browse to the location to which you want to dump the selected instances and enter the name of
the .csv file.

y
op
C
Click Save to continue or Cancel to end the export function.
ot

If Save is chosen, the Galaxy Dump progress box is displayed.

N
o
D

After the Galaxy dump process is finished, click Close. A .csv file has been created containing the
selected objects and configuration data. Note that attribute properties that have been locked will
not be part of the Galaxy dump CSV file.

Wonderware Training
 Section 2 – Galaxy Dump and Galaxy Load 8-31

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.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

8-32 Module 8 – Object Management

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.

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.

Using editing functions like copy and paste, you can create quantities of already configured
objects ready to be imported into your Galaxy.

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, on the Galaxy menu, select Import, and then click Galaxy Load.

y
op
C
ot
N
o
D

Wonderware Training
 Section 2 – Galaxy Dump and Galaxy Load 8-33

The Galaxy Load dialog box appears.

In the Galaxy Load dialog box, browse to locate the .csv file that contains the objects and
configuration data you want to import.

y
op
C
Select the file and click Open to continue or Cancel to end the import function.
If Open is chosen, the Galaxy Load Conflict Resolution dialog box is displayed.
ot
N
o
D

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.

Application Server 2017 Update 3

8-34 Module 8 – Object Management

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. Otherwise, the Galaxy Load dialog box indicates that the load was successful.
When the load is done, all objects changed or created during the Galaxy Load process are
checked in.

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 quotation marks.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-35

Lab 16 – Configuring Instances Using a .CSV

File

Introduction
In this lab, you will use the Galaxy Dump and Galaxy Load features of the ArchestrA IDE to
change the configuration of the mixer instance, including its contained objects. You will also use
the Galaxy Load feature to create a new mixer from an existing .csv file.

Objectives
Upon completion of this lab, you will be able to:
 Use Galaxy Dump and Galaxy Load features to modify instances
 Use a .csv file to make configuration changes to an object

y
op
C
ot
N
o
D

Application Server 2017 Update 3

8-36 Module 8 – Object Management

Use the Galaxy Dump Feature

First, you will dump the configuration of the Mixer100 instance and its contained objects into a .csv
file.
1. In the Model view, select Mixer100 and all of its contained objects.

y
op
2. On the Galaxy menu, select Export | Galaxy Dump.
C
ot
N
o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-37

The Galaxy Dump dialog box appears.

3. Navigate to C:\Training, and then in the File name field, enter Mixer.

y
op
4. Click Save.
When the Galaxy Dump is complete, the progress displays 100% processed.
C
ot
N
o
D

5. Click Close.

Application Server 2017 Update 3

8-38 Module 8 – Object Management

Change the File Using Microsoft Excel

Now, you will use Microsoft Excel to view and change the .csv file.
6. Start Microsoft Excel.

Note: The following process will vary depending on your version of Microsoft Excel.

7. On the File menu, click Open, and then in the Open dialog box, navigate to C:\Training.
8. Using the file type drop-down list, select All Files, and then select the Mixer file name.

y
op
C
ot

9. Click Open.
N
o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-39

The Text Import Wizard - Step 1 of 3 dialog box appears.

10. Verify Delimited is selected.

y
op
C
11. Leave all other default options and click Next.
The Text Import Wizard - Step 2 of 3 dialog box appears.
ot

12. Uncheck the Tab check box, and then check the Comma check box.
N
o
D

13. Click Finish.

Application Server 2017 Update 3

8-40 Module 8 – Object Management

The file contents open in Microsoft Excel.

14. Expand column A to fully display the cell contents.

y
op
C
ot

15. For the Mixer100 instance, ShortDesc attribute (cell G6), enter Mixing Tank.
N
o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-41

16. Change the remainder of the ShortDesc values as follows:

Instance ShortDesc Cell
Agitator_001 Agitator Motor G10
Inlet1_001 Inlet Valve 1 G14
Inlet2_001 Inlet Valve 2 G18
Level_001 Tank Level G22
Outlet_001 Outlet Valve G26
Pump1_001 Pump 1 G30
Pump2_001 Pump 2 G34
Temperature_001 Mixer Temperature G38

The cells now display the new short description names.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

8-42 Module 8 – Object Management

17. On the File menu, click Save As, and then navigate to C:\Training.
18. In the File name field, enter Mixer1.
19. In the Save as type drop-down list, select CSV (Comma delimited).

y
20. Click Save.

op
C
The Microsoft Excel dialog box appears, confirming if you are sure you want to keep the
format.
ot

Note: This dialog box will vary depending on your version of Microsoft Excel.
N
o

21. Click Yes to retain the .csv format.

D

22. Close Microsoft Excel.

The Microsoft Excel dialog box appears, prompting you to save your changes, even though
you have not made any further changes.

23. Click Don’t Save.

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-43

24. In the ArchestrA IDE, on the Galaxy menu, select Import | Galaxy Load.

y
op
25. In the Galaxy Load dialog box, select the Mixer1 file.
C
ot
N
o
D

26. Click Open.

Application Server 2017 Update 3

8-44 Module 8 – Object Management

The Galaxy Load Conflict Resolution dialog box appears.

27. Select the Only update changed attributes option.

28. Click OK.

When the Galaxy Load is complete, the progress displays 100% processed.

y
op
C
ot
N

29. Click Close.

o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-45

The Model view now displays that the objects that were imported have pending changes that
need to be redeployed. You will redeploy these later in this lab.

y
op
30. For the following objects, open the configuration editor, click the Object Information tab and
C
verify the Description fields match those you entered in Microsoft Excel:
Mixer100: Mixing Tank
ot

Agitator_001: Agitator Motor

Inlet1_001: Inlet Valve 1
Inlet2_001: Inlet Valve 2
N

Level_001: Tank Level

Outlet_001: Outlet Valve
o

Pump1_001: Pump 1
Pump2_001: Pump 2
D

Temperature_001: Mixer Temperature

31. Close the configuration editors.

Application Server 2017 Update 3

8-46 Module 8 – Object Management

32. In the Deployment view, deploy Mixer100, and then verify the Cascade Deploy option is
checked.

y
33. Leave all other default options and click OK.

op
34. When the Deploy progress is 100% completed, click Close.

Create Another Mixer Container Instance

C
Next, you will create another mixer container instance named Mixer200 by importing a .csv file.
35. In Microsoft Excel, on the File menu, click Open and navigate to the C:\Training folder.
ot

36. If necessary, use the file type drop-down list to select the All Files option, and then select the
Mixer1 file.
N
o
D

37. Click Open.

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-47

Now, you will rename the tagname from Mixer100 to Mixer200 and rename all the contained
objects. This will create new instance names for a new mixer and all its contained objects. The
most efficient and complete way to do this is using the Find and Replace feature.
38. Expand Column A so you can see all its contents.
39. Use the Find and Replace feature to rename Mixer100 to Mixer200.

Note: You can use the Replace All feature to make these changes.

y
op
40. Rename the objects ending in _001 to end in _002.

Note: You can use the Replace All feature to make these changes.
C
ot
N
o

41. Rename everything named Line1 to Line2.

D

42. Click Close.

Application Server 2017 Update 3

8-48 Module 8 – Object Management

43. Verify that the object tagnames were changed with the Replace All feature.
44. Verify that the area is now Line2 and the object names for the Container names were
changed with the Replace All feature.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-49

45. On the File menu, click Save As and navigate to the C:\Training folder.
46. In the File name field, enter Mixer2.
47. In the Save as type drop-down list, verify that CSV (Comma delimited) is selected.

y
48. Click Save.

op
C
The Microsoft Excel dialog box appears, confirming if you are sure you want to keep the
format.
ot
N

49. Click Yes to retain the .csv format.

o

50. Close Microsoft Excel.

The Microsoft Excel dialog box appears, prompting you to save your changes.
D

51. Click Don’t Save.

Application Server 2017 Update 3

8-50 Module 8 – Object Management

52. In the ArchestrA IDE, on the Galaxy menu, select Import | Galaxy Load.
53. In the Galaxy Load dialog box, select Mixer2.

y
op
54. Click Open.
The Galaxy Load Conflict Resolution dialog box appears.
C
ot
N
o
D

55. Leave the default options and click OK.

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-51

When the Galaxy Load is complete, the progress displays 100% processed.

56. Click Close.

y
57. In the Model view, expand Line2 and note that the new Mixer200 instance has been added to
the Line2 area.

op
58. Expand Mixer200 to view the new contained objects.
C
ot
N

Note: Since the Line2 area was assigned to ProdPLC:Topic1 for autobind purposes (in
o

Lab 12), all objects assigned to that area will automatically be autobound to the same IO
source.
D

59. Deploy Mixer200 and all its contained objects.

60. In the Deploy dialog box, leave the default options and click OK.

Application Server 2017 Update 3

8-52 Module 8 – Object Management

61. When the Deploy progress is 100% completed, click Close.

Mixer200 and its contained objects have been deployed.

62. View Mixer200 in Object Viewer.

63. In Object Viewer, create a watch window called Mixer200 and add the following attributes to it:
 Level_002.PV
 Temperature_002.PV

y
 Agitator_002.CMD
 Agitator_002.PV

op
 Agitator_002.Speed.PV
 Agitator_002.Speed.SP
 Inlet and Outlet CMDs and OLSs
 Pump CMDs and PVs
C
ot
N
o
D

64. Save the watch list and minimize Object Viewer.

Wonderware Training
 y
op Module 9 – Security
C
Section 1 – Security Overview 9-3
ot

Lab 17 – Configuring Security 9-11

Section 2 – Object Security 9-37
N

Lab 18 – Implementing Object Security 9-41

o
D
9-2 Module 9 – Security

Module Objectives
 Configure Security Classifications for attributes in objects
 Configure security in a Galaxy
 View the security audit trail

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Security Overview 9-3

Section 1 – Security Overview

This section describes how ArchestrA handles security. It discusses the security models available
in the ArchestrA IDE and describes how to configure general security permissions and
operational permissions.

ArchestrA security is designed to prevent users from performing unauthorized activities. This
includes users of:
 IDE for configuring and managing objects
 ArchestrA System Management Console (SMC) for performing maintenance and system
administration functions.
 Any runtime operations.
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. When using the
Galaxy security authentication mode, 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

y
the system.

op
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.
C
The ArchestrA Security Model
ot

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.
N
o
D

Each attribute of an AutomationObject is given a security classification. This provides the ability to
define who can write to attributes of an object.

Application Server 2017 Update 3

9-4 Module 9 – Security

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

y
Operational 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.

op
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. C
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:
ot

 Enabling Security
 Defining your Security Model
 Mapping Users to the Security Model
N

 Mapping AutomationObjects to the Security Model

If the Security is not enabled then Authentication mode is disabled.
o
D

Wonderware Training
 Section 1 – Security Overview 9-5

Authentication Mode

y
op
C
ot
N

On the Authentication Mode page, choose the mode of Galaxy security:

o

 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
D

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

Application Server 2017 Update 3

9-6 Module 9 – Security

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.

y
op
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:

C
 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
ot

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
N

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

 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
D

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.

Wonderware Training
 Section 1 – Security Overview 9-7

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

OS Group Based Security

If you use OS Group Based Authentication Mode, you should first familiarize yourself in depth with

y
the functions of the Windows operating system, particularly its user permissions, groups and
security features. ArchestrA OS Group Based security leverages those Windows features.

op
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
C
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
ot

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
N

the new login data. If that fails, the trusts are being reestablished by the controller, and you
should retry at a later time.
 The user's full name is not available to any client (for instance, an InTouch window) if the
o

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
D

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

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.

Application Server 2017 Update 3

9-8 Module 9 – Security

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

y
defined on each machine and imported into the Galaxy Repository (GR) and defined as
Local Host.

op
Logon Dialog Box
If security is enabled within the Galaxy, a client utility Logon dialog box will appear. Application
C
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.
ot

Username and Password are entered onto this dialog box.

If OS Authorization is being used, then the user will also be required to select from a list of
N

accessible domain name for the user being logged in.

Security Roles
o

You can create and manage user roles that apply to your organization’s processes and work-
based authorities. Two roles are defined by default: Administrator and Default.
D

Security Users
If you select either of the OS-based authentication modes, users with local accounts are added to
the Authorized Users Available list in the following format: .\<username>. If you select the OS
Group based authentication mode, the local account must exist on each node in the Galaxy for
successful authentication of that user on any computer in the Galaxy.
Two users are defined by default when a new Galaxy is created: Administrator and DefaultUser.
These cannot be deleted in an open security setting and they are both associated with the default
roles.

Wonderware Training
 Section 1 – Security Overview 9-9

Security Permissions
You can specify General and Operational Permissions for each role:
 General permissions relate to application configuration and administration tasks
 Operational permissions relate to the security groups listed on the Security Groups page;
by default, the Administrator has all permissions

Note: You cannot modify the General permissions for the role of Administrator.

The following Operational Permissions that can be associated with a role:

 Can Modify "Operate" Attributes: Allows users with operational permissions to do
certain normal day-to-day tasks like changing setpoints, outputs, and control modes for a
PID object or commanding a DiscreteDevice object
 Can Modify "Tune" Attributes: Allows users to tune the attribute in the runtime
environment; examples of tuning include attributes that adjust alarm setpoints and PID
sensitivity
Can Modify "Configure" Attributes: Allows users to configure the attribute’s value,

y

which requires that the user first put the object Off scan; writing to these attributes is
considered a significant configuration change, for example, a PLC register that defines a

op
DiscreteDevice input
 Can Acknowledge Alarms: Allows users to manually acknowledge an alarm in the
runtime environment C
 Can Shelve Alarms: Allows users to manually shelve and unshelve alarms
 Can Modify Alarm Modes: Allows users to modify the mode of an alarm
 Can Modify Plant States: Allows users to modify plant states for state-based alarming
ot

 Can Verify Writes: Allows users to provide an authentication signature for attributes
configured with Verified Writes security classification. Only users with this permission can
verify a task performed by users with the Can Modify "Operate" Attributes permission.
N
o
D

Application Server 2017 Update 3

9-10 Module 9 – Security

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-11

Lab 17 – Configuring Security

Introduction
Your Galaxy security is disabled, so you have been able to perform any action during configuration
and runtime without having to log in to the ArchestrA IDE or Object Viewer. In this lab, you will
enable security in the Galaxy to use operating system user groups (OS Groups) as the
authentication method.
For this example, you will create security groups based on the areas of the plant and add several
user groups from the network domain or local computer (depending on your setup) to represent
the different security roles in the Galaxy. You will add roles for administrators, developers,
maintenance, supervisors, and operators. Each role will have a different set of permissions, both
for configuration (General permissions) and runtime (Operational permissions).

Objectives

y
Upon completion of this lab, you will be able to:

op
 Configure security in a Galaxy
 Enable OS Group security
 Create and use security groups
Add security roles and assign permissions to them

C
 Configure general permissions
ot
N
o
D

Application Server 2017 Update 3

9-12 Module 9 – Security

Enable Security in the Galaxy

First, you will enable and configure the security authentication mode.
1. On the Galaxy menu, select Configure | Security.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-13

The Configure Security dialog box appears.

2. In the Authentication Mode area, select the OS Group based option.
The Configurable intervals are displayed.
3. In the Login time field, enter 3000.

Note: Increasing the amount of Login time here will allow for a more seamless logging in
and testing of different users later in the lab.

Important: Do not click OK at this point!

y
op
C
ot
N
o
D

Application Server 2017 Update 3

9-14 Module 9 – Security

Configure Security Groups

Next, you will configure security groups based on the area model of the plant and group the
existing instances accordingly.
4. Click the Security Groups tab.

y
op
C
ot
N
o
D

5. Click the Add new Security Group button.

6. In the Security Groups available list, enter Line1 and press Enter.

Wonderware Training
 Lab 17 – Configuring Security 9-15

7. Add the following security groups:

 Line2
 ControlSystem

8. Select the Default security group.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

9-16 Module 9 – Security

9. In the Objects for Security Group ‘Default’ list, select the following instances and drag them
to the Line1 security group:
 Agitator_001
 Inlet1_001
 Inlet2_001
 Level_001
 Mixer100
 Outlet_001
 Pump1_001
 Pump2_001
 Temperature_001

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-17

Notice that the instances moved are no longer in the Default security group.

y
op
C
ot
N

10. Click Line1 to verify the instances have been moved.

o
D

Application Server 2017 Update 3

9-18 Module 9 – Security

11. Move the following instances from the Default security group to the Line2 security group:
 Agitator_002
 Inlet1_002
 Inlet2_002
 Level_002
 Mixer200
 Outlet_002
 Pump1_002
 Pump2_002
 Temperature_002

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-19

12. Click Line2 to verify the instances have been moved.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

9-20 Module 9 – Security

13. Move the following instances from the Default security group to the ControlSystem security
group:
 AppEngine1
 ControlSystem
 GRPlatform
 ProdPlatform
 ProdPLC
 R_ProdPLC1
 R_ProdPLC2
 Simulator

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-21

14. Click ControlSystem to verify the instances have been moved.

y
After the assignments, the Default security group will contain only the objects that were not
moved.

op
C
ot
N
o
D

Application Server 2017 Update 3

9-22 Module 9 – Security

Configure Security Roles

Now, you will add user groups from the network domain or local computer (depending on your
setup) as security roles for the Galaxy. You will then assign permissions (General and Operational)
to each role depending on the tasks they are allowed to perform at configuration time and runtime.
15. Click the Roles tab.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-23

16. Click the Add new Role button to add a new role.
The Select Groups dialog box appears.

y
op
C
ot
N

17. In the Select in drop-down list, select the domain name ('CLOUD' in the graphic below) or
o

leave "." if no domain controller is available.

D

Note: Your instructor will provide you with the correct domain name.

The operating system’s groups are now displayed in the Available OS Groups list.

Application Server 2017 Update 3

9-24 Module 9 – Security

18. In the Available OS Groups list, select Application Administrators.

19. Click the Add selected OS Group button.

The Application Administrators group is added to the Selected Groups list.

y
op
C
ot

20. Add the following OS Groups:

N

 Application Developers 1
 Plant Maintenance 1
 Plant Operators 1
o

 Plant Operators 2
 Plant Supervisors 1
D

Wonderware Training
 Lab 17 – Configuring Security 9-25

21. Click OK.

The OS Groups are added to the Roles available list.

y
op
C
ot
N
o
D

Important: Do not click OK at this point!

Application Server 2017 Update 3

9-26 Module 9 – Security

Next, you will configure permissions for the built-in Default and Administrator security roles.
22. In the Roles available list, select the Default security role.
23. In the General permissions list, uncheck:
 IDE Permissions (This will uncheck all its sub-permissions)
 SMC Permissions\Can Start the SMC
 SMC Permissions\Can Start/Stop Engine/Platform
The only permission checked will be Can Write to GObject Attributes using ObjectViewer.

Important: All users will inherit the permissions assigned to the built-in Default security role.
Assigning the Can Write to GObject Attributes using ObjectViewer permission to this role
is not a good practice. It is done here to allow testing of the security features through Object
Viewer in a later lab.

24. In the Operational permissions list, uncheck the Default security group.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-27

25. Select the Administrator role and configure the General permissions and Operational
permissions as follows:

General permissions:
IDE Permissions checked (default)
SMC Permissions checked (default)
Operational permissions:
Default checked (default)
Line1 checked
Line2 checked
ControlSystem checked

y
op
C
ot
N
o
D

Application Server 2017 Update 3

9-28 Module 9 – Security

You will now configure permissions for the added security roles.
26. Select the Application Administrators role and configure the General permissions and
Operational permissions as follows:

General permissions:
IDE Permissions checked
SMC Permissions checked
Operational permissions:
Default checked
Line1 checked
Line2 checked
ControlSystem checked

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-29

27. Select the Application Developers 1 role and configure the IDE Permissions and SMC
Permissions as follows:

General permissions:
IDE Permissions checked
User Configuration unchecked
SMC Permissions checked
Can Start/Stop Engine/Platform unchecked

y
op
C
ot
N
o
D

Application Server 2017 Update 3

9-30 Module 9 – Security

28. With the Application Developers 1 role selected, configure the Operational permissions as
follows:

Operational Permissions:
Default
Can Modify "Operate" Attributes checked
Line1
Can modify "Configure" attributes checked
Can modify "Operate" attributes checked
Line2
Can modify "Configure" attributes checked
Can modify "Operate" attributes checked
ControlSystem
Can modify "Configure" attributes checked

y
Can modify "Operate" attributes checked

op
C
ot
N
o
D

All currently deployed objects belong to the Default security group. The application
developers need Operate permissions for this group to be able to place the object off scan for
redeployment.

Wonderware Training
 Lab 17 – Configuring Security 9-31

29. Configure the Plant Maintenance 1 security role as follows:

General permissions:
SMC Permissions checked
Can Start/Stop Engine/Platform unchecked
Operational permissions:
Line1
Can modify "Configure" attributes checked
Can modify "Tune" attributes checked
Line2
Can modify "Configure" attributes checked
Can modify "Tune" attributes checked
ControlSystem
Can modify "Configure" attributes checked

y
Can modify "Tune" attributes checked

op
C
ot
N
o
D

Application Server 2017 Update 3

9-32 Module 9 – Security

30. Configure the Plant Operators 1 security role as follows:

Operational permissions:
Line1
Alarms
Can acknowledge Alarms checked
Can modify "Operate" attributes checked

y
op
C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-33

31. Configure the Plant Operators 2 security role as follows:

Operational permissions:
Line2
Alarms
Can acknowledge Alarms checked
Can modify "Operate" attributes checked

y
op
C
ot
N
o
D

Application Server 2017 Update 3

9-34 Module 9 – Security

32. Configure the Plant Supervisors 1 role as follows:

Operational permissions:
Line1
Alarms
Can acknowledge Alarms checked
Can modify "Operate" attributes checked
Can Verify Writes checked
Line2
Alarms
Can acknowledge Alarms checked
Can modify "Operate" attributes checked
Can Verify Writes checked
ControlSystem

y
Alarms
Can acknowledge Alarms

op
checked
Can modify "Operate" attributes checked
Can Verify Writes C checked
ot
N
o
D

33. Click OK to apply the security configuration.

Wonderware Training
 Lab 17 – Configuring Security 9-35

Because security has been enabled in the Galaxy, after a few moments, you are prompted to
log into the ArchestrA IDE. Your instructor will provide any passwords different from those
listed below.
34. In The Change User dialog box, log in as one of the members of the Plant Maintenance 1
security role:
Role First, Last User name Password Domain
Plant Maintenance 1 Kevin Green KevinG ww CLOUD
Monica Reed MonicaR ww CLOUD

y
op
Since maintenance personnel were not given permissions to access the ArchestrA IDE (Can
Start the IDE permission), an access denied message is displayed.
C
ot
N

35. Click OK.

The Change User dialog box reappears.
36. Log in as one of the members of the Application Developers 1 security role:
o

Role First, Last User name Password Domain

D

Application Developers 1 Thomas Miller ThomasM ww CLOUD

Carol Morris CarolM ww CLOUD

Application Server 2017 Update 3

9-36 Module 9 – Security

The ArchestrA IDE closes and reopens with the user logged in.

Notice that most of the objects need changes to be deployed because they were assigned to a
different Security Group, which modified their SecurityGroup attribute.

y
op
Note: You will deploy the objects in the next lab.
C
ot
N
o
D

Wonderware Training
 Section 2 – Object Security 9-37

Section 2 – Object Security

This section describes the security classifications for object attributes and discusses the security
audit trail.

Set Object Security

Operators interact with objects through the individual attributes of those objects. Each attribute on
the Object Editor that can be modified by operators at run time and can have an associated
security control, which is used to modify its run-time security classification.

On the Attributes tab, security icons must be enabled before you can set security for an
attribute or any of its features in a template. To enable security, click the Show/Hide Security icon
to the right of the description field.

y
op
C
ot
N

When security is enabled, security symbols will appear next to values for which security is
configurable. Security symbols are not visible in the template or its derived instances unless
enabled in the parent template. If an attribute's security classification is configurable, click the
o

security control to select one of seven possible states:

D

Security Icon Description

FreeAccess Lets you change this value without restriction even if you have no defined
permissions on the object. Anyone can write to these attributes to perform
safety or time critical tasks that can be hampered by an untimely logon
request, such as halting a failing process.
Operate Lets you work with Operate permissions to do certain normal day-to-day
tasks. These include writing to attributes like Setpoint or Command for a
Discrete Device object. This level of security requires you to have Operate
permission for the security group for the object.
SecuredWrite Requires you to authenticate using your user name and password each
time you want to write to the attribute. You also need to have Operate
permissions for the object.
VerifiedWrite Requires you to have Operate permissions to log on again and a second,
different user to also log on as the verifier before writing to the attribute.
The verifier needs to have Can Verify Writes permission for the object.

Application Server 2017 Update 3

9-38 Module 9 – Security

Security Icon Description

Tune Allows users with Tune Operational permissions to tune the attribute in the
run-time environment. Examples of tuning are attributes that adjust alarm
setpoints and PID sensitivity.
Configure Allows users with Configure Operational permissions to configure the
attribute’s value. Requires that the user first put the object off scan. Writing
to these attributes is considered a significant configuration change. For
example, a PLC register that defines a Discrete Device input.
ViewOnly Only allows users to read this attribute’s value in the run-time environment.
This attribute is never written to at run time, regardless of the user's
permissions.

If an attribute’s security is shown in gray, its security classification is locked in its parent object and
cannot be changed or it requires the enabling of a group attribute.

Group Locking/Security

y
The lock and security controls associated with option groups and features quickly set those

op
conditions for all options in the group.
The group control typically reflects the setting for all options in the group or feature set. But, if at
least one option in the group has a lock or security control that is different from the other options,
the group control shows an indeterminate icon.
C
In addition to the undefined controls, the group controls for locking and security are the same as
those for individual options.
ot

You can lock or unlock all of the attributes associated with a feature by selecting the lock icon next
to the feature name, after you activate the feature. This will lock or unlock all of the attributes for
the feature, unless an attribute was locked at a higher level. For example, if you locked an attribute
in a template, and then created another derived template, the attribute that was locked in the
N

original template cannot be unlocked (locked in parent).

If an attribute is locked in the template, you can change the value in that template, but not in the
derived children. If you change the value in the parent template, the change propagates to all child
o

objects
D

Security Audit Trail

Application Server creates several types of run-time event messages, including security-audit
(operator change) events, which are saved as historical data.
These Event messages are logged to the Alarms and Events subsystem when an operator logs on
to or logs off from an application. Also, security-audit events are logged when an operator changes
actions by means of User sets.
A Security-audit event message contains the following information:
 Event type, which is operator change.
 Timestamp, which is the date and time when the operator change event occurred. The
timestamp of the event is the current AppEngine scan time.
 Tagname, which is the name of object generating the event.
 Prim.attr, which is the reference string of the attribute being changed.

Wonderware Training
 Section 2 – Object Security 9-39

 Tag description, which is a short description of the object. For Secured and Verified writes,
this will contain the following:
 Type of write (Secured or Verified)
 Comment from the user, if any
 Reason description, if any
 FieldAttribute description, if the attribute is a FieldAttribute and has a description;
otherwise, this is the Object description.
 Area, which is the name of the area that contains the object generating the event.
 UserEngine, which is the name of the view engine or other user engine requesting the
operator change.
 Operator1, which is the full name of the primary operator requesting a change. The full
name is an attribute of the UserProfile.
 Operator2, which is the full name of the secondary operator validating the change, if any.
 Old value, which is the previous value of an attribute. o New Value, which is the new value
of an attribute.

y
Security Query

op
As a part of the security audit trail, you can use Microsoft SQL Server Management Studio to view
security-related events. When you log in to Microsoft SQL Server Management Studio, be sure to
verify the Server name is the same as the Historian computer.
C
You can create a query to show events for a set period of time. In the screen below, you are
querying for the last hour. After you create your query, on the toolbar, click Execute.
ot
N
o
D

Application Server 2017 Update 3

9-40 Module 9 – Security

The data appears in the bottom-middle pane.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 18 – Implementing Object Security 9-41

Lab 18 – Implementing Object Security

Introduction
In the last lab, you configured security roles and permissions. In this lab, you will configure the
security classifications in some of the automation objects. The valves command attribute (Cmd)
has an Operate security classification by default. The temperature maximum engineering units
(EngUnitsMax and EngUnitsRangeMax) have a Configure security classification by default. The
agitator’s speed setpoint (Speed.SP) will be set with a Secured Write security classification, and
the outlet valve command (Outlet.CMD) will be changed to a Verified Write security classification.
You will use Object Viewer to test the different security classifications against the permissions
assigned to the security roles and view the recorded security-related events in the alarm database.

Objectives
Upon completion of this lab, you will be able to:

y
 Configure security classifications for object attributes

op
 Perform secured and verified writes with Object Viewer
 View the security audit trail
C
ot
N
o
D

Application Server 2017 Update 3

9-42 Module 9 – Security

Configure Security Classifications for Attributes

First, you will set the security classifications for several attributes in your objects. You will start by
changing the agitator’s Speed.SP security classification to SecuredWrite.
1. Ensure you are logged in as one of the members of the Application Developers 1 security
role:
Role First, Last User name Password Domain
Application Developers 1 Thomas Miller ThomasM ww CLOUD
Carol Morris CarolM ww CLOUD

2. In the ArchestrA IDE, Template Toolbox, Training\Project template toolset, open the
$Mixer.Agitator configuration editor.
3. On the Attributes tab, in the attributes list, select the Speed.SP attribute.

y
op
C
ot
N

4. To the right of the Initial value field, click the shield icon and change the security classification
o

to SecuredWrite.
D

Wonderware Training
 Lab 18 – Implementing Object Security 9-43

5. Click the lock icon to propagate the security classification to the derived instances.

6. Save and close the $Mixer.Agitator template, and then check in the object with an
appropriate comment.
Notice that the change propagates to both agitators.

y
op
C
ot

7. Click Close.
Now that the security classification has been propagated to the instances, the Speed.SP attribute
N

needs to be unlocked to allow changing its value in runtime.

8. In the Template Toolbox, reopen the $Mixer.Agitator configuration editor.
9. In the attributes list, select the Speed.SP attribute.
o

10. Unlock the Initial value property.

D

Application Server 2017 Update 3

9-44 Module 9 – Security

11. Save and close the $Mixer.Agitator template, and then check in the object with an
appropriate comment.
Notice that the change propagates to both agitators.

y
12. Click Close.

op
Next, you will change the security classification of the $Mixer.Outlet attribute in the mixer to
VerifiedWrite.
13. In the Template Toolbox, open the $Mixer.Outlet configuration editor.
C
14. On the Attributes tab, in the attributes list, ensure the CMD attribute is selected.
ot
N
o
D

Wonderware Training
 Lab 18 – Implementing Object Security 9-45

15. To the right of the Initial value field, click the shield icon and change the security classification
to VerifiedWrite.
16. Click the lock icon to propagate this change to the derived instances.

y
op
17. Save and close the $Mixer.Outlet template, and then check in the object with an appropriate
comment.
18. When check in is complete, click Close.
C
19. Reopen the $Mixer.Outlet configuration editor.
20. On the Attributes tab, in the attributes list, ensure the CMD attribute is selected.
ot

21. To the right of the Initial value field, unlock the attribute.
N
o
D

22. Save and close the $Mixer.Outlet template, and then check in the object with an appropriate
comment.
23. When check in is complete, click Close.

Application Server 2017 Update 3

9-46 Module 9 – Security

Deploy Changes and Test Security Settings

Next, you will deploy the modified instances. You will then use Object Viewer to test the different
security classifications and permissions with different users belonging to the OS Groups
configured as security roles in the Galaxy.
24. If Object Viewer is open, close it now.
25. In Deployment view, expand all objects.

y
op
C
ot
N
o
D

26. Deploy the TrainingGalaxy.

27. Keep the default selections and click OK.
This will take several moments.
28. When the deployment is complete, click Close.

Wonderware Training
 Lab 18 – Implementing Object Security 9-47

Now, you will test the security classifications and permissions in runtime using Object Viewer.
29. In the Deployment view, select Outlet_001 and view it in Object Viewer.
Object Viewer opens and automatically logs in the user who is logged in to the ArchestrA IDE.

y
op
C
30. In Object Viewer, on the Options menu, select Change User.
ot
N
o
D

Application Server 2017 Update 3

9-48 Module 9 – Security

The Change User dialog box appears.

31. Log in as one of the members of the Plant Operators 1 security role:
Role First, Last User name Password Domain
Plant Operators 1 John Johnson JohnJ ww CLOUD
Lisa Young LisaY ww CLOUD

32. Load the watch list that was saved earlier and switch to the Mixer200 watch window.

y
33. Double-click Inlet2_002.CMD.

op
C
ot

34. In the Modify Boolean Value dialog box, select True.

N
o
D

35. Click OK.

Wonderware Training
 Lab 18 – Implementing Object Security 9-49

Since Plant Operators 1 personnel were not given permissions to operate Line 2 objects, an
access denied message appears.

36. Click OK.

y
37. On the Mixer100 watch window, double-click Inlet1_001.CMD.

op
C
ot
N
o

38. In the Modify Boolean Value dialog box, select True.

D

39. Click OK.

Application Server 2017 Update 3

9-50 Module 9 – Security

This time the command was executed because Plant Operators 1 have Operate permissions
over Line 1 objects.

y
Next, you will test the Configure Security classification.

op
40. Use Change User to log in as one of the members of the Plant Maintenance 1 security role:
Role First, Last User name Password Domain
Plant Maintenance 1 Kevin Green KevinG ww CLOUD
Monica Reed
C
MonicaR ww CLOUD
ot
N
o
D

Wonderware Training
 Lab 18 – Implementing Object Security 9-51

41. Add the following attributes to the Mixer100 watch window:

 Temperature_001.ScanState
 Temperature_001.ScanStateCmd
 Temperature_001.PV.EngUnitsMax
 Temperature_001.PV.EngUnitsRangeMax

y
op
C
42. Save the watch list.
ot

43. Double-click Temperature_001.PV.EngUnitsRangeMax and change the value to 505.0.

N
o
D

44. Click OK.

Application Server 2017 Update 3

9-52 Module 9 – Security

Since the attribute has a security classification of Configure, an error message appears that
the object needs to be placed off scan first.

45. Click OK.

y
46. Double-click Temperature_001.ScanStateCmd and change the value to False.

op
C
ot
N
o
D

47. Click OK.

Wonderware Training
 Lab 18 – Implementing Object Security 9-53

The ScanStateCmd attribute has a security classification of Operate. Since maintenance

personnel were not given Operate permissions over the objects, an access denied message
appears.

48. Click OK.

y
49. Log in as one of the members of the Plant Operators 1 security role:

op
Role First, Last User name Password Domain
Plant Operators 1 John Johnson JohnJ ww CLOUD
Lisa Young LisaY ww CLOUD
C
50. Double-click Temperature_001.ScanStateCmd and change the value to False to place the
object off scan.
ot

This time the change takes effect. The ScanState now displays false.
N
o
D

Application Server 2017 Update 3

9-54 Module 9 – Security

51. Log in as one of the members of the Plant Maintenance 1 security role:
Role First, Last User name Password Domain
Plant Maintenance 1 Kevin Green KevinG ww CLOUD
Monica Reed MonicaR ww CLOUD

52. Double-click Temperature_001.PV.EngUnitsRangeMax and change the value to 505.0.

Now that the object has been placed off scan, the value is written to the attribute because
maintenance personnel have been given Configure permissions over the object.

y
op
C
ot

53. Double-click Temperature_001.PV.EngUnitsMax and change the value to 500.0.

N
o
D

Wonderware Training
 Lab 18 – Implementing Object Security 9-55

54. Log in as one of the members of the Plant Operators 1 security role:
Role First, Last User name Password Domain
Plant Operators 1 John Johnson JohnJ ww CLOUD
Lisa Young LisaY ww CLOUD

55. Double-click Temperature_001.ScanStateCmd and change the value to True to place the
object on scan.

Next, you will test the SecuredWrite security classification.

56. Double-click Agitator_001.Speed.SP and change the value to 25.0.

y
op
C
ot

57. Click OK.

Since the attribute has a security classification of SecuredWrite, you are prompted for your
password.
N

58. Enter the password.

o
D

59. Click OK.

Application Server 2017 Update 3

9-56 Module 9 – Security

The value is written to the attribute.

y
op
Now, you will test the VerifiedWrite security classification by first making it fail, and then you will
log in with Plant Supervisor credentials. C
60. Double-click Outlet_001.CMD, change the value to True, and click OK.
The attribute has a security classification of VerifiedWrite, so you are prompted for your
password and the credentials of a different user with Can Verify Writes permissions over the
ot

object. If it is not a different user, you will receive an error.

61. Enter ww as your password and the credentials of the other user below in the Plant
Operators 1 security role.
N

Important: For this authentication dialog box, the second user name must be entered in the
form of domain\userid.
o

Role First, Last User name Password

Plant Operators 1 John Johnson CLOUD\JohnJ ww
D

Lisa Young CLOUD\LisaY ww

62. Click OK.

Wonderware Training
 Lab 18 – Implementing Object Security 9-57

The second user entered does not have Can Verify Writes permissions over the object, so an
access denied message is displayed.

63. Click OK.

y
64. Double-click Outlet_001.CMD, change the value to True, and click OK.
65. Enter ww as your password and the credentials of one of the following users in the Plant

op
Supervisors 1 security role.

Important: For this authentication dialog box, the second user name must be entered in the
form of domain\userid.
C
Role First, Last User name Password
Plant Supervisors 1 Michael Jones CLOUD\MichaelJ ww
ot

Karen Turner CLOUD\KarenT ww

N
o
D

66. Click OK.

Application Server 2017 Update 3

9-58 Module 9 – Security

The second user entered does have Can Verify Writes permissions over the object, so the
value is written to the attribute.

y
op
67. Use the same credentials to change Outlet_001.CMD back to false.
C
View the Security Audit Trail
Now, you will use Microsoft SQL Server Management Studio to view the security-related events for
ot

the last hour.

68. Start Microsoft SQL Server Management Studio.
N

After a slight delay, the Connect to Server dialog box appears.

o
D

69. Verify the Server name is the same as the Historian computer and click Connect.

Wonderware Training
 Lab 18 – Implementing Object Security 9-59

70. On the File menu, click Open | File.

y
op
71. In the Open File dialog box, navigate to C:\Training, and select SQLQuery2.

C
ot
N
o
D

72. Open the file.

Application Server 2017 Update 3

9-60 Module 9 – Security

73. On the toolbar, click Execute.

The data appears in the bottom-middle pane.

y
op
C
ot
N

74. Scroll to the right to view all the data.

Notice the comment field that shows the write attempts.
o
D

75. Close Microsoft SQL Server Management Studio.

Wonderware Training
 y
op
Module 10 – Introduction to
C
QuickScript.NET
ot

Section 1 – Introduction to Scripting 10-3

Lab 19 – Adding Auto Reconnect to the DDESuiteLinkClient Object 10-11
N

Section 2 – Variables and Control Statements 10-21

Lab 20 – Scripting Valve Status 10-29
o

Lab 21 – Scripting Custom Alarms 10-37

D
10-2 Module 10 – Introduction to QuickScript.NET

Module Objectives
 Introduce basic concept of scripting
 Introduce the scripting tools used in ArchestrA
 Create scripts in objects with multiple execution types
 Apply scripting tools to real examples using the System Platform

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Introduction to Scripting 10-3

Section 1 – Introduction to Scripting

This section describes the scripting environment and basic scripting syntax. It also discusses the
execution types and triggers.

Script Editing Styles and Syntax

Application Server supports two types of scripts:
 Simple scripts can perform assignments, comparisons, simple math functions, and similar
actions. Simple scripts are described in this section.
 Complex scripts can perform logical operations using conditional branching with IF-THEN-
ELSE type control structures.
Both single and multi-line comments are supported. Single-line comments start with an
apostrophe " ’ " in the line but require no ending " ’ " in the line. Multi-line comments start with a
" { " and end with a " } " and can span multiple lines.

y
White space rules apply for space and indention. Indent using spaces, or the Tab key. Individual
statements are indicated by a semicolon marking the end of the statement.

op
Required Syntax for Expressions and Scripts
The syntax in scripts is similar to the algebraic syntax of a calculator.
C
Most statements are presented using the following form:
a = (b - c) / (2 + x) * xyz;
This statement places the value of the expression to the right of the equal sign (=) in the variable
ot

location named “a.”

 A single entity must appear to the left of the assignment operator =.
 The operands in an expression can be constants or variables.
N

 Statements must end with a semicolon (;).

Entities can be concatenated by using the plus (+) operator. For example, if a data change script
such as the one below is created, each time the value of “Number” changes, the indirect entity
o

“Setpoint” changes accordingly:

Number=1;
D

Setpoint = "Setpoint" + Text(Number, "#");

Where the result is “Setpoint1.”

Simple Scripts
Simple scripts implement logic such as assignments, math, and functions. An example of this type
of scripting is:
React_temp = 150;
ResultTag = (Sample1 + Sample2)/2;
{this is a comment}

Application Server 2017 Update 3

10-4 Module 10 – Introduction to QuickScript.NET

ArchestrA IDE Scripts Tab

The Scripts tab has six areas:
 Scripts
 Inherited scripts
 Aliases
 Declarations
 Basics
 Script Editor

y
op
C
ot

The main areas of the Scripts tab include:

N

 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.
o

 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
D

Scan and Shutdown.

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

Wonderware Training
 Section 1 – Introduction to Scripting 10-5

 Basics area: Provides a location in which you set the expression, triggering conditions,
and other settings that run the script in the runtime environment. This area includes:
 Configure Execution Order: Sets the execution order of multiple scripts (inherited
and local) associated with this object.
 Historize script state: Select to send the state of the script to a 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.

y
op
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
C
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
ot

been imported using the ArchestrA IDE.

Syntax Validation
N

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. It
o

does not evaluate the logic, but rather only the syntax of the script. A script with syntax errors can
be saved. However, an object leveraging such a script cannot be deployed.
D

Application Server 2017 Update 3

10-6 Module 10 – Introduction to QuickScript.NET

Script Execution Types

The editor exposes five script types:

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Introduction to Scripting 10-7

Startup
Startup scripts are called when an object containing the script is loaded into memory, such as
during deployment, platform, or engine start.
Startup instantiates COM objects and .NET objects. Depending on load and other factors,
assignments to object attributes from the Startup method may fail. Attributes that reside off-object
are not available to the Startup method.

OnScan
OnScan scripts are called the first time an AppEngine calls this object to execute after the object’s
scan state changes to OnScan. The OnScan method initiates local object attribute values or
provides more flexibility in the creation of .NET or COM objects. Attributes that are off-engine are
not available to the OnScan method.

Execute
Execute scripts are called each time the AppEngine performs a scan and the object is OnScan.

y
The Execute script method is the workhorse of the scripting execution types. Use the Execute
method for your run-time scripting to ensure that all attributes and values are available to the

op
script.
If the quality check-box is checked, the Execute method is similar to InTouch scripts with the
following conditional trigger types:

C
Periodic: Executes whenever the elapsed time evaluates as true.
 Data Change: Executes when a data value or quality changes between scans.
For the following trigger types, data changes between each scan are not evaluated, only the value
ot

at the beginning of each script is used for evaluation purposes. For example, if a Boolean attribute
changes from True to False to True again during a scan cycle, this change is not evaluated as a
data change as the value is True at the beginning of each scan cycle.
N

 OnTrue: Executes if the expression validates from a false on one scan to a true on the
next scan.
 OnFalse: Executes if the expression validates from a true on one scan to a false on the
next scan.
o

These scripts also have time-based considerations. A trigger period of 0 means that the script
D

executes 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. It is possible that a change in the system clock can change the interval between
executions of these scripts.
 WhileTrue: Executes scan to scan as long as the expression validates as true at the
beginning of the scan.
 WhileFalse: Executes scan to scan as long as the expression validates as false at the
beginning of the scan.
For example, a periodic script is set to run every 60 minutes. The script executes at 11:13 AM. We
expect it to execute 60 minutes later at 12:13 PM. However, a time synchronization event occurred
and the node’s time is adjusted from 11:33 AM to 11:30 AM.
The script still executes when the system time reaches 12:13 PM. But because of the time change,
the actual (True) time period that elapsed between executions is 63 minutes.

Application Server 2017 Update 3

10-8 Module 10 – Introduction to QuickScript.NET

OffScan
OffScan scripts are called when the object is taken OffScan. This script type is primarily used to
clean up the object and account for any needs to address as a result of the object no longer
executing.
If an object is taken OffScan, either directly, or indirectly because its engine is taken OffScan, all
in-progress asynchronous scripts for that object are requested to shut down by setting a Boolean
shutdown attribute for the script to true. A well-written script checks this attribute before and after
time-consuming operations. If the script takes more than 30 seconds to complete, a warning
appears in the logger that the script is not responding to the shutdown command. However, the
script is allowed to complete and is not terminated by force. This all takes place on the engine’s
main thread and could potentially hang the engine. During this time, the script might also time out
and as a result exits before executing all its logic.

Shutdown
Shutdown scripts are called when the object is about to be removed from memory, usually as a
result of the AppEngine stopping. Shutdown scripts are primarily used to destroy COM objects and

y
.NET objects and to free memory.

op
Language Definition
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the
case is preserved throughout editor sessions.
C
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.
ot

Examples:
Dim A; 'This is a single line comment
N

Dim B; {This is an example of a multi-line 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
o

end of a statement.
D

Note: For information on the QuickScript.NET operations, precedence of operators, variables,

control structures, and sample scripts, reference the Application Server Scripting Guide. This can
be found on any machine that has Application Server 2017 installed on it in the following location:
C:\Program Files\ArchestrA\Framework\Docs\1033.

Wonderware Training
 Section 1 – Introduction to Scripting 10-9

Autocomplete
QuickScript autocomplete is active by default in the Script Editor and incorporates several features
for use while authoring object and client scripts:
 Provides an autocomplete Attribute reference when you type a generic object name, such
as "me." Runtime attributes appear in an autocomplete list box.
 Provides method parameter help in an autocomplete list box including context-specific
suggestions covering definitions, keywords, script elements, and programmatic constructs
such as try ... catch or while ... endwhile.
 Automatic word completion of Attribute references, methods, programmatic constructs,
and other script elements.
These features serve as convenient documentation of method parameters and scripting syntax as
well as an enhanced input method.
Autocomplete displays a context-sensitive list of options for script elements, keywords, object and
attribute names, and programmatic constructs. Press Ctrl + space to display all available
autocomplete options and variables for the selected location in the script. You can identify the

y
context from the icons displayed with the list items.

op
Attribute References

Relative References
C
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.
ot

The following are valid relative references that refer to the current object:
N
o
D

Relative references are especially useful in templates because absolute references typically do
not apply or make sense.

Application Server 2017 Update 3

10-10 Module 10 – Introduction to QuickScript.NET

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

y
op
C
ot
N
o
D

Wonderware Training
 Lab 19 – Adding Auto Reconnect to the DDESuiteLinkClient Object 10-11

Lab 19 – Adding Auto Reconnect to the

DDESuiteLinkClient Object

Introduction
In this lab, you will configure the $gDDESuiteLinkClient to automatically reconnect to the data
source when the connection is lost. To do this, you will extend the object by adding attributes and
scripts. Using an attribute/script combination, you will also add additional diagnostic information
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:
 Create scripts in an object

y
 Create scripts with multiple execution types
 Add reconnect functionality to a $DDESuiteLinkClient object

op
C
ot
N
o
D

Application Server 2017 Update 3

10-12 Module 10 – Introduction to QuickScript.NET

Add the Auto Reconnect Functionality

First, you will create a script that will automatically reconnect to the data source when the
connection is lost.
1. In the ArchestrA IDE, Template Toolbox, Training\Global toolset, open the
$gDDESuiteLinkClient configuration editor.

y
op
2. On the Scripts tab, click the Add Script button.
3. Name the new script Reconnect and press Enter.
C
ot
N
o
D

Wonderware Training
 Lab 19 – Adding Auto Reconnect to the DDESuiteLinkClient Object 10-13

4. Configure the Reconnect script as follows:

Aliases: locked
Declarations: locked
Scripts: Execution type: Execute (default) and locked
Basics: locked
Expression: Me.ConnectionStatus <> 2
Trigger type: WhileTrue (default)
Trigger Period: 00:00:05.0000000
Script body: Me.Reconnect = true;

y
op
C
ot
N

This script will attempt to reconnect every 5 seconds, when not connected to the data source.
Now, you will validate the script syntax by using the Validate feature. If the script has a syntax
error, it will appear in an error message.
o

5. To the right of the Execution type drop-down list, click the Validate Script button.
D

If nothing happens, the validation is successful.

Application Server 2017 Update 3

10-14 Module 10 – Introduction to QuickScript.NET

Next, you will add an attribute to count the disconnections.

6. On the Attributes tab, create and configure a new attribute as follows:

Name: Disconnect.Cnt
Data type: Integer
Writeability: Calculated

Now, you will add a script to monitor the connection status.

y
7. On the Scripts tab, add a script named Disconnect.Monitor.

op
8. Configure the Disconnect.Monitor script as follows:

Aliases: locked
Declarations: locked C
Scripts: Execution type: Execute (default) and locked
Basics: locked
Expression: Me.ConnectionStatus <> 2
ot

Trigger type: OnTrue

Script body: Me.Disconnect.Cnt = Me.Disconnect.Cnt + 1;
N

This script will increase a counter by one every time the condition is true.
o
D

9. Click the Validate Script button.

Wonderware Training
 Lab 19 – Adding Auto Reconnect to the DDESuiteLinkClient Object 10-15

Now, you will add code within the same script under a different execution type that will run when
the object goes on scan.
10. While still in the Disconnect.Monitor script, change the Execution type to OnScan.
11. In the script body, enter:
Me.Disconnect.Cnt = 0;
This script will reset the counter to zero every time the object goes on scan.

y
Notice that the locking of the Aliases and Declarations did not change because you are still
in the same script.

op
12. Validate the script.
Notice the list of scripts on the left now lists the two scripts associated with this object and
displays an “x” in the column representing each execution type that contains a scripts.
C
ot
N

13. Save and close, and then check in the object with an appropriate comment.
o

The Check In dialog box reappears with an Object 1 of 1 completed message. Notice that
the changes propagated to both R_ProdPLC instances.
D

14. Click Close.

Application Server 2017 Update 3

10-16 Module 10 – Introduction to QuickScript.NET

15. Deploy R_PRODPLC1 and R_PRODPLC2.

y
op
C
When complete, the progress displays 100% completed.
ot
N
o
D

16. Click Close.

Wonderware Training
 Lab 19 – Adding Auto Reconnect to the DDESuiteLinkClient Object 10-17

Test the Scripts in Runtime

Next, you will use Object Viewer to verify the execution of the scripts.
17. In the Deployment view, open R_PRODPLC1 in Object Viewer.
18. Load your saved watch list, if necessary, and create a new watch window named
R_PRODPLC1, and then add the following attributes:
 ConnectionStatus
 Disconnect.Cnt
 Disconnect.Monitor.ExecutionCnt
 Reconnect.ExecutionCnt

y
op
C
ot
N
o
D

19. Save the watch list.

Application Server 2017 Update 3

10-18 Module 10 – Introduction to QuickScript.NET

20. In the SMC, Operations Integration Server Manager, expand

TrainingGalaxy\ProdPlatform.
21. Right-click OI.MBTCP.1 and select Deactivate.

y
op
A confirmation message appears.

C
ot

22. Click Yes to confirm deactivation.

N

Notice that the SMC now displays a red indicator icon, indicating the server has stopped.
o
D

Wonderware Training
 Lab 19 – Adding Auto Reconnect to the DDESuiteLinkClient Object 10-19

In Object Viewer, the watch list now indicates that the R_PRODPLC1 object is currently
disconnected (R_PRODPLC1.ConnectionStatus), the object has disconnected once
(R_PRODPLC1.Disconnect.Cnt), and how many times the object has tried to reconnect
(R_PRODPLC1.Reconnect.ExecutionCnt).

23. In the SMC, reactivate the OI.MBTCP.1.

y
op
C
ot
N

After a few seconds, your watch list will display that the data is once again connected.
o
D

Application Server 2017 Update 3

10-20 Module 10 – Introduction to QuickScript.NET

24. Add the following attributes to the watch window:

 ScanState
 ScanStateCmd

25. Set the ScanStateCmd attribute to False.

y
op
C
26. Click OK.
The ScanState now displays false.
ot
N
o
D

27. Set the ScanStateCmd attribute back to True.

The ScanState now displays true and the Disconnect.Cnt attribute has been reset to 0.

28. Save the watch list and minimize Object Viewer.

Wonderware Training
 Section 2 – Variables and Control Statements 10-21

Section 2 – Variables and Control Statements

This section describes the usage of variables and control statements in a script.

QuickScript.NET Variables
QuickScript .NET variables must be declared before they can be used in QuickScript .NET scripts.
Variables can be used on both the left and right side of statements and expressions.
Local variables or attributes can be used together in the same script. Variables declared within the
script body lose their value after the script is executed. Those declared in the script body cannot
be accessed by other scripts.
Variables declared in the Declarations area maintain their values throughout the lifetime of the
object that the script is associated with.
Each variable must be declared in the script by a separate DIM statement followed by a
semicolon. Enter DIM statements in the Declarations area of the Script tab page. The DIM

y
statement syntax is as follows:
DIM <variable_name> [ ( <upper_bound>

op
[, <upper_bound >[, < upper_bound >]] ) ]
[ AS <data_type> ];
where: C
DIM Required Keyword
<variable_name> Name that begins with a letter (A-Z or a-z) and whose remaining characters can
be any combination of letters (A-Z or a-z), digits (0-9) and underscores (_). The
ot

variable name is limited to 255 Unicode characters.

<upper_bound> Reference to the upper bound (a number between 1 and 2,147,483,647,
inclusive) of an array dimension. Three dimensions are supported in a DIM
statement, each being nested in the syntax structure. After the upper bound is
N

specified, it is fixed after the declaration. A statement similar to Visual Basic’s

ReDim is not supported.
The lower bound of each array dimension is always 1.
o

AS Optional keyword for declaring the variable’s datatype.

<data_type> Any one of the following 8 datatypes:
D

Boolean, Integer, ElapsedTime, Float, Double, String, Time, or

InternationalizedString
Data_type can also be a .NET data_type like System.Xml.XmlDocument or a
type defined in an imported script library
If you omit the AS clause from the DIM statement, the variable, by default, is
declared as an Integer datatype. For example:
DIM LocVar1;
is equivalent to:
DIM LocVar1 AS Integer;

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 (for example, attribute name, alias or name of an object
leveraged by the script), the variable name takes precedence over the other named entities. If the

Application Server 2017 Update 3

10-22 Module 10 – Introduction to QuickScript.NET

variable name is the same as an alias name, a warning message appears when the script is
validated to indicate that the alias is ignored.
The syntax for specifying the entire array is “[ ]” for both local array variables and for attribute
references. For example, to assign an attribute array to a local array, the syntax is:
locarr[] = tag.attr[];
DIM statements can be located anywhere in the script body, but they must precede the first
referencing script statement or expression. If a local variable is referenced before the DIM
statement, script validation done when you save the object containing the script prompts you to
define it.

Important: The validation mentioned above occurs only when you save the object containing the
script. This is not the script syntax validation done when you click the Validate Script button.

Do not cascade DIM statements. For example, the following examples are invalid:
DIM LocVar1 AS Integer, LocVar2 AS Float;

y
DIM LocVar3, LocVar4, LocVar5, AS String;
To declare multiple variables, you must enter separate DIM statements for each variable.

op
When used on the right side of an equation, declared local variables always cause expressions on
the left side to have Good quality. For example:
dim x as integer;
dim y as integer;
C
x = 5;
ot

y = 5;
me.attr = 5;
me.attr = x;
N

me.attr = x+y;
In each case of me.attr, quality is Good.
When you use a variable in an expression to the right of the operator, its Quality is treated as Good
o

for the purpose of data quality propagation.

D

You can use null to indicate that there is no object currently assigned to a variable. Using null has
the same meaning as the keyword "null" in C# or "nothing" in Visual Basic. Assigning null to a
variable makes the variable eligible for garbage collection. You may not use a variable whose
value is null. If you do, the script terminates and an error message appears in the logger. You may,
however, test a variable for null. For example:
IF myvar == null THEN ...
It is not possible to pass attributes as parameters for system objects. To work around this issue,
use a local variable as an intermediary or explicitly convert the attribute to a string using an
appropriate function call when calling the system object.
Float constants are applicable as values for variables of type float or double. For example, float
constants do not take the number of bytes into account. Script validation detects an overflow when
a float or double variable has been assigned a float constant that exceeds the maximum value.

Wonderware Training
 Section 2 – Variables and Control Statements 10-23

QuickScript.NET Control Structures

QuickScript .NET provides five primary control structures in the scripting environment:
 IF … THEN … ELSEIF … ELSE … ENDIF
 FOR … TO … STEP … NEXT Loop
 FOR EACH … IN … NEXT
 TRY ... CATCH
 WHILE Loop

IF … THEN … ELSEIF … ELSE … ENDIF

IF-THEN-ELSE-ENDIF conditionally executes various instructions based on the state of an
expression. The syntax is as follows:
IF <Boolean_expression> THEN;
[statements];
[ { ELSEIF;
[statements] } ];

y
[ ELSE;
[statements] ];

op
ENDIF;
where Boolean_expression is an expression that can be evaluated as a Boolean.
Depending on the data type returned by the expression, the expression is evaluated to constitute a
C
True or False state according to the following table:

Data Type Mapping

Boolean Directly used (no mapping needed)
ot

Integer Value = 0 evaluated as False

Value != 0 evaluated as True
Float Value = 0 evaluated as False
N

Value != 0 evaluated as True

Double Value = 0 evaluated as False
Value != 0 evaluated as True
o

String Cannot be mapped. Using an expression that results in a string type

as the Boolean_expression results in a script validation error.
D

Time Cannot be mapped. Using an expression that results in a time type as

the Boolean_expression results in a script validation error.
ElapsedTime Cannot be mapped. Using an expression that results in an elapsed
time type as the Boolean_expression results in a script validation error.
InternationalizedString Cannot be mapped. Using an expression that results in an
internationalized string time 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.
To help decide between multiple alternatives, an optional ELSEIF clause can be used as often as
needed. The ELSEIF clause mimics switch statements offered by other programming languages.

Application Server 2017 Update 3

10-24 Module 10 – Introduction to QuickScript.NET

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;
The following syntax is also supported:
IF <Boolean_expression> THEN;
[statements];
[ { ELSEIF;
[statements] } ];
[ ELSE;
[statements] ];
ENDIF;

y
ENDIF;
This approach nests a brand new IF compound statement within a previous one and requires an

op
additional ENDIF.

IF … THEN … ELSEIF … ELSE … ENDIF and Attribute Quality

C
When a Attribute value is copied to another Attribute value of the same type, the Attribute’s quality
is also copied. For example, the following two statements copy both value and quality:
me.Attribute2 = me.Attribute1;
me.Attribute2.value = me.Attribute1.value;
ot

If the Attribute has the quality BAD and only the value needs to be copied, use a temporary
variable to hold the value. For example:
Dim temp as Integer;
N

temp = me.Attribute1;
me.Attribute2 = temp;
If there is a comparison such as Attribute1 <> Attribute2 and one of the Attributes has the quality
BAD, then the statements within the IF control block are not executed. For example, assuming
o

Attribute1 has the quality BAD:

if me.Attribute1 <> me.Attribute2 then
D

me.Attribute2 = me.Attribute1;
endif;
In this script, the statement me.Attribute2 = me.Attribute1 is not executed because Attribute1 has
the quality BAD and comparing a BAD quality value with a good quality value is not defined/not
possible.
A better approach is to first verify the quality of Attribute1, as shown in the following example:
if(IsBad(me.Attribute1)) then
LogMessage("Attribute1 quality is bad, its value is not copied to Attribute2");
else
if me.Attribute1 <> me.Attribute2 then
me.Attribute2 = me.Attribute1;
endif;
endif;

Wonderware Training
 Section 2 – Variables and Control Statements 10-25

FOR … TO … STEP … NEXT Loop

FOR-NEXT performs 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, 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;

y
this holds true if loop is incrementing up, otherwise, if loop is decrementing, loop
termination occurs if analog_var is less than end_expression

op
 change_expression is an expression that defines 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
C
end_expression or the statements in the loop do 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
ot

 If STEP is not set, then change_expression defaults to 1 for increasing increments, and
defaults to -1 for decreasing increments
Exit the loop from within the body of the loop with the EXIT FOR statement.
N

The FOR loop is executed as follows:

1. analog_var is set equal to start_expression.
2. If change_expression is positive, the system tests to see if analog_var is greater than
o

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. If so, program execution exits the loop.
D

3. The statements in the body of the loop are executed. The loop can potentially be exited via the
EXIT FOR statement.
4. analog_var is incremented by 1,-1, or by change_expression if it is specified.
5. Steps 2 through 4 are repeated.

Note: FOR-NEXT loops can be nested. The number of levels of nesting possible depends on
memory and resource availability.

Application Server 2017 Update 3

10-26 Module 10 – Introduction to QuickScript.NET

FOR EACH … IN … NEXT

FOR-EACH loops can be used only with collections exposed by OLE Automation servers. A FOR-
EACH loop performs a function (or set of functions) within a script several times during a single
execution of a script. The general format of the FOR-EACH loop is as follows:
FOR EACH <object_variable> IN <collection_object >
[statements];
[EXIT FOR;];
[statements];
NEXT;
where:
 object_variable is a dimmed variable
 collection_object is a variable holding a collection object
As in the case of the FOR … TO loop, it is possible to exit the execution of the loop through the
statement EXIT FOR from within the loop.

y
TRY ... CATCH

op
TRY ... CATCH provides a way to handle some or all possible errors that may occur in a given
block of code, while still running rather than terminating the program. The TRY part of the code is
known as the try block. Deal with any exceptions in the CATCH part of the code, known as the
catch block.
C
The general format for TRY ... CATCH is as follows:
TRY
[try statements] ’guarded section
ot

CATCH
[catch statements]
N

ENDTRY;
where:
tryStatements
o

Statement(s) where an error can occur. Can be a compound statement. The tryStatement is a
guarded section.
D

catchStatements
Statement(s) to handle errors occurring in the associated Try block. Can be a compound
statement.

Note: Statements inside the Catch block may reference the reserved ERROR variable, which is a
.NET System.Exception thrown from the Try block. The statements in the Catch block run only if
an exception is thrown from the Try block.

TRY ... CATCH is executed as follows:

 Runtime error handling starts with TRY. Put code that might result in an error in the try
block.
 If no runtime error occurs, the script will run as usual. Catch block statements will be
ignored.

Wonderware Training
 Section 2 – Variables and Control Statements 10-27

 If a runtime error occurs, the rest of the try block does not execute.
 When a runtime error occurs, the program immediately jumps to the CATCH statement
and executes the catch block.
The simplest kind of exception handling is to stop the program, write out the exception message,
and continue the program.
The error variable is not a string, but a .NET object of System.Exception. This means you can
determine the type of exception, even with a simple CATCH statement. Call the GetType() method
to determine the exception type, and then perform the operation you want, similar to executing
multiple catch blocks.
Example:
dim command = new System.Data.SqlClient.SqlCommand;
dim reader as System.Data.SqlClient.SqlDataReader;
command.Connection = new System.Data.SqlClient.SqlConnection;
try

y
command.Connection.ConnectionString = "Integrated Security=SSPI";
command.CommandText="select * from sys.databases";

op
command.Connection.Open();
reader = command.ExecuteReader();

while reader.Read()
me.name = reader.GetString(0);
LogMessage(me.name);
C
endWhile;
catch
ot

LogMessage(error);
endtry;
if reader <> null and not reader.IsClosed then
N

reader.Close();
endif;
if command.Connection.State == System.Data.ConnectionState.Open
o

then
command.Connection.Close();
D

endif;

WHILE Loop
WHILE loop performs 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 in the
description of IF…THEN statements.
It is possible to exit the loop from the body of the loop through the EXIT WHILE statement.

Application Server 2017 Update 3

10-28 Module 10 – Introduction to QuickScript.NET

The WHILE loop is executed as follows:

 The script evaluates whether the Boolean_expression is true or not. If not, program
execution exits the loop and continues after the ENDWHILE statement.
 The statements in the body of the loop are executed. The loop can be exited through the
EXIT WHILE statement.
 Steps 1 through 2 are repeated.

Note: WHILE loops can be nested. The number of levels of nesting possible depends on memory
and resource availability.

Quality of Input, InputOutput, and Output Extensions

When the object is On Scan, the value and quality of the Inputextended attribute mirrors the quality
of the externally referenced attribute in the case of successful reads. The data quality of the
extended attribute is set to Bad when reads fail because of communication errors or datatype
conversion failures.

y
While the extended object is On Scan, it behaves as follows: If an external set (for example, from a

op
user) to the extended attribute causes either the value or quality to change, then a write of the
extended attribute’s value to the destination occurs during the next execute phase.
The quality must be Good or Uncertain for a write to occur. For writes to occur because of a quality
change, the quality change must be a transition from Bad or Initializing to Good or Uncertain. The
C
attribute called WriteValue is publicly exposed.
When the extended object is Off Scan, quality is always Bad and user sets are accepted.
ot
N
o
D

Wonderware Training
 Lab 20 – Scripting Valve Status 10-29

Lab 20 – Scripting Valve Status

Introduction
In this lab, you will add a script to the $Valve template to report all of the stages of the valve:
Open, Closed, and Traveling. You will create an attribute with an Array value that holds the list of
possible states of the valve and you will also add an integer value of the valve state.

Objectives
Upon completion of this lab, you will be able to:
 Use a script to calculate the state of a valve
 Create an attribute with an Array value

y
op
C
ot
N
o
D

Application Server 2017 Update 3

10-30 Module 10 – Introduction to QuickScript.NET

Add Support Attributes

First, you will modify the Open Limit Switch (OLS) to add a Not Open option. Then, you will add
attributes to read the Close Limit Switch (CLS) of the valve and hold the current state of the valve
(PV) to be calculated by a script. Next, you will add an array (PVStates) to hold the list of possible
states of the valve, making it easier to update the stages in the future, if necessary. Finally, you will
add an integer value of the valve state (PVState).
1. In the ArchestrA IDE, Template Toolbox, Training\Project toolset, open the $Valve
configuration editor.

y
op
C
ot
N
o

2. In the Attributes list, select OLS and modify the configuration as follows:
D

'False' label: Not Open and locked (default)

Wonderware Training
 Lab 20 – Scripting Valve Status 10-31

3. With OLS selected, click the Duplicate button, and then configure the new attribute as
follows:

Name: CLS
Description: Close Limit Switch and locked
'False' label: Not Closed and locked
'True' label: Closed and locked
I/O: checked (default)

y
op
C
4. Create and configure a new attribute as follows:
ot

Name: PV
Description: Valve State and locked
Data type: String
N

Writeability: Calculated
o
D

Application Server 2017 Update 3

10-32 Module 10 – Introduction to QuickScript.NET

5. Create and configure another attribute as follows:

Name: PVStates
Description: List of Valve States and locked
Data type: String (default)
Array: checked
# of elements: 4
Writeability: Object writeable
Initial value: locked
1 Closed
2 Open
3 Traveling
4 Fault

y
op
C
ot

6. Create and configure another attribute as follows:

Name: PVState
N

Description: Integer Value of Valve State and locked

Data type: Integer
Array:
o

unchecked
Writeability: Object writeable (default)
D

Initial value: unlocked

Wonderware Training
 Lab 20 – Scripting Valve Status 10-33

The attributes are now visible in the attribute list.

y
Add Script to Calculate Valve State
op
C
Now, you will add a script to the $Valve template that will calculate the state of the valve based on
the values of the Open Limit Switch (OLS) and Close Limit Switch (CLS).
ot

7. On the Scripts tab, click the Add Script button, and then name the new script ValveStatus.
8. Configure the ValveStatus script as follows:
N

Aliases: locked
Declarations: locked
Execution type: Execute (default) and locked
o

Basics: locked
Expression: Me.OLS or Me.CLS
D

Trigger type: DataChange

Application Server 2017 Update 3

10-34 Module 10 – Introduction to QuickScript.NET

9. In the script body, enter the following:

Note: For your convenience, you can find the script body in
C:\Training\Lab 20 – Scripting Valve Status.txt.

Script Body: if (not Me.OLS and Me.CLS)

then Me.PVstate = 1; 'Closed
elseif (Me.OLS and not Me.CLS)
then Me.PVstate = 2; 'Open
elseif (not me.OLS and not Me.CLS)
then Me.PVstate = 3; 'Traveling
else
Me.PVstate = 4; 'Fault
endif;

y
op
Me.PV = Me.PVStates[Me.PVState];

C
ot
N
o

10. Validate the script.

D

Wonderware Training
 Lab 20 – Scripting Valve Status 10-35

11. Save and close, and then check in the object with an appropriate comment.
The Check In dialog box reappears with an Object 1 of 1 completed message. Notice that
the changes have been propagated to the inlet and outlet valves.

y
op
12. Click Close.
The valves all indicate they have configuration changes that need to be deployed.
C
ot
N
o
D

13. Deploy the valves.

Application Server 2017 Update 3

10-36 Module 10 – Introduction to QuickScript.NET

Test in Runtime
Now, you will use Object Viewer to test the script in runtime.
14. In Deployment view, open Inlet1_001 in Object Viewer.
15. Add a new watch window and name it ValveStatus.
16. Add the following attributes to the watch window:
 CLS
 OLS
 PV
17. Verify the results as the valve opens and closes.

y
18. Save the watch list and minimize Object Viewer.

op
C
ot
N
o
D

Wonderware Training
 Lab 21 – Scripting Custom Alarms 10-37

Lab 21 – Scripting Custom Alarms

Introduction
In this lab, you will configure two new attributes with Alarm features to monitor the flow to the
transfer pumps within the $Mixer template. Additionally, you will add a script to monitor the inlet
valves and transfer pumps to make sure they are operating correctly and, if they are not, trigger an
alarm.

Objectives
Upon completion of this lab, you will be able to:
 Use attributes and scripting to determine custom alarm conditions

y
op
C
ot
N
o
D

Application Server 2017 Update 3

10-38 Module 10 – Introduction to QuickScript.NET

Create and Configure Attributes

First, you will create two attributes that will be used in a script to trigger alarms.
1. In the ArchestrA IDE, Template Toolbox, Training\Project toolset, open the $Mixer
configuration editor.
2. Create and configure a new attribute as follows:

Name: Flow.Alarm.Pump1
Description: Transfer Pump 1 - Faulty Flow Condition and locked
Data type: Boolean (default)
Writeability: Calculated
State alarm: checked and locked
Category: Process
Priority: 500 (default)
Active alarm state: True (default)

y
op
C
ot
N
o
D

Wonderware Training
 Lab 21 – Scripting Custom Alarms 10-39

3. Duplicate Flow.Alarm.Pump1, and then change the Description field to

Transfer Pump 2 - Faulty Flow Condition and lock it.

y
op
C
ot

The attributes are now visible in the attribute list.

N
o
D

Application Server 2017 Update 3

10-40 Module 10 – Introduction to QuickScript.NET

Add a Script to Calculate Alarm Conditions

Next, you will add a script to the $Mixer template to check the operation of the transfer pumps.
4. On the Scripts tab, add a new script named Flow.Alarm.Condition.
5. Configure the Flow.Alarm.Condition script as follows:

Aliases: locked
Declarations: locked
Execution type: Execute (default) and locked
Basics: locked
Expression: Me.Inlet1.PVState == 1 or Me.Inlet2.PVState == 1 or Me.Pump1.PV or
Me.Pump2.PV
Trigger type: While True (default)

y
op
C
ot
N
o
D

Wonderware Training
 Lab 21 – Scripting Custom Alarms 10-41

6. In the script body, enter the following:

Note: For your convenience you can find the script body in
C:\Training\Lab 21 – Scripting Custom Alarms.txt.

Script Body: If (Me.Inlet1.PVstate == 1 and Me.Pump1.PV) then

Me.Flow.Alarm.Pump1 = true;
Else
Me.Flow.Alarm.Pump1 = false;
Endif;

If (Me.Inlet2.PVstate == 1 and Me.Pump2.PV) then

Me.Flow.Alarm.Pump2 = true;

y
Else
Me.Flow.Alarm.Pump2 = false;

op
Endif;

C
ot
N
o
D

This script separately checks the operation of the transfer pumps by checking if the inlet valve
is closed and the transfer pump are running at the same time, in which case there is a flow
problem.
7. Validate the script.

Application Server 2017 Update 3

10-42 Module 10 – Introduction to QuickScript.NET

8. In the Execution type drop-down list, select OnScan.

9. In the script body, enter the following:

Note: For your convenience you can find the script body in
C:\Training\Lab 21 – Scripting Custom Alarms.txt.

Me.Flow.Alarm.Pump1 = false;
Me.Flow.Alarm.Pump2 = false;

y
10. Validate the script.

op
Notice that the Flow.Alarm.Condition script now has OnScan and Execute scripts.

C
ot
N

11. Save and close, and then check in the objects with an appropriate comment.
The Check In dialog box reappears with an Object 1 of 1 completed message. Notice that the
changes were propagated to both mixers.
o
D

12. Click Close.

The Deployment view displays that both mixers need to be redeployed.
13. Deploy Mixer100 and Mixer200 and leave the default options.

Wonderware Training
 Lab 21 – Scripting Custom Alarms 10-43

Test in Runtime
Now, you will test the new script in runtime.
14. In the Deployment view, open Mixer100 in Object Viewer.
15. Add a new watch window and name it Custom Alarms.
16. Add the following attributes to the watch window:
 Inlet1_001.PV
 Pump1_001.PV.Msg
 Pump1_001.CMD
 Mixer100.Flow.Alarm.Pump1
 Mixer100.Flow.Alarm.Pump1.InAlarm
 Inlet2_001.PV
 Pump2_001.CMD
 Pump2_001.PV.Msg

y
 Mixer100.Flow.Alarm.Pump2
 Mixer100.Flow.Alarm.Pump2.InAlarm

op
C
ot
N

17. Save the watch list.

Now, you will create a condition that will trigger an alarm.
o

18. When Inlet1_001.PV is closed, set Pump1_001.CMD to True to trigger an alarm.

D

Application Server 2017 Update 3

10-44 Module 10 – Introduction to QuickScript.NET

19. Set Pump1_001.CMD to False to reset it.

20. Repeat the steps for Inlet2_001.PV.

y
op
C
ot
N
o
D

Wonderware Training
 y
op
Module 11 – Galaxy Backup and Restore
C
Section 1 – Galaxy Backup and Restore 11-3
ot
N
o
D
11-2 Module 11 – Galaxy Backup and Restore

Module Objectives
 Use the System Management Console to back up and restore a Galaxy

y
op
C
ot
N
o
D

Wonderware Training
 Section 1 – Galaxy Backup and Restore 11-3

Section 1 – Galaxy Backup and Restore

This section briefly describes the SMC and explains how to back up and restore operations using
the Galaxy Database manager. It includes a discussion on how to create a new Galaxy from a
backup file.

System Management Console

The System Management Console is used to help system integrators and system administrators
perform administrative tasks and diagnostics on an ArchestrA application. Its console tree lists the
items available for these tasks. One of these items is the Galaxy Database Manager used to back
up and restore a Galaxy.

y
op
C
ot
N
o
D

Galaxy Database Manager

You use the Galaxy Database Manager to back up and restore a Galaxy. Backing up a Galaxy
creates a single backup file (.cab extension) containing all the files, configuration data, and object
deployment states required to recreate the Galaxy in an empty Galaxy Repository.
During the backup, no write operations are allowed to the Galaxy Repository. If write activity is
occurring, you should back up at a later time.
Restoring a Galaxy uses the backup file to overwrite an existing Galaxy or to create the backed up
Galaxy in a different Galaxy Repository. The restore process prompts you for confirmation before a
Galaxy is overwritten.

Application Server 2017 Update 3

11-4 Module 11 – Galaxy Backup and Restore

All objects should be undeployed before beginning to restore a Galaxy. During the restore, no
clients can use the Galaxy Repository. If these conditions are not acceptable, you should restore
at a later time.

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.
To back up a Galaxy, expand Galaxy Database Manager. Select the Galaxy to backup, and then
on the Action menu, select Backup.

y
op
C
ot
N
o

A warning appears.
D

Wonderware Training
 Section 1 – Galaxy Backup and Restore 11-5

Acknowledge the warning and name the .cab file to be created.

y
Click Save.
op
C
The Galaxy Database Manager progress appears.
ot
N
o
D

When the backup is complete, click Close.

Application Server 2017 Update 3

11-6 Module 11 – Galaxy Backup and Restore

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 (x86)\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.
Select the existing Galaxy, and then on the Action menu, click Restore.

y
op
C
ot
N

The Galaxy Database Manager dialog box appears.

o
D

Wonderware Training
 Section 1 – Galaxy Backup and Restore 11-7

Click Yes to continue restoring and No to terminate the restore function.

If you choose Yes, 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.

y
op
C
ot
N
o
D

Application Server 2017 Update 3

11-8 Module 11 – Galaxy Backup and Restore

y
op
C
ot
N
o
D

Wonderware Training