Wonderware Training

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

y
Training Manual
Revision A

op
March 2018
Part Number 11-GM-10075

C
ot
N

Application Server 2017

o
D
INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

© 2018 AVEVA Group Plc. All rights reserved.

y
op
C
ot
N
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

y
Section 6 – System Requirements and Licensing ........................................... 1-49

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

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

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

Section 1 – The Plant Model.............................................................................. 3-3
Section 2 – The Deployment Model................................................................... 3-5
Lab 3 – Creating the Plant and Deployment Models ....................................... 3-11
Section 3 – System Management Console...................................................... 3-27

Module 4
C
Section 4 – The Runtime Environment ............................................................ 3-35
Lab 4 – Using Object Viewer ........................................................................... 3-43
Section 5 – Data Simulation............................................................................. 3-55
Lab 5 – Configuring for Data Simulation .......................................................... 3-57

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-29
Lab 7 – Configuring Change Control and Propagation .................................... 4-33
Section 4 – Containment.................................................................................. 4-43
Lab 8 – Modeling the Mixer.............................................................................. 4-47
N

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

Section 1 – Device Integration Servers.............................................................. 5-3
Lab 9 – Configuring the OI Server ..................................................................... 5-7
Section 2 – Device Integration Objects............................................................ 5-15
Lab 10 – Configuring the Device Integration Object ........................................ 5-21
o

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
D

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

2 Application Server 2017

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

y
Lab 18 – Implementing Object Security ........................................................... 9-41

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

Section 1 – Introduction to Scripting................................................................. 10-3

op
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

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

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

C
ot
N
o
D

Wonderware Training
 y
op
C
Section 1 – Course Introduction
Module 1 – Introduction
1-3
ot
Section 2 – System Platform Overview 1-9
Section 3 – Application Server Overview 1-13
Lab 1 – Creating the Galaxy 1-17
N

Section 4 – The ArchestrA IDE 1-21

Section 5 – Automation Objects 1-31
Lab 2 – Creating Global Derived Templates 1-43
Section 6 – System Requirements and Licensing 1-51
o
D
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 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 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

y
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,

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

Objectives
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
 Implement .NET Scripting to enhance application functionality
 Back up and restore an application
N

Audience
Individuals who need to configure or modify Application Server applications

Prerequisites
o

Knowledge of the following tools, features, and technologies is required:

 Industrial automation software concepts
D

Application Server 2017

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,

y
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

op
and how to create one.
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.
Section 5 – Automation Objects
This section describes automation objects, templates, and instances. It discusses the Object

C
Editor, explains the different states of automation objects and operations when editing objects,
and gives a brief explanation of Object Wizards.
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
ot
licensed.

Module 2 – Application Planning

Section 1 – Application Server Project Workflow
This section describes the suggested project workflow.
N

Section 2 – Case Study

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

Module 3 – Application Infrastructure

o

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

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

y
Section 1 – Introduction to Application Objects
This section describes the application objects in the Galaxy and discusses the basic

op
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
binding capabilities.
Section 3 – Change Control and Propagation
This section describes attribute locking and unlocking. It also discusses how template

Section 4 – Containment
C
changes can propagate to previously derived objects.

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
configuration of an OI Server to a Controller.
Section 2 – Device Integration Objects
N

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

Section 4 – Device Integration Redundancy

This section describes DI redundancy and explains how to configure a Redundant DI Object.
D

Module 6 – History
Section 1 – Historizing Data for Application Server
This section describes how Process 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

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 Process Historian,
as well as how to retrieve alarm history from SQL Server.

Module 8 – Object Management

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

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

Module 9 – Security
Section 1 – Security Overview

and operational permissions.

Section 2 – Object Security C
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

This section describes the security classifications for object attributes and discusses the
security audit trail.
ot
Module 10 – Introduction to QuickScript.NET
Section 1 – Introduction to Scripting
This section describes the scripting environment and basic scripting syntax. It also discusses
the execution types and triggers.
N

Section 2 – Variables and Control Statements

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

Module 11 – Galaxy Backup and Restore

Section 1 – Galaxy Backup and Restore
o

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

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

y
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,

op
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.
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
services for the multi-user, object-oriented platform.

C
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.
ot
N
o
D

Application Server 2017

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


C
Application Server is the heart of System Platform. It provides an object-oriented
framework with tools for developing and deploying applications.
Process 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.
ot
 Device Integration Servers are drivers for communicating with third-party controllers.
These 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:
 Supervisory clients run the operator interface and provide real-time access to
Application Server data, alarms, and events. There are two supervisory client products,
N

based on different technologies. Both can coexist in the same System Platform solution.
 Operations Management Interface for System Platform has a rapid-design
visualization framework with tools, and provides the ability to automatically navigate
and display graphics based on the application's data model.
 InTouch for System Platform is based on traditional development tools to create
displays and corresponding navigation.
o

 Process Historian Client is a collection of tools for accessing and reporting on data
historized with Process Historian. This client includes a Trend application for plotting data
on a graphical display, a Query application for constructing SQL queries through a point-
D

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

y


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

op
web service by means of a script.

ArchestrA Technology
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-
oriented design. It is built on .NET and leverages the Microsoft Framework for the industrial
automation world.


C
ArchestrA provides the following system services:
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
 Centralized security services with support for multi-user environments for development
and runtime
N

 Version management for every object in the application, including logging of development
operations
Most of these services are exposed, configured, and managed by Application Server.
o
D

Application Server 2017

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

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

op
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
allows the extension and enhancement of your application through integration with the .NET
Framework, particularly through a powerful scripting engine.
Applications created with Application Server have distributed capabilities by nature. Going from

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

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
 Multi-user development environment
 Self-documenting objects and versioning
N

 Security features to prevent users from performing unauthorized activities within the
development and runtime environments
 Redundancy capabilities for the application and for I/O communications
 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
o


HMIs
D

Application Server 2017

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

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

op
The Galaxy and the Galaxy Repository
A Galaxy is the entire application. It is the project database and configuration information, as well
as the single logical name space of your deployed application (runtime environment). It is
composed of:
 A collection of objects that represent all your physical and logical entities in your

 C
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
A common set of system-level policies that all components and objects comply with, such
as security, alarm, and communications settings
ot
The Galaxy Repository software, a Windows Service, manages the development and deployment
of the Galaxy. The project database is hosted in the same computer where the Galaxy Repository
software is installed.

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

For runtime, the objects in the Galaxy can be deployed to multiple computers for load balancing,
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
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
o

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

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


C
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.
Create a new Galaxy in the specified Galaxy Repository node.
ot
 Delete the selected Galaxy from the specified Galaxy Repository node. As a safety
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

Application Server 2017

1-14 Module 1 – Introduction

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

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

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 ArchestrA IDE. This Galaxy will be
used during the class.

Objectives

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

op
C
ot
N
o
D

Application Server 2017

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
The New Galaxy dialog box appears.
C
ot
3. In the Galaxy name field, enter TrainingGalaxy.
4. In the Galaxy type drop-down list, select Default_Empty.cab.
N

5. Click Create.
o
D

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.

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

Note: Check to make sure there are no error messages.

C
ot
N

7. Click Close.
o
D

Application Server 2017

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.

C
The Connect To Galaxy dialog box closes and, after a few seconds, the ArchestrA IDE
opens.
ot
N
o
D

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

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,

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

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

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

y
 I/O communication management
 Global graphic styles
 Time master computer for time synchronization across all Galaxy nodes

op
 Alarms and events logging parameters
 User preferences
 Multi-Galaxy communications
When working with objects, the ArchestrA IDE allows:
 Creation of new objects
 Configuration of existing objects, such as I/O points, alarm definitions, and process data to


historize

C
Check-out/Check-in functionality for versioning control
Deployment and undeployment of objects
View object properties, such as error and warning messages, as well as cross-reference
information
ot
 Upload changes to the runtime version of the object to the configuration database
The ArchestrA IDE also includes import and export capabilities, including:
 Objects
 Global graphic styles
 Script function libraries, such as .NET assemblies to use within a script
N

 Localization strings to easily translate text between different languages

Toolboxes and Application Views

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
o

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
D

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

y
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)

op
 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
The other views included with the ArchestrA IDE are:
 IO Device Mapping – Displays the I/O references configured through the IO Devices
view; it allows validation and override of the references

object templates and instances
C
Operations – Displays the results of manually validating the configuration of automation

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

View menu
 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

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

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

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

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
N

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

Containment relationships between templates can be configured and displayed within this toolbox.
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
D

$Mixer, the agitator template is displayed as Agitator instead of $Mixer.Agitator.

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

Wonderware Training
 Section 4 – The ArchestrA IDE 1-23

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.

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

y
within automation objects are not displayed in this toolbox.

op
C
ot
N
o

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
D

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.

Application Server 2017

1-24 Module 1 – Introduction

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.

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;

y
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

op
templates.

C
ot
N
o

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

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

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
D

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

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
templates as the top-level objects.
Base templates and protected derived templates display a small orange lock icon to the left of the
N

object icon. The configuration of these objects is read-only, but you can still create writeable
derived templates and instances from them.
Any base template that has not been derived is located in the Unused Base Templates folder.
The Derivation view helps identify which objects will be impacted by the propagation of changes.
o
D

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

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

The IO Devices view does not display the containment or hosting relationship between the objects;
contained objects display their hierarchical name in brackets.
D

Application Server 2017

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

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

op
C
ot

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

N

 System Objects – Used to build the infrastructure of the application. They represent the
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
o

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
D


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
new application objects from scratch using ArchestrA Object Toolkit; though knowledge of C# and
Visual Studio is required to use the toolkit.

Application Server 2017

1-30 Module 1 – Introduction

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
All automation objects include the following features and configuration options:
ot
 Inputs and Outputs – References to real-time I/O data from the field or other objects in
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
flow rates or defining complex alarm conditions.
N

 Historical Configuration – Specify which data points in the object will be historized by the
Process 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
o

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

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

Wonderware Training
 Section 5 – Automation Objects 1-31

 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
Types of Automation Objects

C
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
automation objects, each serving a distinct function within the Galaxy.
ot
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
toolset to the Device Integration toolset does not make the $Area object a device integration
object.
N

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

Application Server 2017

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

y
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

op
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.
 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
commands for all basic database transactions such as select, insert, update and delete


records.

C
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
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
of C# and Visual Studio is required to use the toolkit.
N

Device Integration Objects

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
speaks the actual controller protocol, like Modbus TCP or DH+.
Application Server provides out-of-the-box communication with other applications through the
o

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

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

y
to multiple controllers.
 Redundant Device Integration Object ($RedundantDIObject) – This object allows the
configuration of redundant communication channels from your Galaxy to the controllers. It

op
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.
 InTouch Proxy Object ($InTouchProxy) – An object useful in "hybrid" installations,
where System Platform coexist with legacy, tag-based InTouch applications. It provides a
way of integrating legacy InTouch applications to your Galaxy; it sits on top of your tag-

C
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
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:
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).
N
o

At present, Application Server provides the following System Objects:

D

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

Application Server 2017

1-34 Module 1 – Introduction

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

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

op
 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
applications (InTouchViewApp objects) to the operator stations.
 InTouch View Application Object ($InTouchViewApp) – This object holds the
operator's graphical interface (HMI). This is your visualization application, which includes
the windows and ArchestrA Graphics that comprise your operator interface. The
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, such as security.

Templates and Instances

C
Automation objects are classified into templates and instances. Templates allow the configuration
of reusable standards, while instances implement the standards.
ot
 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.
 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
N

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;
o

template objects are configuration-only and cannot be deployed.

D

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

y
environments

 Base templates are created with the ArchestrA Object Toolkit while derived templates and
instances are created within the ArchestrA IDE.

op
 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.
 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
created with the toolkit; device integration and system objects cannot be created with


the toolkit).

C
Base Templates contain predefined, built-in attributes and functionality; these cannot be
removed/deleted. Derived templates and instances inherit all attributes, scripts, and
configuration settings from the parent template; attribute and configuration values might
be modified, but not removed/deleted.
Base Templates are read-only and cannot be changed. Derived templates and instances
ot
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).
N
o
D

Application Server 2017

1-36 Module 1 – Introduction

 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
When deriving objects, note that:

C
Every derivation hierarchy starts with a base template
ot
 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
 There is no limit on the number of levels of derivation
 The parent-child relationship between objects in the derivation hierarchy cannot be broken
N

or rearranged

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
o

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

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.

Wonderware Training
 Section 5 – Automation Objects 1-37

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
The configuration editor of automation objects group attributes in tabs based on functionality.


C
There are four tabs that are common to all objects:
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,
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
ot
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.
Other configuration tabs might be available in the editor depending on the object. For example, the
$Area object includes a fifth tab named 'General' with several area-specific configuration
N

attributes.

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

The following are deployment status indicators for object instances; these overlay icons appear in
the top-left corner of the object's icon:
D

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.

Application Server 2017

1-38 Module 1 – Introduction

Overlay Icon Example Description

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
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
templates has been imported to the Galaxy.

The following are configuration status indicators for object templates and instances; these overlay icons

y
appear on the bottom-right corner of the object's icon:

Overlay Icon Example Description

op
[No Icon] Normal state of an object. There are no configuration warnings or errors.

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
and the object cannot be deployed.

C
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
object first, to narrow your options.

Editing Objects
ot
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
N

 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
 Checked out objects can be undone to revert the last checked in state; only the user that
o

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
D

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

Wonderware Training
 Section 5 – Automation Objects 1-39

Object Wizards
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
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,
or modify existing instances. You open an instance and answer a series of prompts or
questions.

y
 Use the Configure New Asset editor to create and configure instances and a
representative symbol by dragging an associated symbol into a graphic, and then
answering a series of prompts or questions.

op
Object Wizards consist of a series of user-selectable choices and options that are used to
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
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

C
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
ot
configure instances reduces the amount of product knowledge and training that is required.
N
o
D

Application Server 2017

1-40 Module 1 – Introduction

y
op
C
ot
N
o
D

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 ArchestrA IDE. These
derived templates will be used in the class 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.

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

op
 Create a new template toolset to organize templates
 Create a derived template
 Hide a template toolset

C
ot
N
o
D

Application Server 2017

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
C
ot
2. Rename the new toolset Training.
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 folder 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.

y
op
4. Rename the new toolset Global.

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

Application Server 2017

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

1-46 Module 1 – Introduction

11. Expand the System template toolset.

y
op
12. Create four new derived templates from the following base templates:
Base Template Derived Template
$AppEngine $gAppEngine
$Area $gArea
$ViewEngine
$WinPlatform
$gViewEngine
$gWinPlatform

C
The Template Toolbox now displays the four new derived templates in the System template
toolset.
ot
N
o

Note: You will not create a derived template from $InTouchViewApp or $ViewApp because
D

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
C
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.
14. Right-click the Device Integration template toolset and select Hide.
ot
N

15. Hide the System template toolset.

o
D

Application Server 2017

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

System Platform Computer Roles

A complete implementation of System Platform and its Clients involves many computer roles

y
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

op
combined on a single computer, depending on the size of the application and the hardware
resources available.

C
ot
N

The possible computer roles on a System Platform implementation are:

 Galaxy Repository – Runs the Galaxy Repository service and hosts the configuration
project database. There is only one Galaxy Repository per Galaxy.
 Engineering Station – Runs the tools necessary to develop and configure the
application, such as the ArchestrA IDE and the InTouch development tools. There can be
multiple engineering stations for multi-user development teams.
o

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

 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

1-50 Module 1 – Introduction

 Process Historian Server – Runs the Process 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 Process Historian Client
concurrent license, or both.
Workstation – Computer on the business network that can access reports in Information

y

Server through a web browser.
Based on these computer roles, the following diagram illustrates the Application Server

op
components that need to be installed and deployed on each computer.

C
ot

The WinPlatform objects are required on those computers to either host other automation objects
N

in the Galaxy (Application Object Servers, Visualization Stations) or for real-time communication to
those objects (Galaxy Repository, Engineering Stations, Visualization Stations, Information
Server), or both.
o
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

y
The following table lists supported and preferred software requirements for various nodes in your
system:

op
Development Galaxy Automation Supervisory
(ArchestrA IDE) Repository Object Server Client
Windows Server Preferred Preferred Preferred Supported
Windows Workstation Supported Supported Supported Preferred
SQL Server --- Required --- ---
.NET Framework Required Required Required Required

Minimum Hardware Requirements

C
The following table lists minimum hardware requirements for server nodes, such as Historian, the
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
Medium
4 8 200 1024 x 768 1000
25K-50K I/O per node
N

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

You can use all products on a single node. An All-in-One node includes Application Server,
InTouch, Process Historian, Process Historian Client, and Licensing components. The following
table lists the minimum hardware requirements for an All-in-One node:
o

CPU RAM Storage Display Network

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

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

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

Application Server 2017

1-52 Module 1 – Introduction

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

y
connections. Please contact your sales representative for more information.
System Platform licenses with 25K I/O points or less do not include a Microsoft SQL Server
Standard license.

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

Supervisory Client
A Supervisory Client license enables the use of both Operations Management Interface for

C
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 web clients (InTouch Access Anywhere and InTouch Web
Client).
ot
Activated Licensing
System Platform is license-enforced using an activated licensing framework with an activation
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.
N

 License Manager: Web-based user interface for accessing and maintaining licenses.
For more information about licensing components, refer to your product documentation.

ArchestrA Network Account

An important requirement when implementing System Platform is the correct setup of the
o

ArchestrA Network Account. This account 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
D

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

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

 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.
 Password must not expire or change. If the password expires or is changed, all
communications between Wonderware software will cease.
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
Directory user. All subsequent Wonderware software installed on that same computer will

y
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

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

C
ot
N
o
D

Application Server 2017

1-54 Module 1 – Introduction

y
op
C
ot
N
o
D

Wonderware Training
 y
op
C
Module 2 – Application Planning
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

y
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

op
Galaxy.

C
ot
N

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

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

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

Application Server 2017

2-4 Module 2 – Application Planning

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

y
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
security model for the runtime environment. Which users can write to attributes on which

op
objects? (for example, who can open a valve or change a setpoint) Who can acknowledge
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.
 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

C
objects necessary to deploy the Galaxy to the production environment. A testing
deployment model will be needed while creating and testing the Galaxy.
ot
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 class 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.

y
Factory Layout
The factory example for this training course is divided in four main sections or areas: Receiving,

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

C
ot
N

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
o

Production and Packaging areas.

D

Application Server 2017

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

y
 Two transfer pumps:
 Transfer Pump 1 (Pump1): Used in conjunction with Inlet Valve 1 to add the first
material into the tank

op
 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
for this device
 Two transmitters:
 Level Transmitter (Level): Indicates the current level of the tank

tank

C
Temperature Transmitter (Temperature): Indicates the current temperature of the
ot
N

Equipment Signal I/O Type Range Eng. Units

Level Transmitter MixerX00.Level.PV I Float RAW: 0 - 4095 Liters
o

EU: 0 - 250
Temperature Transmitter MixerX00.Temperature.PV I Float RAW: 0 - 4095 Celsius
EU: 0 - 250
D

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

y
Agitator MixerX00.Agitator.PV I Boolean - -
MixerX00.Agitator.CMD IO Boolean - -
MixerX00.Agitator.Speed.PV I Float EU: 0 - 500 Rpm

op
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
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
scaled to the corresponding engineering units (0 - 100 Liters, 0 - 250 Celsius, respectively).
Each valve has three signals:



C
A Close Limit Switch (CLS) to indicate if the valve is fully closed
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:
 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
N

 A Speed Process Value (Speed.PV) to indicate how fast the motor is running, when the
agitator is on
 A Speed Setpoint (Speed.SP) to tell the agitator how fast the motor should run, when it is
on

Note: The simulation provided with this training course includes four Mixers named Mixer100,
o

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

Application Server 2017

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.

y
After the tank is empty, the simulation automatically starts over.

op
the following happens:



C
During the running of a batch, a complete run of the four steps or stages from beginning to finish,

The level and temperature of the tank are available, as well as the temperatures.
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
Section 1 – The Plant Model
C
Module 3 – Application Infrastructure
3-3
ot
Section 2 – The Deployment Model 3-5
Lab 3 – Creating the Plant and Deployment Models 3-11
Section 3 – System Management Console 3-27
N

Section 4 – The Runtime Environment 3-35

Lab 4 – Using Object Viewer 3-43
Section 5 – Data Simulation 3-55
Lab 5 – Configuring for Data Simulation 3-57
o
D
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

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

op
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
 Sections are divided in areas
 Areas are divided in production lines
 Production lines are divided in manufacturing cells

C
ot
The plant model is also how alarms are distributed in the system; for example, if the production
N

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
inherent in the plant model.
Using the ArchestrA IDE, the plant model is built using the application Model view (for more
information see Module 1, “The Model View”).
o
D

Application Server 2017

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.

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

The Area Object

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

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
D

 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

y
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

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

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

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

example, a new version of a base template will include a new version of its underlined software, so
even if you have not changed the configuration of its instances, redeployment will be necessary to
send the new software to the runtime environment.
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.
o

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
Module 1, “Object States”).
D

To be able to deploy automation objects, you must define the Deployment Model for the Galaxy.

Application Server 2017

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

y
deployment model. Afterwards, you distribute the rest of your objects based on a hosting
relationship between all objects.

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

communication between objects hosted in the same engine.

 AppEngine objects host Area objects for alarm grouping and filtering.
 Area objects host Application objects, which primarily represent the equipment in the
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.
o

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

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 Module 1, “The Deployment View”).

y
op
C
ot
N

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

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

Application Server 2017

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)

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

op
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
 On the deployment model, engines are hosted on it
The Galaxy Repository requires a special instance of the WinPlatform object that handles GR-
specific operations. This instance must be the first object to be deployed from the Galaxy, and

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

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.

The AppEngine Object

o

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

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

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.

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

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 class. The Model view will be used to represent the physical

y
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. After building the

op
deployment model, you will use the Deployment view to deploy the instances.

Objectives
Upon completion of this lab, you will be able to:
 Create instances



C
Create a plant model for a Galaxy
Create a deployment model for a Galaxy
Deploy instances to the runtime environment
ot
N
o
D

Application Server 2017

3-12 Module 3 – Application Infrastructure

Create the Plant Model

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

y
op
C
ot
N
o

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
D

operation you are trying to run. Different application views are used throughout the remainder
of this class.

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
C
The instance appears in the Model view with the default name of gArea_001.
ot
4. Rename the instance Receiving.
N
o
D

Application Server 2017

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
 Packaging
 Shipping
N
o
D

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.

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

7. In the Model view, drag the Line1 area object onto the Production area object.
Line1 is now assigned to the Production area.

y
You can also create an assignment by right-clicking on an instance and assigning it to an area.

op
8. Right-click Line2 and select Assign To.

C
ot
The Assign To dialog box appears.
9. In the drop-down list, select Production.
N
o
D

Application Server 2017

3-16 Module 3 – Application Infrastructure

10. Click Assign.

Line2 is now assigned to the Production area.

y
The Model view now shows the logical layout of the plant that will be used throughout the

op
remainder of the class.

C
ot
Create the Deployment Model
Now, you will use the Deployment view, which displays how the application is distributed across
the available networked computers.
11. Click the Deployment tab to display the Deployment view, and then expand TrainingGalaxy
and the Unassigned Host folder, if necessary.
N
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
13. In the Deployment view, rename the new instance GRPlatform.
ot
N
o

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

Application Server 2017

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
op
You will now configure the newly created platform with the remote computer name.
15. Double-click ProdPlatform to open its configuration editor.

C
In the Deployment view, a red check mark appears next to ProdPlatform indicating that the
object is currently checked out.
ot
N

16. On the General tab, configure the Network address field with the computer name of the
remote PROD node that your instructor provides.
o
D

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
C
18. In the Comment field, enter Changed Network Address and click OK.
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

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

Platforms host engines, so you will now move the engine instance to a platform.
21. Drag AppEngine1 to ProdPlatform.
o
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
op
The Deployment view now shows that all objects in the deployment model have been hosted.
Now, you will update the plant model.

C
23. Click the Model tab to display the Model view, and then expand the Unassigned Area folder.
ot
N

24. Assign the three objects in the Unassigned Area folder to the ControlSystem area.
The Model view now shows that all objects in the plant model have been assigned.
o
D

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

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

y
GRPlatform and then deploy the rest of the platforms in parallel.

op
The Deploy dialog box appears.
C
ot
N
o
D

27. Keep 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
op
28. Click Close.
You will now deploy the second platform.

C
29. Right-click ProdPlatform and select Deploy.
ot
N
o
D

Application Server 2017

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. Keep the default options and click OK.

C
When complete, the progress displays 100% completed. Notice that nine objects were
deployed.
ot
N

31. Click Close.

o
D

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

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

y
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

op
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
application infrastructure diagnostics by allowing the viewing of runtime status of some system
objects and the ability to perform actions upon those objects.
The console tree shows the items that are available in the console. Other snap-ins that may

and the DAServer Manager

C
appear below the ArchestrA SMC node include the Galaxy Database Manager, the Log Viewer,

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

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)

y
 Log Viewer (all Wonderware nodes)
 Platform Manager (all Application Server nodes)

op
 Other snap-ins (for example, Process Historian Server) will be available when other
Wonderware software is installed

C
ot
N

Each snap-in has its own toolbar, menu options, detail panel, and so on. The contents of these
items will change as you select different items in the console tree.

Security
For all ArchestrA administrative utilities, including Platform Manager, security is configured through
the ArchestrA IDE. By default, there is no security enabled for Platform Manager or any of the
o

other snap-ins.

Galaxy Database Manager

D

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.

y
Operations Integration Server Manager

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

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
ot
components. For example, the ArchestrA Log Viewer records the date and time when ArchestrA
components start and any error conditions that occur.
The Log Viewer can:
 Monitor messages on any machine in the system
 Send a portion of the log to notepad or e-mail
N

 Filter messages on a flag

When running an ArchestrA application, the Logger runs as a system service. The Log Viewer is a
Microsoft Management Console (MMC) snap-in that provides a user interface for viewing
messages reported to the Logger. The MMC is a host or container utility for the Log Viewer with its
own generic functions.
o

Note: If a problem occurs while running an ArchestrA application, always check logged messages
by using the Log Viewer prior to calling Technical Support.
D

Application Server 2017

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.

y
These commands are also available by right-clicking an item in either the console tree or the

op
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
the console tree or the details pane.

C
ot
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
N

the system. This process occurs without any prompting from or interaction necessary from
the user. The logging process can be customized with the LogFlag Editor Snap-In utility.
The Logger is installed as a system service, and can be configured to be an Auto Service
or Manual Service. 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
o

ArchestrA components. The look-and-feel and the format of the user interface can be
customized to suit individual needs.
D

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.

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

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

C
ot
N

Using Bookmarks
Bookmarks are unique labels you can apply to individual messages for quick access. They differ
from marks in that bookmarks are associated with specific messages while marks are messages
added below the message that is currently last in the log.
You cannot enter duplicate bookmark names for more than one message, and a message can
o

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
D

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

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

y
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

op
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
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
bookmarked message above and below, respectively. When you are finished searching, click
Close.

C
Note: You cannot go to bookmarked messages that are currently hidden by a filter. If you cannot
find the desired message, disable filtering and try again.

To Manage Bookmarks
ot
On the View menu, click Bookmarks. In the Bookmarks dialog box, you can manage current
bookmarks and create new ones. The bookmark list shows the current set of bookmark names
and associated Message No. (the same number as the No column in the message window).
The bookmark list provides several functions. For example, to rename a bookmark, select the
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.
N

To go to a bookmarked message, double-click it in the list or select it and click Go To. To remove
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
window and click Add. This function is comparable to a fast bookmark. Rename it by pressing F2.
When you are finished, click Close.
o

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

Wonderware Training
 Section 3 – System Management Console 3-33

Platform Manager
The Platform Manager is an extension snap-in to the SMC. It provides Galaxy application
diagnostics by allowing you to view the runtime status of some system objects and to perform
actions upon these objects. Actions include setting platforms and engines in an executable or idle
mode and starting and stopping platforms and engines.

y
op
C
ot
N
o
D

Application Server 2017

3-34 Module 3 – Application Infrastructure

y
op
C
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

y
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

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

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

is spent in housekeeping tasks or idle, or both. This is called a scan overrun and it could span
multiple scans. The AppEngine provides attributes to monitor if scan overruns have occurred:
 Scheduler.ScanOverrun.Condition
 Scheduler.ScanOverrunsCnt
 Scheduler.ScanOverrunsConsecCnt
o

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
D

default, they are executed in alphabetical order.

3. The AppEngine itself.

Application Server 2017

3-36 Module 3 – Application Infrastructure

Consider the following hosting relationship within a given AppEngine object:

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

op
1. The Device Integration objects are executed first, in alphabetical order.

alphabetical order.
C
2. The Area objects, including their hosted Application objects are executed (by default) in

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
ot
corresponding Area object: X, Y, Z for Area 1; A, B, C for Area 2; and M, N, P for Area 3.
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:

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

op
C
ot
As soon as an attribute reference is submitted from Object Viewer or from a graphic in InTouch,
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.
N

The same behavior occurs when one object requests data from another object, object 1 will have a
reference to an attribute in object 2. The location of object 2 is handled by ArchestrA.
o
D

Application Server 2017

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
means that from any computer that has a WinPlatform object deployed you will have access to all
deployed automation objects in the Galaxy.
N

You can open the Object Viewer tool from two places:
 The ArchestrA IDE, as long as there is a local platform deployed
 The Platform Manager, from any computer with a platform deployed
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
o

permissions to, for example, change a setpoint, you will also need this additional permission to do
so from Object Viewer.
D

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

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

op
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
both
 Quality – Indicates the quality of the current value of attribute; possible values are: Good,
Uncertain, Initializing, and Bad.


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

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

Application Server 2017

3-40 Module 3 – Application Infrastructure

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
ot
provided through the local WinPlatform object. This means that from any computer that has a
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
tool, as well as operations within the tool will be dictated by the permissions assigned to the user.
N

Key Functions
Platform Manager provides access to the following deployed objects from the Galaxy:
 WinPlatform
 AppEngine
 ViewEngine
o

Platform Manager allows you to:

 View the following information of deployed WinPlatform objects:
 Platform Name – The name of the platform object
D

 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

Wonderware Training
 Section 4 – The Runtime Environment 3-41

 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

y
 Remove the platform from the local computer
Platforms and engines can have one of the following statuses:

op
 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
 Running Off Scan – The object is running but not available for execution
 Various transitional statuses between (for example, Shutting Down)

C
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
the corresponding objects will still show as deployed in the ArchestrA IDE.
ot
N
o
D

Application Server 2017

3-42 Module 3 – Application Infrastructure

y
op
C
ot
N
o
D

Wonderware Training
 Lab 4 – Using Object Viewer 3-43

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.

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

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

C
ot
N
o
D

Application Server 2017

3-44 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
The Object Viewer window appears and displays the ProdPlatform attributes.
ot
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-45

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,
right-click PlatformInfo and select Add to Watch.

y
op
C
ot
The attribute is added to the watch window.
N
o
D

Application Server 2017

3-46 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

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

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

Wonderware Training
 Lab 4 – Using Object Viewer 3-47

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

9. Click OK.
The watch list tab now displays the new name.
o
D

Application Server 2017

3-48 Module 3 – Application Infrastructure

Save the Watch List

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

y
The Save As dialog box appears.

op
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
editor. Object Viewer does not require a file extension.

C
ot
N
o

12. Click Save.

13. Close Object Viewer.
D

Wonderware Training
 Lab 4 – Using Object Viewer 3-49

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

3-50 Module 3 – Application Infrastructure

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

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

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

C
ot
N
o
D

Wonderware Training
 Lab 4 – Using Object Viewer 3-51

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.

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

C
ot
N
o

21. Click Open.

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

Application Server 2017

3-52 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
C
A new tab appears at the bottom of the watch window.
ot
N
o
D

Wonderware Training
 Lab 4 – Using Object Viewer 3-53

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

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

25. In the Tab Name field, enter AppEngine and click OK.
o
D

Application Server 2017

3-54 Module 3 – Application Infrastructure

The watch list tab displays the new name.

y
26. On the File menu, click Save Watch List.
27. Minimize Object Viewer.

op
C
ot
N
o
D

Wonderware Training
 Section 5 – Data Simulation 3-55

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

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

op
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.
To gather simulated I/O data, you need to make sure that all the I/O references of attributes in
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

and OI.SIM server.

C
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

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

3-56 Module 3 – Application Infrastructure

y
op
C
ot
N
o
D

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

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.

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

op
 Configure an $OPCClient to the OI.SIM
 Monitor the connection status to the OI.SIM

C
ot
N
o
D

Application Server 2017

3-58 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

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

o
D

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

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

Server node: <Instructor will provide Production node>

Server name: OI.SIM.1

y
5. On the Scan Group tab, in the Available scan groups section, click to add a scan

op
group.
6. Name the group Fast and press Enter.

7. Click the Save and Close

C
button to close the editor.
ot
The Check In dialog box appears.
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

3-60 Module 3 – Application Infrastructure

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

y
op
11. Right-click Simulator and select Deploy.

C
ot
12. Keep the default options and click OK.
N
o
D

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

When complete, the progress displays 100% completed.

y
op
13. Click Close.
Next, you will use the SMC to check the activation status of the OI.SIM.
14. In the SMC, expand Operations Integration Server Manager\TrainingGalaxy\
ProdPlatform.

C
Note that OI.SIM.1 has been activated automatically.
ot
N
o
D

Application Server 2017

3-62 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
Object Viewer appears and refreshes.

C
16. Right-click the empty area of the watch window and select Add Watch Window.
17. Right-click the watch window and select Rename Tab.
ot
18. Name the tab Simulator and click OK.
N
o
D

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

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
configured in the device integration object and the topics in the Device Integration Server.
20. Add the ScanGroupList attribute to the watch window.
N

The Array for Simulator.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.
21. In the Enter an array index field, enter -1.
o
D

22. Click OK.

Application Server 2017

3-64 Module 3 – Application Infrastructure

The ScanGroupList is added to the watch window.

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

op
24. Click Go.
C
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-65

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

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

op
26. Right-click the empty area in the watch window and select Save.

27. Minimize Object Viewer.

C
ot
N
o
D

Application Server 2017

3-66 Module 3 – Application Infrastructure

y
op
C
ot
N
o
D

Wonderware Training
 y
op
C
Module 4 – Application Objects
Section 1 – Introduction to Application Objects 4-3
ot
Section 2 – Object Attributes 4-7
Lab 6 – Modeling Meters 4-15
Section 3 – Change Control and Propagation 4-29
N

Lab 7 – Configuring Change Control and Propagation 4-33

Section 4 – Containment 4-43
Lab 8 – Modeling the Mixer 4-47
o
D
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

y
Server. They can store process data in the Process Historian. Application Server provides the
following Application objects:
 AnalogDevice

op
 DiscreteDevice
 Sequencer
 SQLData
 UserDefined

AnalogDevice Object

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

Sequencer Object
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:
o

 repetitive manufacturing procedures with a finite number of steps

 supervisory processes with a finite number of steps
D

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

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

y
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

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

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.

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.

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

 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

y
The Attribute supports the following data types:
 Boolean

op
 Integer
 Float
 Double
 String
 Time
 ElapsedTime
InternationalizedString



History C
The Attribute provides the enabling and configuration for the following functionality:
Scaling of Input and Output values

HiHi, Hi, Lo and LoLo Limit Alarms

ot
 Rate of Change Alarms
 Target Deviation Alarms
 Bad Value Alarm
 Statistics
The UserDefined object is an object that you can use to create customized objects. You can use
N

the UserDefined object as a template, or as a container.

o
D

Application Server 2017

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

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

op
 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
as State Labels, State alarm, and Statistics (Open/Close time).
 XV100b - Discrete Attribute - InputOutput to a solenoid valve configured with options such
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

y
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

op
initial value and security are editable and lockable in derived templates. When unlocked in either
the base or derived template, the value is editable in instances.
After you add an attribute to an instance, it appears in the Attribute Browser list for use with the
scripting and attribute configuration functions.
On the Attributes tab, you can define the following initial information and parameters for the
attribute:



Add a new attribute to an object.

Configure its data type.

C
Name the attribute and provide a description.

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,
ot
you can specify the states as “Stopped” and “Running.” Text boxes appear for you to enter
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.
 Specify the attribute writeability.
 Set initial values if the attribute is user writeable.
N

 Enable and set locks and security on the new attribute.

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

Attribute Naming Conventions

Attribute names can have up to 32 alphanumeric characters, including periods. Attribute names
o

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
D

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

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

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

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

About the Attributes Tab

If the object you are editing does not have any attributes defined, the Attributes tab will be empty,

features.

C
except for buttons for adding, filtering, duplicating, deleting, and viewing attributes and attribute

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:

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

op
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
template is checked in.
 You can check in a template with an attribute configured with a new feature with the same
name as an existing feature on an attribute in a derived object. The template definition of

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

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:
 Read (Input)
 Read/Write (InputOutput)
N

 Write (Output)
You can also configure advanced properties. The attribute’s data type and I/O type determine what
Advanced I/O properties are available.

Using Read/Write I/O in Scripts

o

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
D

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

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.

y
Using the History Feature

op
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.
You can configure Writeable and Calculated attributes of the following data types with a history
feature:


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

Using the Limit Alarms Feature

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
N

features cannot be added to attribute arrays.

You can enable up to four categories of Limit alarms. When enabled, alarms will be triggered when
the value reaches the configured limit.
 HiHi
 Hi
o

 Lo
 LoLo
D

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

y
Using the Deviation Alarms Feature

op
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.
You can enable up to two categories of Deviation alarms. When enabled, an alarm will be triggered
when the attribute level deviates from a target value by a configured amount.
 Major: The major alarm deviation tolerance


Using the State Alarm Feature C

Minor: The minor alarm deviation tolerance

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.

Using the Bad Value Alarms Feature

Select the Bad Value alarms feature to add and configure a Bad Value alarm on an attribute of
N

Boolean, Integer, Float, or Double data type. If enabled, alarms will be triggered when the attribute
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,
the Bad Value alarm feature is automatically locked in derived objects. Bad Value alarm features
cannot be added to attribute arrays.
o

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

Application Server 2017

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.

y
Using the Log Change Feature

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

Using I/O Auto Assignment

Instead of configuring I/O references manually, or writing scripts to set them at runtime, you can

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

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
o

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

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

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

op
Validating and Editing I/O Assignments
The IO Device Mapping view is a table that displays I/O auto assignment references for application
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

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

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
N

within the device hierarchy, even though the parent object is selected.

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

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

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

4-14 Module 4 – Application Objects

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.

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

op
 Configure and use object templates
 Create instances of application objects
 Acquire data from an OI Simulator
 Monitor attribute data in Object Viewer

C
ot
N
o
D

Application Server 2017

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

3. Name the new template $Meter.

o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-17

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

y
op
Now, you will configure the $Meter template.
5. Double-click the $Meter template to open its configuration editor.

C
ot
N
o
D

Application Server 2017

4-18 Module 4 – Application Objects

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

Name: PV
Data type: Float
Writeability: Object writeable

y
op
C
ot
8. In the Available features area, click the I/O button.
9. In the I/O area, select Read.
N
o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-19

10. Click the Save and Close button to close the editor.
The Check In dialog box appears.
11. 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
12. 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.
13. Right-click the $Meter template and select New | Derived Template.
N
o
D

14. Name the new template $Level.

Application Server 2017

4-20 Module 4 – Application Objects

15. Repeat Steps 13 and 14 for $Temperature.

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

y
op
C
In the Model view, the new instance appears under the Unassigned Area folder.
17. In the Model view, name the new instance L1.
ot
N
o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-21

18. Assign the L1 instance to the Production area.

y
op
19. 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.

C
20. Rename the new instance T1 and assign it to the Production area.
ot
N
o
D

Application Server 2017

4-22 Module 4 – Application Objects

21. On the ArchestrA IDE View menu, click IO Devices.

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

C
ot
N

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

o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-23

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

y
op
C
23. In the IO Devices pane, expand TrainingGalaxy, Simulator, and Fast.
Note the auto assignment of L1 and T1 to Simulator\Fast.
ot
N
o
D

Application Server 2017

4-24 Module 4 – Application Objects

Deploy the Objects

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

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

Wonderware Training
 Lab 6 – Modeling Meters 4-25

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
26. Click OK to accept the default settings.

C
When complete, the progress displays 100% completed.
ot
N

27. Click Close.

o
D

Application Server 2017

4-26 Module 4 – Application Objects

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

C
Now, you will return to Object Viewer to view the attribute values in runtime.
28. Right-click L1 and select View in Object Viewer.
ot
N
o
D

Wonderware Training
 Lab 6 – Modeling Meters 4-27

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

y
op
When the mixer is running, observe the attribute values changing in real time. There is nothing
wrong if the numbers are static for a few moments.
31. Right-click the blank area of the watch window and select Save to save the watch list.

C
ot
N

32. Minimize Object Viewer.

o
D

Application Server 2017

4-28 Module 4 – Application Objects

y
op
C
ot
N
o
D

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

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

y
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

op
constant during run time.

C
ot
N

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

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

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

4-30 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

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

op
Unlocking an Attribute
Unlocking an attribute releases the locking control only one level down.

C
ot
N

Notice that unlocking an attribute within the $Valve template releases the locking control of the
o

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

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

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.

Locking Groups of Attributes

There are a number of places where Application Server allows you to click a single lock icon to
N

lock an entire group of attribute extensions. This adds efficiency, but there are times when not
every item in the group should be locked. You still have the option of locking the group and then
unlocking any specific extension.

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

Application Server 2017

4-32 Module 4 – Application Objects

y
op
C
ot
N
o
D

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

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

y
scaling values.

Objectives

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

C
ot
N
o
D

Application Server 2017

4-34 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-35

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

5. Check Enable I/O scaling.

y
op
6. In the Enable I/O scaling area, in the Maximum: Raw value field, enter 4095.0, and then

click the lock icon to lock the field.

7. Configure the other Enable I/O scaling parameters as follows:
Minimum: Raw value: 0 (default) locked
Minimum: EU value:
Minimum: Extended EU range:
C0 (default)
-6 (default)
unlocked (default)
unlocked (default)
ot
N

8. Save and close the configuration editor.

9. In the Check In dialog box, Comment field, enter Locking Raw Values.
o
D

Application Server 2017

4-36 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
12. On the Derivation tab, double-click the $Level template to open its configuration editor.
13. Verify that the PV attribute is selected.
ot
N

14. In the Description field, enter Level Indicator and press Enter.
o

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

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

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

y
op
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
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:

Minimum: EU value:
Minimum: Extended EU range:

C
locked
locked
ot
N

19. Save and close the configuration editor.

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

Application Server 2017

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

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

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

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

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

y
29. In the I/O area, expand Advanced.
30. Configure the Enable I/O Scaling parameters as follows:

op
Maximum: EU value: 250 locked
Maximum: Extended EU range: 255 locked

C
ot
31. Save and close the configuration editor.
32. In the Check In dialog box, Comment field, enter Locking Attribute Properties.
N

33. Click OK.

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

Application Server 2017

4-40 Module 4 – Application Objects

34. Click Close.

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.

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

Maximum: EU value: unlocked

op
Maximum: Extended EU range: unlocked

C
ot
38. Save and close the configuration editor.
39. In the Check In dialog box, Comment field, enter Unlocking Attribute Properties.
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-41

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. Right-click L1 and select View in Object Viewer.

y
Notice the new values.

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

4-42 Module 4 – Application Objects

y
op
C
ot
N
o
D

Wonderware Training
 Section 4 – Containment 4-43

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

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

op
An object can have three kinds of names, depending on if it is contained by another object. The
three names include:
 Tagname
 Contained Name
 Hierarchical Name

Name
Tagname
Contained Name
Description

C
The unique name of the individual object. For example, Valve1.
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.
For example, if:
“Mixer1” contains Tank1 (also known within Mixer1 by its contained name “Tank”).
N

“Tank1” contains Valve1 (also known within Tank1 by its contained name “Outlet”).
Valve1 could be referred to as:
“Valve1”
“Tank1.Outlet”
“Mixer1.Tank.Outlet”
o

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

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

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

y
ApplicationObject Containment

op
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:
 2 Inlet Valve
 Agitator
 Outlet

C
ot
N
o
D

Wonderware Training
 Section 4 – Containment 4-45

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

Within the context of each hierarchy, the contained names are unique, in that the names only refer
o

to this tank system and the contained objects.

So if the tank is named Mixer_001, the contained names are:
 Mixer_001.Agitator
D

 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

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

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

op
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
can also right-click an object and select Rename Contained Name.

Containment and the Derivation View


C
The Derivation View does not show containment relationships. It shows templates and instances
with regard to containment in the follow ways:
Non-contained instances show their tagnames.
Contained instances show their tagnames and hierarchical names.
Non-contained templates show their object name.
ot
 Contained templates show their hierarchical name.
Containment of instances is limited to Areas containing other Areas and AppObjects containing
other AppObjects.
Renaming can be done on an instance's tagname and contained name. A template only has a
template name.
N

It is also important to note that adding or removing an element to/from a container at the template
level, does not affect previously created instances.
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-47

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.

y
Objectives

op
Upon completion of this lab, you will be able to:
 Create a containment relationship using templates
 Create instances of contained objects
 View the attribute data of contained objects in Object Viewer
 Use the Area model to handle I/O assignments

C
ot
N
o
D

Application Server 2017

4-48 Module 4 – Application Objects

Create the Mixer Template

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

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

Wonderware Training
 Lab 8 – Modeling the Mixer 4-49

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

y
op


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

Application Server 2017

4-50 Module 4 – Application Objects

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

y
op
7. On the Attributes tab, click the Add
press Enter.
C
6. Double-click the $Valve template to open its configuration editor.

button and name the new attribute OLS, and then

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

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 area
Read: selected

y
op
C
ot
10. Click the Add button and name the new attribute CMD, and then press Enter.
N

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

Application Server 2017

4-52 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 area
Write: selected

y
op
C
ot

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

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

o
D

14. Click Close.

Wonderware Training
 Lab 8 – Modeling the Mixer 4-53

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

y
op
16. Contain the templates in $Mixer.

C
ot
Create the Motor Template
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.
N

18. Move the new template to the Training\Project toolset.

o
D

Application Server 2017

4-54 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-55

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
25. 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.
N
o
D

26. Click Close.

Application Server 2017

4-56 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
op
28. Open the $Agitator configuration editor.
29. For the CMD attribute, change the Description to Agitator Command and lock the field.

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

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

4-58 Module 4 – Application Objects

All the attributes are now visible in the attributes list.

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

Create the Pump Templates


$Pump1
$Pump2 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:
ot
N
o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-59

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.

y
op
37. Save and close, and then check in the object with an appropriate comment.
38. Open the $Pump2 configuration editor.
39. For the CMD attribute, change the Description to Pump 2 Command and lock the field.

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

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

Application Server 2017

4-60 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-61

44. In the Deployment view, name the new instance Mixer100 and assign it 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

C
proper data points. You will first have to undeploy the objects because you cannot change the
autobind assignment of an object while the object being assigned is deployed.
45. Select Line1 and Line2, and then right-click and select Undeploy.
ot
N
o

46. The Undeploy dialog box appears.

D

47. Click OK.

Application Server 2017

4-62 Module 4 – Application Objects

When complete, the progress displays 100% completed.

y
op
48. Click Close.
49. Expand Mixer100.
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-63

50. In the Deployment view, select Line1, Mixer100 and all its contained objects, and Line2, and
then drag them 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. When an area is assigned to an IO source for autobinding, all objects contained in that

C
area are bound to the same IO source, and all objects that will be assigned to that area in the
future will also be bound to that source.
Now, you will verify the references created using I/O Binding.
51. In the Deployment view, deploy Line1, Mixer100 and all its contained objects, and Line2.
ot
N
o
D

Application Server 2017

4-64 Module 4 – Application Objects

The Deploy dialog box appears.

y
op
52. Keep the default options and click OK.

C
When complete, the progress displays 100% completed.
ot
N

53. Click Close.

o
D

Wonderware Training
 Lab 8 – Modeling the Mixer 4-65

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

y
op
54. Right-click Mixer100 and select View in Object Viewer.

C
55. Load the watch list you saved earlier, if necessary.
56. Add a new watch window and rename the tab Mixer100.
57. Add the following attributes to the watch window:
 Level_001.PV
ot
 Temperature_001.PV
 Agitator_001.CMD
 Agitator_001.PV.Msg
 Agitator_001.Speed.PV
 Agitator_001.Speed.SP
N

 Inlet and Outlet CMDs and OLS.Msgs

 Pump CMDs and PV.MSGs
o
D

Application Server 2017

4-66 Module 4 – Application Objects

58. Save the watch list.

As this is all data from the Simulator data source, the data is not interactive and changing any
value will have no impact.

y
op
C
ot
N
o
D

Wonderware Training
 y
op
C
Module 5 – Device Integration
Section 1 – Device Integration Servers 5-3
ot
Lab 9 – Configuring the OI Server 5-7
Section 2 – Device Integration Objects 5-15
Lab 10 – Configuring the Device Integration Object 5-21
N

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
o
D
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

y
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

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

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
 Communication between device integration objects in the Galaxy and external drivers
(Windows applications or services) is accomplished by the DDE, SuiteLink, or OPC
protocols
N

 The drivers (for example, OI Servers) communicate with the controllers through the
device-specific protocol, such as Modbus TCP or DH+.

OI Servers
The OI Server Manager is a part of the SMC suite of utilities. It enables the configuration,
o

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
D

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

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

Since there is a limit of one server group per OI Server per computer node, that server group
effectively is the OI Server.
Where the server group appears in the OI Server Manager depends on what type of OI Server it is
for. For the purpose of this course, the MBTCP is optimized and is contained in the Operations
Integration Supervisory Servers folder.
o

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

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

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

op
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
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
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
because a large amount of data is being transmitted between the device and the OI Server. Large
update intervals slow turnaround for data changes.
N

Configuring Device Items

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

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

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

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.

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

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

C
ot
N
o
D

Application Server 2017

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

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
op
9. Rename the topic to Topic1.

C
ot
10. Click the Device Items tab.
11. Right-click inside the table and select Import.
N
o
D

Application Server 2017

5-12 Module 5 – Device Integration

12. Navigate to the 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

14. Click the Save button in the top-right corner.

D

Application Server 2017

5-14 Module 5 – Device Integration

15. Right-click OI.MBTCP.1 and select Activate.

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

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

y
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

op
 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
Application Server includes the following device integration objects for communication with the
drivers:
 $DDESuiteLinkClient
 $OPCClient

$DDESuiteLinkClient
DDE

SuiteLink

C
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:

Product OPC
ot
$OPCClient 

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
N

information.

Each Device Integration Server speaks a particular device-specific protocol; for example, to
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:
o

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

Application Server 2017

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) 

y
Note: For OPC, DA Servers support the OPC DA standard (OPC Classic).

op
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
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
a server.
The supported application protocols are:


C
DDE (Dynamic Data Exchange) - a Microsoft communications protocol that lets
applications send and receive data and instructions to and from each other. DDE
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.
 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
N

commonly referred to as such for convenience. Application Server supports OPC

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
Wonderware Knowledge and Support Center).

Important: Communication using the DDE protocol can only be done on the same computer.
o

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

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.

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

op
 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
that includes the update interval.

I/O Referencing from Automation Objects

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

point) requested; the attribute name becomes a compound of these two pieces:
<di object name>.<device group name>.<item name>
The item name can be customized through the device integration objects to accommodate any
necessary naming conventions. Both, device integration objects and device integration servers
allow adding a list of aliases for the item names.
o

Note: Naming conventions for item names are important for automatic I/O binding to work.
D

Application Server 2017

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.

y
op
The main characteristics of the DDESuiteLinkClient object are:
 Support for multiple topics which allows one instance of the object to access multiple
controllers connected to the same device integration server
 Allows definition of aliases for item names; this is done on a per topic basis
 The rate at which the data items are updated depends on how the topics are configured


within the device integration server

resources
C
Support for advanced communication management to address network traffic and other

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.

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

The OPCClient Object

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

The main characteristics of the OPCClient object are:

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

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

resources

Application Server 2017

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.

y
At least one Scan Group must also be configured for the OPCClient object to establish a
communication channel with the server application.

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.

y
Objectives

op
Upon completion of this lab, you will be able to:
 Configure a device integration object
 Monitor the connection status of a device integration object

C
ot
N
o
D

Application Server 2017

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.

C
6. In the Available topics section, click the ScanGroupList
7. In the Topic field, enter Topic1 and press Enter.
button to add a topic.
ot
N

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

Application Server 2017

5-24 Module 5 – Device Integration

9. In the Model view, assign the ProdPLC instance to the ControlSystem area.

y
op
C
10. In the Deployment view, assign the ProdPLC instance to AppEngine1.
ot
N
o
D

Wonderware Training
 Lab 10 – Configuring the Device Integration Object 5-25

11. Deploy ProdPLC.

y
op
C
12. In the Deploy dialog box, click OK to accept the default settings.
When complete, the progress displays 100% completed.
13. Click Close.
ot
View the Attributes in Runtime
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
 Reconnect
 ScanState
ScanStateCmd
o


D

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

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
op
19. Click OK.
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.

y
op
21. Click OK.
The ProdPLC.Topic1.$Sys$Status attribute reference is added to the watch window.

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.
23. Minimize Object Viewer.
N
o
D

Application Server 2017

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.

y
Using the I/O Feature
The I/O feature allows you to configure all aspects of data input and output for an attribute.

op
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)
 Write (Output)
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.

Note: Note: I/O auto assignment is the default setting for application and other system objects,
N

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
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:
<IODevice>.[ObjectName].[AttributeName].InputSource
o

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

<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

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

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

op
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
and system objects that are linked to DI object scan groups. Manually configured references are

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

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
o

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

D

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.

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

op
 Change the I/O assignment of objects
 Connect objects to live controller data
 Monitor data acquisition

C
ot
N
o
D

Application Server 2017

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
The Undeploy dialog box appears.
C
ot
N

2. Click OK.
o
D

Wonderware Training
 Lab 11 – Connecting the Mixer to the Field 5-33

When complete, the progress displays 100% completed.

y
op
3. Click Close.
4. In the IO Devices pane, expand ProdPLC.

C
ot
N
o
D

Application Server 2017

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
C
6. Deploy the Production area and all its contained areas and objects.
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 window, double-click Agitator_001.Speed.SP.
The Modify Numeric Value dialog box appears.

y
10. In the Value field, change the speed to 50.0.

op
11. Click OK.

C
Wait for the mixer to be full, which causes the agitator to start, and note the
Agitator_001.Speed.PV.
ot
N
o

12. Minimize Object Viewer.

D

Application Server 2017

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.

y
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

op
sources. It also determines which one is Active at any given time. Both data sources must also
have the same item address space.

RedundantDIObject
The RedundantDIObject provides you with the ability to configure a single object with connections
to two different data sources (proxy objects or DIDevice objects). In the event of a failure of the

C
active data source, this object automatically switches to the standby data source.
This capability allows clients to configure redundant connections to a field device.
The 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
source DeviceIntegration objects.
The RedundantDIObject supports the following operations on I/O points from field devices:
N

 Subscriptions, which are implemented via scan groups. Read transactions, which are
implemented via block reads (when available in the source DIObject). Write transactions,
which are implemented via block writes (when available in the source DIObject).

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

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

Note: The RedundantDIObject checks the state of its source DIObjects on every scan cycle.

Application Server 2017

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.

y
Configuring Data Acquisition Redundancy
Data acquisition redundancy objects involve two DIObjects and the RedundantDIObject. In data

op
acquisition redundancy, you must configure all three components:
 Primary DIObject data source
 Backup DIObject data source
 Redundant DIObject data source

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.

Wonderware Training
 Section 4 – Device Integration Redundancy 5-39

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.

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

y
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

op
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

C
connection status of the PLC at runtime. If you are using the redundancy feature of the
RedundantDIObject to communicate with DIObjects, you should configure the PingItem attribute
for each scan group.
ot
N
o
D

Application Server 2017

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

y
redundant DI system.
If you are on a single-node network configuration, you will skip this lab.

op
Objectives
Upon completion of this lab, you will be able to:
 Configure an instance of a Redundant DI Object
 Create a deployment model for a Redundant DI Object
 Force a failover on a redundant DI system

C
ot
N
o
D

Application Server 2017

5-42 Module 5 – Device Integration

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

5. In the Deployment view, rename the instance R_ProdPLC2.

N
o
D

Application Server 2017

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, X00Eng)>

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.

C
9. In the Available topics section, click the ScanGroupList
10. In the Topic field, enter Topic1 and press Enter.
button to add a topic.
ot
N

11. Save and close, and then check in the object with an appropriate comment.
12. In the Model view, assign the R_ProdPLC2 instance to the ControlSystem area.
o
D

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

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.

y
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

op
named area.

C
ot
N
o

19. Click OK.

D

Wonderware Training
 Lab 12 – Configuring the Redundant DI Object 5-47

In the Available scan groups area, Scan Group column, Topic1 appears.

y
op
20. Save and close, and then check in the object with an appropriate comment.
Now, you will deploy the objects.

C
21. In the Model view, assign the ProdPLC instance to the ControlSystem area.
ot
N
o
D

Application Server 2017

5-48 Module 5 – Device Integration

22. In the Deployment view, assign the ProdPLC instance to AppEngine1.

y
op
24. Expand R_ProdPLC1\Topic1, if necessary.
C
23. In the IO Devices pane, expand ProdPLC\Topic1.

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
op
26. Select all undeployed objects.

C
ot
N
o
D

Application Server 2017

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

y
 StatusBackupDISource
 StatusPrimaryDISource
 SwitchCnt

op
 SwitchReason
The watch window displays that R_ProdPLC1 is currently the active DI source and
R_ProdPLC2 is the standby DI source.

C
ot
N

You will now force a failover and observe that the active DI source changes from R_ProdPLC1 to
R_ProdPLC2.
32. In the watch window, double-click ProdPLC.ForceFailoverCmd.
33. In the Modify Boolean Value dialog box, click the True option.
o
D

Application Server 2017

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.

C
36. On the DIO Redundancy tab, trigger ProdPLC.ForceFailoverCmd again to switch back to
R_ProdPLC1 as the active DI source.
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

38. Double-click R_ProdPLC1.ScanStateCmd.

D

Application Server 2017

5-54 Module 5 – Device Integration

39. In the Modify Boolean Value dialog box, click the False option.

y
40. Click OK.
The watch window now displays R_ProdPLC2 as the active DI source and R_ProdPLC1 as
the standby.

op
Notice that the SwitchCnt is now 3 and the SwitchReason is Offscan.

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

Notice that Failover does not change. This is because the Redundant DIO Object does not
automatically switch back to the Primary DI Source.
o
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
op
44. Save the watch list and minimize Object Viewer.

C
ot
N
o
D

Application Server 2017

5-56 Module 5 – Device Integration

y
op
C
ot
N
o
D

Wonderware Training
 y
op
C Module 6 – History
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 Process 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 Process 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

y
You can configure application objects to store process data in the Process Historian. Historical
data from Application Server can be retrieved and viewed using standard Process Historian
database utilities. Also, you can use historical data to produce reports shown from your client
applications.

op
Application Server History Components
To save your process data to a historical database, you must install the Process Historian. A
Process Historian can be installed on any computer outside the Galaxy, but on the same network.
In a production environment, the Process Historian should be installed on a dedicated computer.
Each Engine in the Galaxy is configured with the location of the Process Historian storage node to

C
which its history data is to be sent. This configuration is stored in an attribute within the Engine.
ot
N
o

A single Process Historian installation can receive historical data from a single Galaxy. A push
model is used to send and save new historical updates to Process Historian. Each system Object
Engine (Platform, AppEngine, ViewEngine) includes a historian primitive that sends all history
D

updates for all hosted objects to the historian. All Engine objects include an attribute to specify the
node name of the computer hosting Process Historian.
The figure shows a single Process Historian. This may be a common configuration, but other
Application Server configurations support multiple Process Historian databases for a Galaxy.
However, each Engine Object only sends its historical data to one Process Historian.

Application Server 2017

6-4 Module 6 – History

The following figure shows the major ArchestrA components to save process data from a
production device to the Process Historian.

y
op
There is a one-to-one relationship between a historical Object attribute and a tag in Process
Historian.
For storage, the story is similar. When an Object decides to store a new VTQ to Process Historian,
it pushes that storage update message, with the new VTQ, to Process Historian using a Process

C
Historian supplied interface. The history primitive uses the previously-returned unique identifier for
the Process Historian tag that corresponds to the historized property to identify the tag being
stored.

Process Historian Installation and Deployment

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

A single Process Historian can receive historical data from a single Galaxy only.

Store and Forward

If the Process 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
o

Object.
When the Process Historian node recovers, data is forwarded from the local node to the Process
Historian node at a low priority.
D

If an AppEngine loses connectivity to the Process Historian node, the Process Historian reports
bad data quality to clients. When you undeploy an Object with attributes configured for history, the
Process Historian stores the final data points with Bad quality.

Wonderware Training
 Section 1 – Historizing Data for Application Server 6-5

History Configuration

Saving Object Attribute Data to the Process 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 Process Historian. If there is no timestamp
associated with the attribute value, the current scan time from the AppEngine hosting the Object is
used instead.

y
Historizable Data Types for Attributes

op
For attribute data to be stored in the historian, a host AppEngine must be configured to send
history data to a Process Historian node. For each Object, you can configure attributes of the
following data types to be saved to the Process Historian.
 Float (numerical)
 Double (numerical)
 Integer (numerical)
 Boolean (non-numerical)



C
String - Unicode (non-numerical)
CustomEnum (non-numerical) maps to Process Historian Integer
ElapsedTime (numerical) Maps to Process Historian Float, converted to seconds
Arrays or portions of arrays are not supported.
Enum type attributes are saved as Process Historian integer ordinal values.
ot
 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 Process Historian are in the engineering units specified
for the attribute. The Process Historian does not scale numerical values.
N

Configuration of a Non-Numerical Attribute for Historization

For an Object that has non-numerical historizable attributes, the ArchestrA IDE user can enable
history for each attribute. No other configuration data is provided, 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.
o

Configuration of a Numerical Attribute for Historization

For an Object that has numerical historizable attributes, the ArchestrA IDE user can enable history
D

for each attribute. Once enabled, certain configuration settings can be specified. These settings
determine how often data is historized.
The following configuration settings can then be specified:
Value Deadband - 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 Process Historian. A new value that is within the range of the
deadband is not saved to the Process Historian. The default value of 0.0 disables the Value
Deadband and any change to a value is saved as historical data.

Application Server 2017

6-6 Module 6 – History

Force Storage Period - Interval in milliseconds in which an attribute value is saved to the Process
Historian, regardless of whether the value exceeds its value deadband setting or not. An attribute
value is saved to the Process 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.
Trend Lo - Initial minimum trend value in engineering units for clients. The default is 0.0.
The following are advanced configuration settings that require a knowledge of Process Historian
Server and will not be discussed in this course:
Interpolation Type

y


 Rollover Value
 Sample Count

op
 Enable Swinging Door Rate Deadband

Dynamic, Automatic Configuration of Process Historian at Object Deploy Time

When an AutomationObject is deployed that has been historized, the Object causes a dynamic
reconfiguration of the Process Historian product. Each historized property causes a new tag to be
created and configured automatically in Process Historian at deployment time. The Process
Historian storage system to be configured is configured in the engine Object itself.

C
If the link to the Process Historian product is down at deploy time, the attempt to dynamically
reconfigure Process Historian is achieved at the time the Process Historian link is recovered. In
other words, automatic retry is built in.

Reconfiguration of Process Historian at Object Redeploy Time

ot
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 Process
Historian product automatically. For example, if the engineering units string for the tag changes
from “Deg F” to “Deg C” upon a redeploy, the Process Historian configuration database must
reflect this change.
N

Reconfiguration of Process Historian at Object Undeploy Time

When an AutomationObject that has been historized is undeployed, the Object does not cause
any dynamic reconfiguration of the Process Historian product. In other words, the Process
Historian tag and all its history is left in the Process Historian. This means the history data can still
be examined in the future even if the AutomationObject is no longer deployed.
o

NaN Handling
For Float and Double attributes, a potential value is the IEEE NaN encoding for the float or double
representation. NaN values can be generated for attributes that are to be historized. These NaNs
D

will be accompanied by a Bad OPC Data Quality. In any case, NaN is a valid value that can be
generated for floats and doubles. Unfortunately, Process Historian clients do not handle NaN
properly. Therefore, ArchestrA will convert the NaN value to a Null value representation just prior
to sending to Process Historian.

Wonderware Training
 Section 1 – Historizing Data for Application Server 6-7

Process Historian Quality Mapping

The Application Server Data Quality is somewhat different than the Process Historian data quality.
The plan is for Process Historian to support the OPC Quality definition. Thus, the 16-bit value for
the OPC Data quality is sent to Process 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 Process 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 Process

y
Historian. The quality stored in Process Historian is to be the actual quality of the attribute in
Application Server with no modification. However, Process 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 Process Historian clients to project the right information on the

op
client.

Process Historian Timestamp Mapping

The timestamp to be sent to Process Historian for each attribute value/quality update is sent by the
Object in the VTQ packet. Both Application Server and Process Historian use UTC time.

C
ot
N
o
D

Application Server 2017

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 Process 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 Process Historian. Also, you can select the WinPlatform
Object’s Platform, scheduler, and engine data to be saved to the Process Historian. Finally, you
can select the WinPlatform’s attribute values to be saved to the Process Historian.

Configuring an AppEngine Object to Store Historical Data

If an AppEngine is deployed before Process Historian Server is started, history data can be stored
locally by HCAL until the objects successfully register with the Process Historian Server.

y
Note: Note: Except for Late Data, the ViewEngine Object contains the same historical attributes
as the AppEngine Object.

op
Insight
Process Historian Insight provides web-based access to Process Historian Server. It is installed
with Process Historian as an on-premise application. It helps to retrieve historical data through the
web browser and present data in different formats, such as trends and tables. On a remote client
node, you can connect to Process Historian Insight using a web browser.

C
ot
N
o
D

Application Server 2017

6-10 Module 6 – History

With Process 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
InSightApp
N

InSightApp is an out-of-the-box ArchestrA App for running an active Insight browser session within
a pane of a running ViewApp. The InSightApp provides a visualization of operational data by
retrieving information from the Historian. The InSightApp includes a search engine for retrieving
relevant information from tags that include defined keywords.

InSightApp Global Settings

o

InSightApp global settings are configured in the InSightApp Global Editor. You can open the
InSightApp Global Editor by double-clicking the InSightApp from the Graphic Toolbox. From the
editor, you can configure the Historian InSight server URL, the chart duration, and keywords
D

defined for searching tags. You can also use the Test Connection button to verify connection to the
specified InSight server.

InSightApp Properties
To use the InSightApp in a ViewApp, it must be assigned to a layout pane in the Layout Editor or
ViewApp Editor. Once the InSightApp is assigned to a pane, you can customize the properties that
include Historian InSight server URL, chart duration, and keywords defined for searching tags.

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 Process Historian Server.
Specifically, you will configure the AppEngine Object to store historical data to a Process Historian
Server.
Additionally, you will configure the object attributes to be historized.

y
Objectives

op
Upon completion of this lab, you will be able to:
 Configure the AppEngine object to store historical data on a Process Historian Server
 Configure objects to historize attributes
 Retrieve historical process data with Insight

C
ot
N
o
D

Application Server 2017

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 store forward 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, check the Enable storage to historian check box.
6. In the Historian field, enter the node <instructor will provide (for example, X00Eng)>.
N
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

6-14 Module 6 – History

11. Scroll down and unlock Trend high and Trend low.

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

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.

y
op
C
ot
N

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

18. Click Close.

Application Server 2017

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.

y
op
21. 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.

C
ot
N

Notice that the change was also propagated to the mixer instance.
22. Click Close.
23. In the Template Toolbox, Training\Project toolset, open the $Valve configuration editor.
24. In the attributes list, select OLS.
o
D

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-17

25. Click the History button.

26. Lock the History group.

y
op
C
ot
27. Save and close, and then check in the object with an appropriate comment.
28. When the Check In dialog box reappears with an Object 1 of 1 completed message, click
Close.
Notice that the change was propagated to other instances.
N

29. In the Template Toolbox, Training\Project toolset, open the $Mixer.Agitator configuration
editor.
30. Select the Speed.PV attribute.
o
D

Application Server 2017

6-18 Module 6 – History

31. Click the History button, and then lock the History group.
32. In the History group, in the Trend high field, enter 100.0.

y
op
C
ot
N

33. Save and close, and then check in the object with an appropriate comment.
34. When the Check In dialog box reappears with an Object 1 of 1 completed message, click
Close.
o

Notice that the change was propagated to the agitator instance.

35. You may configure other objects of your choice for historization.
D

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-19

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.

Application Server 2017

6-20 Module 6 – History

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.
39. After a few seconds, Insight appears.

y
op
C
40. In the Search field, enter Level and wait for Data to appear.
ot
41. 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 appears.
N
o
D

42. Click Level_001.PV.

Wonderware Training
 Lab 13 – Configuring and Retrieving History 6-21

The Insight Trend appears for the selected tag. You may have to scroll to the right to see the
trend.
43. Click the blue trend.

y
op
C
ot
The tag details appear with another trend indicator.
44. Click the trend indicator in the tag details.
N
o
D

Application Server 2017

6-22 Module 6 – History

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
op
45. Set the time to the last hour.
C
ot
N
o
D

46. On your own, explore the features of Insight.

Wonderware Training
 y
op
C
Module 7 – Alarms and Events
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 Process Historian, as
well as how to retrieve alarm history from SQL Server.

What is an Alarm/Event

y
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

op
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
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.
Examples of alarms include:



alarm.

stopped. C
A process measurement has exceeded a predefined limit, such as a high temperature

A process device is not in the desired state, such as a pump that should be running has

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

deployment of a new AutomationObject.

 The system engineer has started or stopped a system component; for example, stopping
an engine.
 A Platform has come back online after it had a failure or shutdown.
 A user has logged into the system.
o

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

 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

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

The Platform also routes alarm acknowledgments, enables and disables received from distributed
alarming back to the appropriate AutomationObject. Alarm acknowledgments, enables, and
disables carry along the User information for security purposes. An alarm generated by Application
Server contains fields that are generated by the alarm functions inside the AutomationObject.
o
D

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

y
Application Server supports the following types of alarms:
 Limit alarms
 Deviation alarms

op
 Diagnostic alarms
 Rate of change alarms
 Bad value alarms
The type of alarm that you can configure is based on the data type of the attribute’s value.

Limit Alarms

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

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
limits. You can set individual messages for each alarm limit.
o
D

Application Server 2017

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.

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

op
Deviation Alarms
A deviation alarm compares the current attribute value to a target Engineering Units value. Then,
the absolute value of the difference is compared to one or more alarm deviation limits expressed in
EngineeringUnits.

C
ot
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
N

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

y
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

op
your rate of change alarm limit to 5.0 liters per minute, a rate of change alarm condition exists.

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

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

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

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.

y
Configuring Plant State-Based Alarms

op
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
Plant State Available Alarm States
Alarm State
Running Enable Enable
Maintenance
Startup
Shutdown
Testing
Disable
Silence
Disable
Silence C
Enable / Silence / Disable
Enable / Silence / Disable
Enable / Silence / Disable
Enable / Silence / Disable
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).

y
This attribute is read-only at runtime.

Enabling, Silencing, and Disabling Alarms

op
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.
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.
To enable an Object’s alarms, you must ensure that the AlarmModeCmd and AlarmInhibit

C
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.
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
re-enabled. The disabled state is more restrictive than the silenced and enabled alarm states. A
disabled alarm does not require acknowledgment.
N

When Object alarms are disabled, an individual alarm that is enabled or silenced is forced to be
disabled.
When Object alarms are enabled 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 silenced and an individual alarm is enabled or silenced, the individual
o

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

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

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

y
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

op
disabled.

AlarmMode Attribute
The AlarmMode is a calculated attribute that identifies the Object alarm mode and is based upon
the current values of an Object’s:
 AlarmModeCmd attribute
 AlarmInhibit attribute

C
ot
N

Application Server checks the AlarmModeCmd and AlarmInhibit attributes of an Object and the
AlarmMode status of the parent Object. Application Server then updates the Object's AlarmMode
attribute to reflect the most restrictive setting.
All individual alarms use the Object's AlarmMode status to determine whether they are enabled,
silenced, or disabled.
o

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
D

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

y
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,

op
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
DescAttrName attribute can contain a static alarm description or a reference to
another string attribute within the same Object containing the alarm
description. The reference must be in the form: “me.AttrName”. If the reference
is invalid, the actual reference string is used for the description, if nothing is

<Attribute>.InAlarm
C
supplied for the DescAttrName attribute, the Object’s ShortDesc attribute is
used at runtime.
The alarm state. This is exactly the same as the attribute in the host primitive
that represents the alarm condition, except when the alarm state is disabled, in
which case, InAlarm is set to Off, regardless of the actual condition state.
The quality is set during execute to the quality of the attribute, except when the
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
or contained by this Object.
<Attribute>.Priority The value for the urgency of the alarm. Valid values are 1 through 999, with 1
N

being the most urgent.

<Attribute>.TimeAlarmAcked The timestamp indicating the last time this alarm was acknowledged. The date
format reflects the current locale setting for the operating system.
<Attribute>.TimeAlarmOff The timestamp indicating the last time this alarm (as represented by the
InAlarm attribute) went off. The date format reflects the current locale setting
for the operating system.
<Attribute>.TimeAlarmOn The timestamp indicating the last time this alarm (as represented by the
o

InAlarm attribute) went on. The date format reflects the current locale setting
for the operating system.
D

Application Server 2017

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

y
4 Low 751 - 999

op
C
ot
N

Understanding How Alarms Are Ranked at Runtime

The most important alarm has the lowest severity number, but other criteria are taken into account
when ranking alarms by urgency at runtime.
o

Alarm Mode Enabled is more urgent than silenced

InAlarm TRUE (InAlarm) is more urgent than FALSE (normal)
D

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

Wonderware Training
 Section 1 – Alarms and Events Overview 7-13

makes it possible to follow a trail from one level to the next to find the underlying cause of a
complex Object’s alarms.
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.

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

op
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.
Area Aggregation represents the alarms on the Area Object itself, on all objects

C
assigned to the area, and on all sub-Areas, down to the lowest level of the
Model view.
If the Area’s AlarmMode is silenced, all alarms on all Objects in that Area
will be silenced.

Alarms are aggregated if they are in one of three states:

ot
 UNACK_ALM
 ACK_ALM
 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

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

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

op
<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
InAlarm state have been acknowledged, whether or
not they are currently InAlarm.
<Attribute>.AlarmMostUrgentInAlarm FALSE (default) indicates that no alarms are in the Read-Only

<Attribute>.AlarmMostUrgentMode
C
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
the InAlarm state, whether or not they have been
acknowledged.
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
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).
N
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

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

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

op
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.
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
fashion to silenced alarms.

AlarmShelved
C
A set of seven attributes provide runtime alarm shelving information and control:

AlarmShelveCmd User writeable. Use this attribute to shelve or unshelve an alarm.

Default values: Duration = 0, Reason = ""
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,
based on the engine time when the shelving request was received.
Default value: Blank
N

AlarmShelveStopTime A read-only date/time stamp equal to the AlarmShelveStartTime plus

the duration for which the alarm is to be shelved.
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.
o

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

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

7-18 Module 7 – Alarms and Events

Enabling Alarm Shelving

Alarm shelving is configured from the IDE Configuration menu in 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

y
Obtain aggregated alarm severity status information by:
 Mapping alarm severity levels to priority ranges,
 Configuring alarms on objects,

op
 Enabling alarm aggregation by Area,
 Viewing aggregated alarm status information by means of runtime clients and
applications.

Mapping Alarm Severity to Priority

Use the IDE to map each of four alarm severities to priorities expressed as numeric ranges.

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

Default Alarm Mapping and Historization Values

From Priority To Priority
N

Severity Description Shelve Historize

Range Range
1 Critical N Y 1 250
2 High N Y 251 500
3 Medium Y Y 501 750
4 Low Y Y 751 999
o

An example is shown in the image on page 7-18.

Monitoring Alarm Severities at Runtime
D

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

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

y
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

op
configuration Categories:

 Discrete
 Value LoLo
 Value Lo
 Value Hi
 Value HiHi






DeviationMinor
DeviationMajor
ROC Lo
SPC
Process
System
C
ot
 Batch
 Software
N

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

Saving Alarms and Events as Historical Data

Alarms and events detected by the Application Server at runtime are saved as historical data to
the Process Historian for the host engine. In addition, alarm-related events such as Acknowledge
o

are also saved as historical alarm data.

D

Wonderware Training
 Section 1 – Alarms and Events Overview 7-21

What alarms and events are to be historized 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:
 Active alarms
 Unacknowledged alarms
N

 Disabled or silenced alarms

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.
When the associated tags in the InSightApp have alarms and events, the trend displays with
additional indicators.
o
D

Application Server 2017

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
C
For events, trend lines display with event icons. You can click on an icon to see additional
information related to that event.
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

y
alarms.

Objectives

op
Upon completion of this lab, you will be able to:
 Configure alarms in objects
 Interact with alarm attributes in Object Viewer
 View alarm and process history in Insight
 Retrieve alarm history from SQL Server

C
ot
N
o
D

Application Server 2017

7-24 Module 7 – Alarms and Events

Configure Alarming for the Galaxy

First, you will configure the $Mixer template 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
Limit alarms: locked
C
3. Scroll down and configure the Limit alarms group as follows:
ot
Hi: checked and locked (default)
Hi: Limit: 80.0 and unlocked
Hi: Priority: 100 and locked
Hi: Alarm message: Mixer Hi Level Alarm and locked
N

Lo: checked and locked (default)

Lo: Limit: 25.0 (default) and unlocked
Lo: Priority: 500 (default) and locked
Lo: Alarm message: Mixer Lo Level Alarm and locked
o
D

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

y
Read: selected
State alarm: checked and locked
Category: Process and locked (default)

op
Priority: 700 and locked (default)
Alarm message: me.Alarm.Condition.Description (default) and locked (default)
Active alarm state: True (default) and locked (default)

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

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
8. Deploy Mixer100. C
ot
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-20.
N

9. Switch back to Insight in your browser and ensure Level_001.PV is on trend.

o
D

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-27

10. In the timeline at the bottom of the window, set the time to the last hour to refresh the trend to
the most recent data.

y
op
C
You may need to zoom in on the trend by double-clicking the trend line or using your mouse
wheel to zoom in and out. Depending on your zoom level, you may see no alarm information,
alarm limit points only, or highlighted sections of the trend line indicating alarm states.
ot
N
o
D

Note: Since Mixer.Alarm.Condition has no historized process data, it cannot be added to

the trend to view alarm states.

Application Server 2017

7-28 Module 7 – Alarms and Events

View the Alarm States in Runtime

Now, you will return to Object Viewer to view alarm conditions, as well as high and low alarms.
11. View Mixer100 in Object Viewer.
12. Add a new watch window and name it Mixer100Alarms.
13. Add the following attributes to the watch window:
 Mixer100.Alarm.Condition
 Mxier100.Alarm.Condition.InAlarm

y
 Mixer100.Alarm.Condition.AckMsg
 Mixer100.Alarm.Condition.TimeAlarmOff
 Mixer100.Alarm.Condition.Time.Alarm.On

op
 Level_001.PV.Hi.InAlarm
 Level_001.PV.Lo.InAlarm
 Level_001.PV
 Level_001.PV.Hi.Limit
 Level_001.PV.Lo.Limit
 Level_001.PV.Hi.AckMsg
 Level_001.PV.Lo.AckMsg

C
ot
N
o
D

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-29

14. For Mixer100, add AlarmCntsBySeverity to the watch list.

y
The Array for Mixer100.AlarmCntsBySeverity dialog box appears.

op
15. In the Enter an array index field, enter -1.

16. Click OK.

C
ot
N
o

There are 13 counts available:

1-4: Active Alarms Per Severity
D

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

Application Server 2017

7-30 Module 7 – Alarms and Events

17. Double-click Level_001.PV.Hi.AckMsg.

18. Add a comment to acknowledge the alarm.

y
op
19. Click OK.

C
The message must change if you wish to acknowledge the alarm again later.
ot
When an alarm has been acknowledged, the severity count for the object should decrease.
N

20. Save the watch list.

o

21. Minimize Object Viewer.

D

Wonderware Training
 Lab 14 – Configuring and Interacting with Alarms 7-31

View the High-Speed Alarm History Data

Now, you will use Microsoft SQL Server Management Studio to view the latest recorded alarms
and events.
22. Open Microsoft SQL Server Management Studio.
The splash screen appears.

y
op
C
After a slight delay, the Connect to Server dialog box appears.
ot
N

23. Keep the default settings and click Connect.

o
D

Application Server 2017

7-32 Module 7 – Alarms and Events

24. On the File menu, click Open | File.

y
25. Navigate to C:\Training, and select SQLQuery1.

op
C
ot
N

26. Open the file.

o
D

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
op
The data appears in the bottom-middle pane.

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

7-34 Module 7 – Alarms and Events

y
op
C
ot
N
o
D

Wonderware Training
 y
op
C
Module 8 – Object Management
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
Lab 16 – Configuring Instances Using a .CSV File 8-35
N
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

y
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

op
session. If the designated file already exists, you are prompted to confirm overwrite.
If any of the selected objects are currently checked out, only the checked in versions are exported.
Exporting an entire Galaxy is similar to using the Galaxy Database Manager utility to back up the
database. However the change logs for the objects are not exported while they are saved during
backup. Also, the backup process retains security model settings for objects while exporting them
does not.
When exporting an object instance, it will also include the parents of that object all the way back to
and including the base template.

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

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
ot
(Shift+Click or Ctrl+Click). If you want to export all the objects in the Galaxy, click Export, and
then 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
C
Click Save. Click Cancel to terminate the export function. If you click Save, a progress box is
displayed.
ot
N
o

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

When the export process is finished, click Close. The resulting .aaPKG file can be used to import
the chosen objects into another existing Galaxy.

Application Server 2017

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.

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

op
Import Objects
To import Automation objects, on the Galaxy menu, select lmport | Object(s).

C
ot
N
o
D

Wonderware Training
 Section 1 – Object Export and Import 8-7

The Import AutomationObject(s) dialog box appears.

y
op
C
Browse for the file with either a .aaPKG or a .aaPDF extension. You can select more than one file.
Click Open.
ot
N
o
D

Application Server 2017

8-8 Module 8 – Object Management

The Import Preferences dialog box appears.

y
op
following:
C
In the Objects with same Tagname and Codebase as an existing object area, select one of the

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.
Overwrite objects regardless of configuration version replaces the existing object
regardless of whether the existing object has an older configuration or the same configuration.
N

In the Base Templates with a different revision number in the Codebase or a different minor
version area, select one of the following:
Skip: Do not migrate does not migrate objects with an older Codebase when a newer
Codebase exists in the Galaxy.
Migrate (default) migrates an older codebase when the replacement object is available.
o

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

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

y
Area.
 If the host to which the object is assigned does not exist, it is assigned to the Unassigned
Host.

op
 If you selected 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.

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.

C
ot
N
o
D

Application Server 2017

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.

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

op
 Use the Export Objects and Import Objects features of the ArchestrA IDE

C
ot
N
o
D

Application Server 2017

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, in the 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

3. Right-click $Storage and select Properties.

N
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.
The 1 indicates that this is the first version of the object.

y
op
C
ot
6. Click Close.
Now, you will make changes to the $Storage object and view the version changes.
N

7. Open the $Storage configuration editor.

8. Add an attribute named Pressure.
9. Configure Pressure as follows:

Data type: Integer

Category: User writeable (default)
o
D

Application Server 2017

8-14 Module 8 – Object Management

10. Add and configure another attribute named Density as follows:

Data type: Integer (default)

Category: User writeable (default)

y
op
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.
The ConfigVersion has changed to version 2. The ConfigVersion increases by 1 each time
changes to the object are checked in.

C
ot
N
o
D

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.aaPKG,
This corresponds with ConfigVersion 2.
N
o
D

19. Click Save.

Application Server 2017

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
op
20. Click Close.
21. Open the $Storage configuration editor.

Name
Viscosity
Hardness
Data Type
Integer
Integer (default)
C
22. Add and configure two new attributes as follows:
Attribute
Category
User writeable (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

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 File name field, enter $StorageV3.aaPKG.
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
op
The Delete dialog box appears.

C
ot
N

32. Click Yes to confirm deletion of the $Storage object.

o
D

Application Server 2017

8-20 Module 8 – Object Management

The $Storage object no longer appears in the Project toolset.

y
op
33. On the Galaxy menu, select Import | Object(s).

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.
C
The Import Preferences dialog box appears.
ot
N
o
D

36. Keep the default options and click OK.

Application Server 2017

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
op
37. Click Close.
$Storage appears again in the Project toolset.

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

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. Select $StorageV3.aaPKG.

y
op
C
ot
43. Click Open.
44. In the Import Preferences dialog box, keep the default options and click OK.
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
48. Click Close.
C
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

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, click the Overwrite objects regardless of configuration version
option.

y
op
C
ot
53. Click OK.
The Import Automation Object(s) progress appears with an Object 2 of 2 completed
N

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

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
op
60. Use the Galaxy menu to import $StorageV2.aaPKG file.
61. In the Import Preferences dialog box, keep the default options and click OK.

C
The Import Automation Object(s) progress shows that $Storage was not found, so the
object was created.
ot
N

62. Click Close.

o

Both objects now appear in the Project toolset. They are identical, except for their tag names.
D

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

y
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

op
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.
 Attributes that are not text based are not exported.
For example, type QualifiedStruct is not exported.
 Custom object online help files are not exported.

C
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.
On the Galaxy menu, select Export, and then click Galaxy Dump.
ot
N
o
D

Application Server 2017

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

y
converted to a carriage return in a Galaxy Load function.

op
C
ot
N
o
D

Application Server 2017

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

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

op
To import a .csv file, on the Galaxy menu, select Import, and then click Galaxy Load.

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

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
D

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

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

y
not contain quotation marks.

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.

y
Objectives

op
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

C
ot
N
o
D

Application Server 2017

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
C
2. On the Galaxy menu, select Export | Galaxy Dump.
ot
N
o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-37

3. Navigate to C:\Training and in the File name field, enter Mixer.csv.

y
op
4. Click Save.
C
When the Galaxy Dump is complete, the progress displays 100% processed.
ot
N
o

5. Click Close.
D

Application Server 2017

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 navigate to the C:\Training folder.
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. Keep all other default options and click Next.
ot
The Text Import Wizard - Step 2 of 3 dialog box appears.
12. Uncheck the Tab check box, and then check the Comma check box.
N
o
D

13. Click Finish.

Application Server 2017

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 F6), 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 F10
Inlet1_001 Inlet Valve 1 F14
Inlet2_001 Inlet Valve 2 F18
Level_001 Tank Level F22
Outlet_001 Outlet Valve F26
Pump1_001 Pump 1 F30

y
Pump2_001 Pump 2 F34
Temperature_001 Mixer Temperature F38

op
The cells now display the new short description names.

C
ot
N
o
D

Application Server 2017

8-42 Module 8 – Object Management

17. On the File menu, click Save As and navigate to C:\Training.

18. In the File name field, enter Mixer1.csv.
19. In the Save as type drop-down list, select CSV (Comma delimited).

y
op
20. Click Save.
C
The Microsoft Excel dialog box appears, confirming if you are sure you want to keep the
ot
format.

Note: This dialog box will vary depending on your version of Microsoft Excel.
N

21. Click Yes to retain the .csv format.

o

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

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. Select the Mixer1 file.

C
ot
N
o

26. Click Open.

D

Application Server 2017

8-44 Module 8 – Object Management

The Galaxy Load Conflict Resolution dialog box appears.

27. Select the Only update changed attributes option.

y
op
28. Click OK.
When the Galaxy Load is complete, the progress displays 100% processed.

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
Mixer100:
Agitator_001:
Mixing Tank
Agitator Motor
C
30. For the following objects, open the configuration editor, click the Object Information tab and
verify the Description fields match those you entered in Microsoft Excel:
ot
Inlet1_001: Inlet Valve 1
Inlet2_001: Inlet Valve 2
Level_001: Tank Level
Outlet_001: Outlet Valve
N

Pump1_001: Pump 1
Pump2_001: Pump 2
Temperature_001: Mixer Temperature
o
D

31. Close the configuration editors.

Application Server 2017

8-46 Module 8 – Object Management

32. In the Deployment view, deploy Mixer100, and then verify the Cascade Deploy option is
checked.

y
op
33. Keep all other default options and click OK.
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:

C
You can use the Replace All feature to make these changes.
ot
N

41. Rename everything named Line1 to Line2.

o
D

Application Server 2017

8-48 Module 8 – Object Management

42. Verify that the object tagnames were changed with the Replace All feature.
43. 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

44. On the File menu, click Save As and navigate to the C:\Training folder.
45. In the File name field, enter Mixer2.csv.
46. In the Save as type drop-down list, verify that CSV (Comma delimited) is selected.

y
op
47. Click Save.
C
The Microsoft Excel dialog box appears, confirming if you are sure you want to keep the
ot
format.
N

48. Click Yes to retain the .csv format.

49. Close Microsoft Excel.
The Microsoft Excel dialog box appears, prompting you to save your changes.
o
D

50. Click Don’t Save.

Application Server 2017

8-50 Module 8 – Object Management

51. In the ArchestrA IDE, on the Galaxy menu, select Import | Galaxy Load.
52. Select Mixer2.

y
op
53. Click Open.
C
The Galaxy Load Conflict Resolution dialog box appears.
ot
N

54. Keep the default options and click OK.

o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-51

When the Galaxy Load is complete, the progress displays 100% processed.

y
op
55. Click Close.
56. In the Model view, expand Line2 and note that the new Mixer200 instance has been added to
the Line2 area.
57. 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 Lab
12), all objects assigned to that area will automatically be autobound to the same IO source.

58. Deploy Mixer200 and all its contained objects.

o
D

59. In the Deploy dialog box, keep the default options and click OK.

Application Server 2017

8-52 Module 8 – Object Management

60. When the Deploy progress is 100% completed, click Close.

Mixer200 and its contained objects have been deployed.

y
op
C
ot
N
o
D

Wonderware Training
 Lab 16 – Configuring Instances Using a .CSV File 8-53

61. View Mixer200 in Object Viewer.

62. In Object Viewer, create a watch window called Mixer200 and add the following attributes to it:
 Level_002.PV
 Temperature_002.PV
 Agitator_002.CMD
 Agitator_002.PV
 Agitator_002.Speed.PV
 Agitator_002.Speed.SP

y
 Inlet and Outlet CMDs and OLSs
 Pump CMDs and PVs

op
C
ot
63. Save the watch list.
64. Minimize Object Viewer.
N
o
D

Application Server 2017

8-54 Module 8 – Object Management

y
op
C
ot
N
o
D

Wonderware Training
 y
op
Section 1 – Security Overview
C Module 9 – Security
9-3
ot
Lab 17 – Configuring Security 9-11
Section 2 – Object Security 9-37
Lab 18 – Implementing Object Security 9-41
N
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

y
 ArchestrA System Management Console (SMC) for performing maintenance and system
administration functions.
 Any runtime operations.

op
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
the system.
If your application requires a higher level of security, this can be achieved by typical IT
departments using tools provided by Microsoft®. To facilitate a higher level of security, the security

C
model can be configured to support operating system authentication. In that case, the
configuration and runtime permissions can be mapped to the external operating system account.
Some options include password timeout and electronic signature authentication.

The ArchestrA Security Model

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

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

y
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

op
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
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.
Permissions are required to perform most ArchestrA activities. Usually only one permission is

C
required to perform a given activity, but occasionally, two or more permissions may be required for
operation-critical actions.
The final aspect of the Security Model is the User. This describes the access to the system allowed
by a User. The User can be granted as many Roles as needed to perform their job.
ArchestrA's security system is configured in the Configure Security dialog box by:
ot
 Enabling Security
 Defining your Security Model
 Mapping Users to the Security Model
 Mapping AutomationObjects to the Security Model
If the Security is not enabled then Authentication mode is disabled.
N
o
D

Wonderware Training
 Section 1 – Security Overview 9-5

Authentication Mode

y
op
C
ot
On the Authentication Mode page, choose the mode of Galaxy security:
 None: The default setting for new Galaxies, this mode is considered Open Security. It
leaves all functions open to all users. No authentication is provided for any operations in
N

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
o

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
D

system's user authentication system, on a group basis. When you select OS Group Based
Authentication mode, the following Configurable Intervals options are displayed:
 Login time: This value (in milliseconds) is the timeout period during which the system
validates the user's membership against the OS groups selected as ArchestrA Roles.
After this timeout period, the login operation defaults to the local cache. The result of a
successful login for a value other than 0 (zero) is that local cache is stored/updated. If
the login operation times out and the user has performed a previous ArchestrA login
on the computer, local cache is used; if the user has never performed an ArchestrA
login on the computer, the ArchestrA login fails. Minimum allowed value is 0 (zero);

Application Server 2017

9-6 Module 9 – Security

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

y
(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

op
Login time option. In other words, even if Login time times out, the role update
operation continues in the background and eventually updates user-to-role
relationships for this user in the local cache.

Note: When you select Authentication Modes, note the messages relevant to your ArchestrA
installation that are displayed in the Note box.

Authentication Mode selections provide the following general results:




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
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.
ot
 When you close the Configure Security dialog box after selecting any Authentication
Mode other than None, you must login. This action ensures that the new security model
can be enforced. If you select Cancel on the login dialog box, the ArchestrA IDE closes.
 When you switch to None from another Authentication Mode and click OK, the
ArchestrA IDE is shut down.
N

 When Galaxy authentication is selected, each user must provide a user name and
password in a login dialog box. The security system authenticates the user's credentials
against Galaxy user data. Access to all operations in the ArchestrA IDE and anywhere in
the ArchestrA environment are granted based on the logged in user's associated roles
and permissions. The ArchestrA IDE customizes the user interface to the user's previous
preferences (for instance, which Application Views are shown). The logged in user's
name is shown in the status bar of the ArchestrA IDE.
o

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

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.

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

op
OS Group Based Security
If you use OS Group Based Authentication Mode, you should first familiarize yourself in depth with
the functions of the Windows operating system, particularly its user permissions, groups and
security features. ArchestrA OS Group Based security leverages those Windows features.
Take note of the following behaviors that are unique to OS Group Based Authentication Mode:



C
A newly-added user working on a computer that has no access to the Galaxy node cannot
write to an attribute on a remote node if that user has never logged on to the remote node.
This is true even if the user has been given sufficient runtime operational permissions to
do writes. To enable remote writing capabilities, log on to the remote node at least once.
If you log in to ArchestrA on a workstation that belongs to Domain A and Domain
Controller A fails, locally cached login data is used on subsequent logins. When the
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
the new login data. If that fails, the trusts are being reestablished by the controller, and you
should retry at a later time.
N

 The user's full name is not available to any client (for instance, an InTouch window) if the
domain controller is disconnected from the network when the user logs in to ArchestrA for
the first time. If the user previously logged in to ArchestrA when the domain controller was
connected, the user's full name will still be available to the client from data stored in cache
even if the domain controller is disconnected when the user subsequently logs in to
ArchestrA.
o

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

“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

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

y
Supported Operating System Security Configurations
The following list of OS security configurations will be supported:

op
 Machines and users participating in a domain.
 Users being drawn from multiple domains.
 Machines and users defined within a Workgroup. Note the users/groups have been
defined on each machine and imported into the Galaxy Repository (GR) and defined as
Local Host.

Logon Dialog Box

C
If security is enabled within the Galaxy, a client utility Logon dialog box will appear. Application
Server provides a standard login dialog. The login appears:
 The user explicitly chooses a Log On option from within the user interface. It is not
necessary to explicitly Log Off before logging on using a different User Profile. The
ot
previous user will be implicitly logged off.
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
accessible domain name for the user being logged in.
N

Security Roles
You can create and manage user roles that apply to your organization’s processes and work-
based authorities. Two roles are defined by default: Administrator and Default.

Security Users
o

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
D

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:

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

op
 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,
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
DiscreteDevice input



runtime environment

C
Can Acknowledge Alarms: Allows users to manually acknowledge an alarm in the

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

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.

y
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

op
for configuration (General permissions) and runtime (Operational permissions).

Objectives
Upon completion of this lab, you will be able to:
 Configure security in a Galaxy



Enable OS Group security
Create and use security groups

C
Add security roles and assign permissions to them
Configure general permissions
ot
N
o
D

Application Server 2017

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

y
Important: Do not click OK at this point!

op
C
ot
N
o
D

Application Server 2017

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

5. Click the Add new Security Group button.

o

6. In the Security Groups available list, enter Line1 and press Enter.
D

Wonderware Training
 Lab 17 – Configuring Security 9-15

7. Add the following security groups:

 Line2
 ControlSystem

y
8. Select the Default security group.

op
C
ot
N
o
D

Application Server 2017

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:
 Mixer100
 Agitator_001
 Inlet1_001
 Inlet2_001
 Pump1_001
 Pump2_001
Outlet_001

y


 Level_001
 Temperature_001

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

9-18 Module 9 – Security

11. Move the following instances from the Default security group to the Line2 security group:
 Mixer200
 Agitator_002
 Inlet1_002
 Inlet2_002
 Pump1_002
 Pump2_002
 Outlet_002

y
 Level_002
 Temperature_002

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

9-20 Module 9 – Security

13. Move the following instances from the Default security group to the ControlSystem security
group:
 ProdPlatform
 GRPlatform
 AppEngine1
 ControlSystem
 ProdPLC
 R_ProdPLC1
R_ProdPLC2

y


 Simulator

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
op
After the assignments, the Default security group will contain only the objects that were not
moved.

C
ot
N
o
D

Application Server 2017

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 ('LKF' in the graphic below) or leave
"." if no domain controller is available.

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

Application Server 2017

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:
 Application Developers 1
 Plant Maintenance 1
N

 Plant Operators 1
 Plant Operators 2
 Plant Supervisors 1
o
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

Important: Do not click OK at this point!

o
D

Application Server 2017

9-26 Module 9 – Security

Next, you will configure permissions for the built-in Default security role.
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.

y
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

op
Viewer in a later lab.

24. In the Operational permissions list, uncheck the Default security group.

C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-27

You will now configure permissions for the added security roles.
25. Configure the Application Administrators security role as follows:

General permissions:
IDE Permissions (checked)
SMC Permissions (checked)
Operational permissions:
Default (checked)

y
Line1 (checked)
Line2 (checked)
ControlSystem (checked)

op
C
ot
N
o
D

Application Server 2017

9-28 Module 9 – Security

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

Wonderware Training
 Lab 17 – Configuring Security 9-29

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

y
Line2
Can modify "Configure" attributes (checked)

op
Can modify "Operate" attributes (checked)
ControlSystem
Can modify "Configure" attributes (checked)
Can modify "Operate" attributes (checked)

C
ot
N
o

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

Application Server 2017

9-30 Module 9 – Security

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

y
Line2
Can modify "Configure" attributes (checked)

op
Can modify "Tune" attributes (checked)
ControlSystem
Can modify "Configure" attributes (checked)
Can modify "Tune" attributes (checked)

C
ot
N
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-31

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

Application Server 2017

9-32 Module 9 – Security

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

Wonderware Training
 Lab 17 – Configuring Security 9-33

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

y
Line2
Alarms
Can acknowledge Alarms (checked)

op
Can modify "Operate" attributes (checked)
Can Verify Writes (checked)
ControlSystem
Alarms
Can acknowledge Alarms (checked)
Can modify "Operate" attributes (checked)
Can Verify Writes

C (checked)
ot
N
o
D

32. Click OK to apply the security configuration.

Application Server 2017

9-34 Module 9 – Security

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.
33. 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 LKF
Monica Reed MonicaR ww LKF

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
34. Click OK.
The Change User dialog box reappears.
35. Log in as one of the members of the Application Developers 1 security role:
N

Role First, Last User name Password Domain

Application Developers 1 Thomas Miller ThomasM ww LKF
Carol Morris CarolM ww LKF
o
D

Wonderware Training
 Lab 17 – Configuring Security 9-35

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
C
ot
N
o
D

Application Server 2017

9-36 Module 9 – Security

y
op
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

y
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

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

C
ot
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
N

enabled in the parent template. If an attribute's security classification is configurable, click the
security control to select one of seven possible states:

Security Icon Description

Free Access 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
o

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
D

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.
Secured Write 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.
Verified Write 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

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.
Read Only Only allows users to read this attribute’s value in the run-time environment.

y
This attribute is never written to at run time, regardless of the user's
permissions.

op
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
The lock and security controls associated with option groups and features quickly set those
conditions for all options in the group.

the group control shows an indeterminate icon.

C
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,

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

derived children. If you change the value in the parent template, the change propagates to all child
objects

Security Audit Trail

Application Server creates several types of run-time event messages, including security-audit
o

(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
D

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

y
operator change.
 Operator1, which is the full name of the primary operator requesting a change. The full
name is an attribute of the UserProfile.

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

Security Query

C
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 Process Historian computer.
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

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

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

op
Objectives
Upon completion of this lab, you will be able to:
 Configure security classifications for object attributes
 Perform secured and verified writes with Object Viewer
View the security audit trail


C
ot
N
o
D

Application Server 2017

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. In the ArchestrA IDE, Template Toolbox, Training\Project template toolset, open the
$Mixer.Agitator configuration editor.
2. On the Attributes tab, in the attributes list, select the Speed.SP attribute.

y
op
C
ot
3. To the right of the Initial value field, click the shield icon and change the security classification
to SecuredWrite.
N
o
D

Wonderware Training
 Lab 18 – Implementing Object Security 9-43

4. Click the lock icon to propagate the security classification to the derived instances.

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

op
C
ot
6. Click Close.
Now that the security classification has been propagated to the instances, the Speed.SP attribute
needs to be unlocked to allow changing its value in runtime.
7. In the Template Toolbox, reopen the $Mixer.Agitator configuration editor.
N

8. In the attributes list, select the Speed.SP attribute.

9. Unlock the Initial Value property.
o
D

Application Server 2017

9-44 Module 9 – Security

10. 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
11. Click Close.
Next, you will change the security classification of the $Mixer.Outlet attribute in the mixer to
VerifiedWrite.

C
12. In the Template Toolbox, open the $Mixer.Outlet configuration editor.
13. 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

14. To the right of the Initial value field, click the shield icon and change the security classification
to VerifiedWrite.
15. Click the lock icon to propagate this change to the derived instances.

y
op
16. Save and close the $Mixer.Outlet template, and then check in the object with an appropriate
comment.

C
17. When check in is complete, click Close.
18. Reopen the $Mixer.Outlet configuration editor.
19. On the Attributes tab, in the attributes list, ensure the CMD attribute is selected.
ot
20. To the right of the Initial value field, unlock the attribute.
N

21. Save and close the $Mixer.Outlet template, and then check in the object with an appropriate
comment.
o

22. When check in is complete, click Close.

D

Application Server 2017

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.
23. If Object Viewer is open, close it now.
24. In Deployment view, expand all objects.

y
op
C
ot
N
o

25. Deploy the TrainingGalaxy.

26. Keep the default selections and click OK.
D

This will take several moments.

Wonderware Training
 Lab 18 – Implementing Object Security 9-47

27. When the deployment is complete, click Close.

Now, you will test the security classifications and permissions in runtime using Object Viewer.
28. 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
ot
29. In Object Viewer, click the Options menu and select Change User.
N
o

The Change User dialog box appears.

D

Application Server 2017

9-48 Module 9 – Security

30. 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 LKF
Lisa Young LisaY ww LKF

y
op
31. Load the watch list that was saved earlier and switch to the Mixer200 watch window.
32. Double-click Inlet2_002.CMD.

C
ot
33. In the Modify Boolean Value dialog box, select True.
N
o

34. Click OK.

D

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.

y
op
35. Click OK.
36. On the Mixer100 watch window, double-click Inlet1_001.CMD.

C
ot
37. In the Modify Boolean Value dialog box, select True.
N
o

38. Click OK.

D

Application Server 2017

9-50 Module 9 – Security

This time the command was executed because Plant Operators 1 have Operate permissions
over Line 1 objects.

y
op
Next, you will test the Configure Security classification.
39. 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 LKF
Monica Reed

CMonicaR ww LKF
ot
N
o
D

Wonderware Training
 Lab 18 – Implementing Object Security 9-51

40. 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
41. Save the watch list.
C
ot
42. Double-click Temperature_001.PV.EngUnitsRangeMax and change the value to 505.0.
N
o
D

43. Click OK.

Application Server 2017

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.

y
op
44. Click OK.
45. Double-click Temperature_001.ScanStateCmd and change the value to False,

C
ot
N

46. Click OK.

o
D

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.

y
op
47. Click OK.
48. 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
Lisa Young

C JohnJ
LisaY
ww
ww
LKF
LKF

49. Double-click Temperature_001.ScanStateCmd and change the value to False to place the
object off scan.
ot
This time the change takes effect.
N
o
D

50. 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 LKF
Monica Reed MonicaR ww LKF

Application Server 2017

9-54 Module 9 – Security

51. 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
52. Double-click Temperature_001.PV.EngUnitsMax and change the value to 500.0.
ot
N
o
D

53. 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 LKF
Lisa Young LisaY ww LKF

Wonderware Training
 Lab 18 – Implementing Object Security 9-55

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

y
55. Double-click Agitator_001.Speed.SP and change the value to 25.0.

op
56. Click OK.

C
Since the attribute has a security classification of SecuredWrite, you are prompted for your
password.
57. Enter the password.
ot
N

58. Click OK.

o
D

Application Server 2017

9-56 Module 9 – Security

The value is written to the attribute.

y
op
C
Now, you will test the VerifiedWrite security classification by first making it fail, and then you will
log in with Plant Supervisor credentials.
59. 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.
60. Enter ww as your password and the credentials of the other user below in the Plant
Operators 1 security role.

Important: For this authentication dialog box, the second user name must be entered in the
form of domain\userid.
N

Role First, Last User name Password

Plant Operators 1 John Johnson LKF\JohnJ ww
Lisa Young LKF\LisaY ww
o
D

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

y
op
62. Click OK.
63. Double-click Outlet_001.CMD, change the value to True, and click OK.
64. Enter ww as your password and the credentials of one of the following users in the Plant
Supervisors 1 security role.

form of domain\userid.

Role
Plant Supervisors 1 Michael Jones
C
Important: For this authentication dialog box, the second user name must be entered in the

First, Last User name

LKF\MichaelJ
Password
ww
ot
Karen Turner LKF\KarenT ww
N
o

65. Click OK.

D

Application Server 2017

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
View the Security Audit Trail
C
Now, you will use Microsoft SQL Server Management Studio to view the security-related events for
the last hour.
ot
66. Start Microsoft SQL Server Management Studio.
After a slight delay, the Connect to Server dialog box appears.
N
o
D

67. Verify the Server name is the same as the Process Historian computer and click Connect.

Wonderware Training
 Lab 18 – Implementing Object Security 9-59

68. On the File menu, click Open | File.

y
op
69. Navigate to C:\Training, and select SQLQuery2.

C
ot
N
o

70. Open the file.

D

Application Server 2017

9-60 Module 9 – Security

71. On the toolbar, click Execute.

y
op
The data appears in the bottom-middle pane.

C
ot
N
o
D

72. Scroll to the right to view all the data.

Notice the comment field that shows the write attempts.
73. Exit Microsoft SQL Server Management Studio.

Wonderware Training
 y
op
C
Module 10 – Introduction to
QuickScript.NET
ot
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
N

Lab 20 – Scripting Valve Status 10-29

Lab 21 – Scripting Custom Alarms 10-37
o
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

y
actions. Simple scripts are described in this section.
 Complex scripts can perform logical operations using conditional branching with IF-THEN-
ELSE type control structures.

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

C
Required Syntax for Expressions and Scripts
The syntax in scripts is similar to the algebraic syntax of a calculator.
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.
 Statements must end with a semicolon (;).
Entities can be concatenated by using the plus (+) operator. For example, if a data change script
N

such as the one below is created, each time the value of “Number” changes, the indirect entity
“Setpoint” changes accordingly:
Number=1;
Setpoint = "Setpoint" + Text(Number, "#");
Where the result is “Setpoint1.”
o

Simple Scripts
Simple scripts implement logic such as assignments, math, and functions. An example of this type
of scripting is:
D

React_temp = 150;
ResultTag = (Sample1 + Sample2)/2;
{this is a comment}

Application Server 2017

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

Click the Add button to add a new script.

 Inherited scripts name list: Shows all scripts associated with the object's parent. The
columns indicate which kind of trigger the script uses: Startup, On Scan, Execute, Off
Scan and Shutdown.
 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
o

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
D

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 Process Historian
Server historian, the ArchestrA historian.
 Script Editor box: Shows the script you are writing.

Script Development Environment

y
Attribute Browser

op
From within the Script Editor the user can leverage the Attribute-Picker tool to browse through the
attribute namespace of the hosting object and other objects to pick a certain attribute to be
included in the script code. The tool does not distinguish between attributes of on-engine and off-
engine objects.

Script Function Browser

C
Like the InTouch script editor, the name of the selected script function and its calling syntax will be
added to the script text when the user picks it in the script function browser. In addition to being
able to insert the function call, the user can also enter a type declaration statement for object
names. In addition, the browser provides the user the ability to distinguish between properties and
methods.
Similar to browsing for script functions, the user can also browse for .NET / COM objects that have
ot
been imported using the ArchestrA IDE.

Syntax Validation
Script language syntax validation is performed by selecting the red check mark above the script
window.
N

This operation will identify and inform/warn the script developer of any syntax errors in the script. It
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.
o
D

Application Server 2017

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

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

op
Execute
Execute scripts are called each time the AppEngine performs a scan and the object is OnScan.
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
script.

following conditional trigger types:




C
If the quality check-box is checked, the Execute method is similar to InTouch scripts with the

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

next scan.
These scripts also have time-based considerations. A trigger period of 0 means that the script
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
o

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

 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

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

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

op
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
.NET objects and to free memory.

Language Definition

C
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the
case is preserved throughout editor sessions.
Both single line and multi-line comments are supported. Single line comments start at a ' in a
source code line that has no matching ending ' in the line. Multi-line comments start with a { and
end with a } and can span multiple lines as the name suggests.
ot
Examples:
Dim A; 'This is a single line comment
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
N

space must appear between adjacent identifiers, and spaces and line breaks cannot appear within
identifiers and numbers. Individual statements are distinguished by a semicolon that marks the
end of a statement.

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

C:\Program Files\ArchestrA\Framework\Docs\1033.
D

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,

y
and other script elements.
These features serve as convenient documentation of method parameters and scripting syntax as
well as an enhanced input method.

op
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
context from the icons displayed with the list items.

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

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

y
that will indicate the number of disconnects the object has experienced since it last went on scan.

Objectives

op
Upon completion of this lab, you will be able to:
 Create scripts in an object
 Create scripts with multiple execution types
 Add reconnect functionality to a $DDESuiteLinkClient object

C
ot
N
o
D

Application Server 2017

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 C
3. Name the new script Reconnect and press Enter.
button.
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

y
Script body: Me.Reconnect = true;

op
C
ot
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
N

error, it will appear in an error message.

5. To the right of the Execution type drop-down list, click the Validate Script button.
o
D

If nothing happens, the validation is successful.

Application Server 2017

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

y
op
Now, you will add a script to monitor the connection status.
7. On the Scripts tab, add a script named Disconnect.Monitor.
8. Configure the Disconnect.Monitor script as follows:

Aliases:
Declarations:
Scripts: Execution type:
Basics:
Expression:
locked
locked

C
Execute (default) and locked
locked
Me.ConnectionStatus <> 2
ot
Trigger type: OnTrue
Script body: Me.Disconnect.Cnt = Me.Disconnect.Cnt + 1;

This script will increase a counter by one every time the condition is true.
N
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
op
Notice that the locking of the Aliases and Declarations did not change because you are still
in the same script.
12. Validate the script.

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

13. 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 propagated to both R_ProdPLC instances.
o
D

14. Click Close.

Application Server 2017

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

16. Click Close.

D

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

y


 Reconnect.ExecutionCnt

op
C
ot
N
o
D

19. Save the watch list.

Application Server 2017

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.
Notice that the SMC now displays a red error icon, indicating the server has stopped.
N
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).

y
23. In the SMC, reactivate the OI.MBTCP.1.

op
C
ot
After a few seconds, your watch list will display that the data is once again connected.
N
o

24. Minimize Object Viewer.

D

Application Server 2017

10-20 Module 10 – Introduction to QuickScript.NET

y
op
C
ot
N
o
D

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.

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

op
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 statement syntax is
as follows:
DIM <variable_name> [ ( <upper_bound>
[, <upper_bound >[, < upper_bound >]] ) ]
[ AS <data_type> ];
where:

DIM
<variable_name>
C
Required Keyword
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
specified, it is fixed after the declaration. A statement similar to Visual Basic’s
ReDim is not supported.
N

The lower bound of each array dimension is always 1.

AS Optional keyword for declaring the variable’s datatype.
<data_type> Any one of the following 8 datatypes:
Boolean, Integer, ElapsedTime, Float, Double, String, Time, or
InternationalizedString
Data_type can also be a .NET data_type like System.Xml.XmlDocument or a
o

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

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

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.

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

op
Do not cascade DIM statements. For example, the following examples are invalid:
DIM LocVar1 AS Integer, LocVar2 AS Float;
DIM LocVar3, LocVar4, LocVar5, AS String;
To declare multiple variables, you must enter separate DIM statements for each variable.
When used on the right side of an equation, declared local variables always cause expressions on

dim x as integer;
dim y as integer;
x = 5;
C
the left side to have Good quality. For example:
ot
y = 5;
me.attr = 5;
me.attr = x;
me.attr = x+y;
In each case of me.attr, quality is Good.
N

When you use a variable in an expression to the right of the operator, its Quality is treated as Good
for the purpose of data quality propagation.
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,
o

however, test a variable for null. For example:

IF myvar == null THEN ...
D

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

y
IF … THEN … ELSEIF … ELSE … ENDIF
IF-THEN-ELSE-ENDIF conditionally executes various instructions based on the state of an

op
expression. The syntax is as follows:
IF <Boolean_expression> THEN;
[statements];
[ { ELSEIF;
[statements] } ];
[ ELSE;
[statements] ];
ENDIF;

Data Type
Boolean
Mapping
C
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
True or False state according to the following table:

Directly used (no mapping needed)

ot
Integer Value = 0 evaluated as False
Value != 0 evaluated as True
Float Value = 0 evaluated as False
Value != 0 evaluated as True
Double Value = 0 evaluated as False
N

Value != 0 evaluated as True

String Cannot be mapped. Using an expression that results in a string type
as the Boolean_expression results in a script validation error.
Time Cannot be mapped. Using an expression that results in a time type as
the Boolean_expression results in a script validation error.
ElapsedTime Cannot be mapped. Using an expression that results in an elapsed
o

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
D

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

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:

y
IF <Boolean_expression> THEN;
[statements];
[ { ELSEIF;

op
[statements] } ];
[ ELSE;
[statements] ];
ENDIF;
ENDIF;
This approach nests a brand new IF compound statement within a previous one and requires an
additional ENDIF.

C
IF … THEN … ELSEIF … ELSE … ENDIF and Attribute Quality
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;
temp = me.Attribute1;
me.Attribute2 = temp;
If there is a comparison such as Attribute1 <> Attribute2 and one of the Attributes has the quality
N

BAD, then the statements within the IF control block are not executed. For example, assuming
Attribute1 has the quality BAD:
if me.Attribute1 <> me.Attribute2 then
me.Attribute2 = me.Attribute1;
endif;
In this script, the statement me.Attribute2 = me.Attribute1 is not executed because Attribute1 has
o

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

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;

y
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

op

the loop
 end_expression is a valid expression. If analog_var is greater than end_expression,
execution of the script jumps to the statement immediately following the NEXT statement;
this holds true if loop is incrementing up, otherwise, if loop is decrementing, loop
termination occurs if analog_var is less than end_expression
 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



C
If change_expression is positive, start_expression must be less than or equal to
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.
The FOR loop is executed as follows:
1. analog_var is set equal to start_expression.
N

2. If change_expression is positive, the system tests to see if analog_var is greater than

end_expression. If so, the loop exits. If change_expression is negative, the system tests to
see if analog_var is less than end_expression. If so, program execution exits the loop.
3. The statements in the body of the loop are executed. The loop can potentially be exited via the
EXIT FOR statement.
o

4. analog_var is incremented by 1,-1, or by change_expression if it is specified.

5. Steps 2 through 4 are repeated.
D

Note: FOR-NEXT loops can be nested. The number of levels of nesting possible depends on
memory and resource availability.

Application Server 2017

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;

y
where:
 object_variable is a dimmed variable

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

TRY ... CATCH

TRY ... CATCH provides a way to handle some or all possible errors that may occur in a given

catch block.

C
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

The general format for TRY ... CATCH is as follows:

TRY
[try statements] ’guarded section
ot
CATCH
[catch statements]
ENDTRY;
where:
N

tryStatements
Statement(s) where an error can occur. Can be a compound statement. The tryStatement is a
guarded section.
catchStatements
Statement(s) to handle errors occurring in the associated Try block. Can be a compound
o

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
D

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.

y
Example:
dim command = new System.Data.SqlClient.SqlCommand;

op
dim reader as System.Data.SqlClient.SqlDataReader;
command.Connection = new System.Data.SqlClient.SqlConnection;
try
command.Connection.ConnectionString = "Integrated Security=SSPI";
command.CommandText="select * from sys.databases";
command.Connection.Open();
reader = command.ExecuteReader();

catch
while reader.Read()
me.name = reader.GetString(0);
LogMessage(me.name);
endWhile; C
ot
LogMessage(error);
endtry;
if reader <> null and not reader.IsClosed then
reader.Close();
endif;
N

if command.Connection.State == System.Data.ConnectionState.Open
then
command.Connection.Close();
endif;

WHILE Loop
o

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

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

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.

y
Quality of Input, InputOutput, and Output Extensions

op
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.
While the extended object is On Scan, it behaves as follows: If an external set (for example, from a
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.

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

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

op
 Use a script to calculate the state of a valve
 Create an attribute with an Array value

C
ot
N
o
D

Application Server 2017

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
2. In the Attributes list, select OLS and modify the configuration as follows:
N

'False' label: Not Open and locked (default)

o
D

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
Writeability: Calculated
N
o
D

Application Server 2017

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

y
1 Closed
2 Open

op
3 Traveling
4 Fault

C
ot
6. Create and configure another attribute as follows:

Name: PVState
Description: Integer Value of Valve State and locked
Data type: Integer
N

Array: unchecked
Writeability: Object writeable (default)
Initial value: unlocked
o
D

Wonderware Training
 Lab 20 – Scripting Valve Status 10-33

The attributes are now visible in the attribute list.

y
op
Add Script to Calculate Valve State
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:

Aliases: locked
Declarations: locked
N

Execution type: Execute (default) and locked

Basics: locked
Expression: Me.OLS or Me.CLS
Trigger type: DataChange
o
D

Application Server 2017

10-34 Module 10 – Introduction to QuickScript.NET

9. In the script body, enter the following:

Script Body:
Note: For your convenience, you can find the script body in
C:\Training\Lab 20 – Scripting Valve Status.txt.

if (not Me.OLS and Me.CLS)

then Me.PVstate = 1; 'Closed
elseif (Me.OLS and Not Me.CLS)
then Me.PVstate = 2; 'Open

y
elseif (not me.OLS and not Me.CLS)
then Me.PVstate = 3; 'Travelling

op
else
Me.PVstate = 4; 'Fault
endif;

Me.PV = Me.PVStates[Me.PVState];

C
ot
N
o
D

10. Validate the script.

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.

C
The valves all indicate they have configuration changes that need to be deployed.
ot
N
o
D

13. Deploy the valves.

Application Server 2017

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

y
 PV
Observe the results as the valve opens and closes.

op
17. Save the watch list and minimize Object Viewer.

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.

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

op
 Use attributes and scripting to determine custom alarm conditions

C
ot
N
o
D

Application Server 2017

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

y
Data type: Boolean (default)
Writeability: Calculated
State alarm: checked and locked

op
Category: Process
Priority: 500 (default)
Active alarm state: True (default)

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.

y
op
C
ot
The attributes are now visible in the attribute list.
N
o
D

Application Server 2017

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

y
Basics: locked
Expression: Me.Inlet1.PVState == 1 or Me.Inlet2.PVState == 1 or Me.Pump1.PV or

op
Me.Pump2.PV
Trigger type: While True (default)

C
ot
N
o
D

Wonderware Training
 Lab 21 – Scripting Custom Alarms 10-41

6. In the script body, enter the following:

Script Body: For your convenience you can find the script body in
C:\Training\Lab 21 – Scripting Custom Alarms.txt.
If (Me.Inlet1.PVstate == 1 and Me.Pump1.PV) then
Me.Flow.Alarm.Pump1 = true;
Else
Me.Flow.Alarm.Pump1 = false;

y
Endif;

op
If (Me.Inlet2.PVstate == 1 and Me.Pump2.PV) then
Me.Flow.Alarm.Pump2 = true;
Else
Me.Flow.Alarm.Pump2 = false;
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.
8. In the Execution type drop-down list, select OnScan.

Application Server 2017

10-42 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 21 – Scripting Custom Alarms.txt.

Me.Flow.Alarm.Pump1 = false;
Me.Flow.Alarm.Pump2 = false;

y
op
10. Validate the script.
Notice that the Flow.Alarm.Condition script now has OnScan and Execute scripts.

C
ot
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.
N
o
D

12. Click Close.

The Deployment view displays that both mixers need to be redeployed.
13. Deploy Mixer100 and Mixer200 and keep 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

y
 Pump1_001.CMD
 Mixer100.Flow.Alarm.Pump1
 Mixer100.Flow.Alarm.Pump1.InAlarm

op
 Inlet2_001.PV
 Pump2_001.CMD
 Pump2_001.PV.MSG
 Mixer100.Flow.Alarm.Pump2
 Mixer100.Flow.Alarm.Pump2.InAlarm

C
ot
17. Save the watch list.
Now, you will create a condition that will trigger an alarm.
N

18. When Inlet1_001.PV is closed, set Pump1_001.CMD to True to trigger an alarm.

o
D

Application Server 2017

10-44 Module 10 – Introduction to QuickScript.NET

19. Set Pump1_001.CMD to False to reset it.

y
20. Repeat the steps for Inlet2_001.PV.

op
C
ot
N
o
D

Wonderware Training
 y
op
C
Module 11 – Galaxy Backup and Restore
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

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

op
C
ot
N
o

Galaxy Database Manager

D

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

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.

y
Backup

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

C
ot
N

A warning appears.
o
D

Wonderware Training
 Section 1 – Galaxy Backup and Restore 11-5

Acknowledge the warning and name the .cab file to be created.

y
op
Click Save.
C
The Galaxy Database Manager progress appears.
ot
N
o

When the backup is complete, click Close.

D

Application Server 2017

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

y
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

op
rolled back.
Select the existing Galaxy, and then on the Action menu, click Restore.

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

11-8 Module 11 – Galaxy Backup and Restore

y
op
C
ot
N
o
D

Wonderware Training