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

Training Manual
Revision B
April 2009
Part Number 11-GT-10000

System Platform - Part 1

Wonderware Application Server 3.1 and Device Integration Products
INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

© 2009 by Invensys Systems, Inc. All rights reserved. No part of this document may be reproduced, stored in
or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording or otherwise), or for any purpose, without the express written permission of Invensys
Systems, Inc. Except where noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places and events depicted herein are fictitious and no association with any real
company, organization, product, domain name, e-mail address, logo, person, place or event is intended or
should be inferred.

Invensys and the author(s) assume no responsibility for errors or omissions and no liability is assumed for
damages resulting from the use of the information contained herein. Use of the Invensys software described
in this document is subject to the terms of the applicable Invensys Systems, Inc. / Wonderware license.
These terms include provisions that limit your rights such as use restrictions, disclaimers of warranties and
limitations of Wonderware / Invensys liability. By installing or using the Invensys software, you agree to
accept all of the terms of the applicable Invensys Systems, Inc. / Wonderware license. A copy of the
applicable license will be displayed upon initial installation of the software. If a copy of the license is not
displayed or you require an additional copy of the license, you may obtain one from Invensys' Wonderware
business unit by calling 1.949.727.3200 or by sending an e-mail to [email protected].

Invensys, Wonderware, ArchestrA, Factelligence, IntelaTrac, InBatch, InControl, IndustrialSQL Server,

InSQL, InTouch, InTrack, QI Analyst, SCADAlarm, SuiteLink, SuiteVoyager, WindowMaker, WindowViewer
are trademarks and registered trademarks of Invensys plc, its subsidiaries and affiliated companies. All other
brands and product names may be the trademarks or service marks of their respective owners.
 Table of Contents 3

Table of Contents
Module 1 Introduction .................................................................................1-1
Section 1 – Course Introduction......................................................................... 1-3
Section 2 – Wonderware System Platform ...................................................... 1-17
Lab 1 – Creating a Galaxy......................................................................... 1-39
Section 3 – The ArchestrA IDE ........................................................................ 1-45
Section 4 – Automation Objects....................................................................... 1-67
Section 5 – System Requirements, Licensing and Support............................. 1-79
Section 6 – Application Planning ..................................................................... 1-89
Lab 2 – Identifying the Mixer ..................................................................... 1-95

Module 2 Application Infrastructure ..........................................................2-1

Section 1 – The Plant Model.............................................................................. 2-3
Lab 3 – Creating the Plant Model ................................................................ 2-5
Section 2 – The Deployment Model................................................................. 2-13
Lab 4 – Creating the Deployment Model ................................................... 2-17
Section 3 – The Runtime Environment ............................................................ 2-27
Lab 5 – Using Object Viewer ..................................................................... 2-31
Section 4 – Connecting to the Field ................................................................. 2-41
Lab 6 – Connecting to the Field ................................................................ 2-51

Module 3 Application Objects ....................................................................3-1

Section 1 – Templates and Instances................................................................ 3-3
Section 2 – The $UserDefined Object ............................................................... 3-9
Lab 7 – Modeling the Heat Exchanger ...................................................... 3-11
Section 3 – Change Control and Propagation ................................................. 3-25
Lab 8 – Configuring Change Control and Propagation ............................. 3-27
Section 4 – The $AnalogDevice Object ........................................................... 3-35
Lab 9 – Modeling a Meter.......................................................................... 3-37
Section 5 – The $DiscreteDevice Object ......................................................... 3-41
Lab 10 – Modeling a Valve, Pump, and Motor .......................................... 3-45
Section 6 – Containment.................................................................................. 3-61
Lab 11 – Creating the Mixer ...................................................................... 3-67

Module 4 Extending the Objects ................................................................4-1

Section 1 – UDAs............................................................................................... 4-3
Section 2 – Extensions ...................................................................................... 4-7
Lab 12 – Configuring the Motor Speed ..................................................... 4-11
Section 3 – Introduction to QuickScript .NET................................................... 4-21
Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient ......................... 4-43
Lab 14 – Configuring Automatic Reference .............................................. 4-51

Module 5 Alarms and History .....................................................................5-1

Section 1 – Alarms............................................................................................. 5-3
Lab 15 – Configuring Alarms ..................................................................... 5-13
Section 2 – Historization .................................................................................. 5-31
Lab 16 – Configuring History ..................................................................... 5-37

Module 6 Security ........................................................................................6-1

Section 1 – Security Overview ........................................................................... 6-3
Lab 17 – Security ...................................................................................... 6-13

System Platform - Part 1

4 System Platform - Part 1

Module 7 Galaxy Maintenance ................................................................... 7-1

Section 1 – Exporting and Importing Objects ..................................................... 7-3
Section 2 – Configuring Instances Through a .CSV File .................................. 7-13
Section 3 – System Management Console (SMC) ........................................... 7-21
Section 4 – Network Account Utility ................................................................. 7-35

Module 8 Device Integration Products...................................................... 8-1

Section 1 – Wonderware I/O Servers ................................................................. 8-3
Section 2 – Wonderware Data Access Servers ................................................. 8-9
Section 3 – Device Integration Objects ............................................................ 8-13

Module 9 Multi-Node Applications ............................................................ 9-1

Section 1 – Application Redundancy.................................................................. 9-3
Lab 18 – Configuring Application Redundancy ......................................... 9-17
Section 2 – DI Redundancy.............................................................................. 9-31
Lab 19 – Configuring the Redundant DI Object ......................................... 9-35
Section 3 – Multi Node Application................................................................... 9-47
Lab 20 – Convert to Network Environment ............................................... 9-51

Appendix A Wonderware Application Server Glossary...............................A-1

Appendix B Plant Model Planning Diagrams................................................B-1

Wonderware Training
 Module 1

Introduction
Section 1 – Course Introduction 1-3
Section 2 – Wonderware System Platform 1-17
Lab 1 – Creating a Galaxy 1-39
Section 3 – The ArchestrA IDE 1-45
Section 4 – Automation Objects 1-67
Section 5 – System Requirements, Licensing and Support 1-79
Section 6 – Application Planning 1-89
Lab 2 – Identifying the Mixer 1-95
1-2 Module 1 – Introduction

Module Objective
z Introduce the Wonderware System Platform and its architecture, environment, and
requirements for installation and licensing.

Wonderware Training
 Section 1 – Course Introduction 1-3

Section 1 – Course Introduction

Section Objective
This section identifies the objectives and agenda for the System Platform - Part 1 as well as the
key basics of Wonderware Application Server.

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

Agenda

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

Module 2 – Application Infrastructure

Section 1 – The Plant Model

System Platform - Part 1

1-4 Module 1 – Introduction

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

Module 3 – Application Objects

Section 1 – Templates and Instances
This section introduces you to the concept of templates and explain how to derive a template.
Section 2 – The $UserDefined Object
This section introduces you to the $UserDefined object and its functionality.
Lab 7 – Modeling the Heat Exchanger
Section 3 – Change Control and Propagation
This section presents the concept of attribute locking and provides an illustrations on how
locking attributes can propagate to previously derived instances.
Lab 8 – Configuring Change Control and Propagation
Section 4 – The $AnalogDevice Object
This section introduces you to the concept of the $AnalogDevice object and its functionality.
Lab 9 – Modeling a Meter
Section 5 – The $DiscreteDevice Object
This section introduces you to the concept of the $DiscreteDevice object and its functionality.
Lab 10 – Modeling a Valve, Pump, and Motor
Section 6 – Containment
This section illustrates the concept of containment and how it works with Application Objects
and Templates.
Lab 11 – Creating the Mixer

Module 4 – Extending the Objects

Section 1 – UDAs
This section introduces and explains UDAs and how they are configured and used.

Wonderware Training
 Section 1 – Course Introduction 1-5

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

Module 5 – Alarms and History

Section 1 – Alarms
This section provides familiarization of the concept of alarms and events and how ArchestrA
handles them.
Lab 15 – Configuring Alarms
Section 2 – Historization
This section provides familiarization with the background concept of historization and the
details of historizable configuration.
Lab 16 – Configuring History

Module 6 – Security
Section 1 – Security Overview
This section provides an understanding of Security as it relates to Application Server.
Lab 17 – Security

Module 7 – Galaxy Maintenance

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

Module 8 – Device Integration Products

System Platform - Part 1

1-6 Module 1 – Introduction

Section 1 – Wonderware I/O Servers

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

Module 9 – Multi-Node Applications

Section 1 – Application Redundancy
This section provides an understanding of the concept of redundancy, how it can be
configured and key points to more effectively implement this feature. It also provides an
understanding of the concept and functionality of Redundant DI Objects
Lab 18 – Configuring Application Redundancy
Section 2 – DI Redundancy
This section provides an understanding of the concept of redundancy, how it can be
configured and key points to more effectively implement this feature. It also provides an
understanding of the concept and functionality of Redundant DI Objects
Lab 19 – Configuring the Redundant DI Object
Section 3 – Multi Node Application
This section provides an understanding of how to migrate from a standalone configuration to a
network configuration. At the conclusion of this section you will have an understanding of the
steps necessary to migrate to a network environment.
Lab 20 – Convert to Network Environment

Wonderware Training
 Section 1 – Course Introduction 1-7

Wonderware software solutions

Wonderware is the leading supplier of real-time operations management industrial software
solutions for Manufacturing Execution Systems (MES), Performance Management, Enterprise
Manufacturing Intelligence (EMI), and integration with asset management, Supervisory HMI,
GeoSCADA, Production Management, supply and demand chain, and Enterprise Resource
Planning (ERP) applications.
Wonderware delivers significant cost reductions associated with designing, building, deploying
and maintaining secure and standardized applications for manufacturing and industrial operations.
Wonderware software solutions enable companies to synchronize their production operations with
business objectives, obtaining the speed and flexibility to attain sustained profitability.
Over one-third of the world's plants and facilities run Wonderware software solutions in dozens of
industries worldwide, such as:
z Automotive
z Chemical & Pharmaceutical
z CPG (Food & Beverage)
z Discrete Manufacturing
z Electrical Power
z Facilities Management
z Mining and Metals
z Oil and Gas
z Process Manufacturing
z Water and Wastewater
Wonderware software solutions deliver manufacturing and operational performance improvements
that help reduce the amount of project-specific work required to develop information and
automation applications that are integrated across entire operational enterprises. They can be
implemented in the context of existing systems, at a company’s own pace and to the extent that
they choose.

System Platform - Part 1

1-8 Module 1 – Introduction

These solutions leverage a powerful, layered software architecture that enables a variety of
features and capabilities, such as visualization, optimization and control of plant floor data
collection, and data storage and analysis.

Wonderware offers the following software solutions:

z Manufacturing Execution Systems – Manufacturing Execution Systems (MES)
solutions feature a complete set of functional capabilities for consistent and effective
execution of operational activities. Leveraging the ArchestrA software architecture (see
page 1-10), Wonderware MES solutions are completely scalable and configurable. This
enables a unique, incremental approach to operational improvements where low-risk
deployment of increased application functionality can be realized one step at a time.
Wonderware MES solutions help to substantially reduce lead time and manufacturing
costs, increase production throughput and product quality, and reduce efforts involved in
compliance and governance.
z Enterprise Manufacturing Intelligence – Enterprise Manufacturing Intelligence (EMI)
software solutions empower companies to analyze their overall operational performance
using simple yet powerful data analysis and reporting tools. Production, costs, process
capability, equipment downtime, and quality and variance data can be collected,
aggregated, and displayed using Wonderware EMI software solutions. A powerful yet
secure Web interface helps deliver this information to the full range of plant workers –
tailored to their specific information requirements.
z HMI/SCADA – HMI/SCADA solutions often impose complex demands on software
architectures. Wonderware InTouch HMI visualization software, coupled with the award-
winning ArchestrA technology-based Wonderware System Platform is uniquely positioned
to meet these challenges. The HMI/SCADA software solutions are easy to use, implement
and configure, and offer simplified maintenance, high security and availability, and virtually
unlimited scalability.
z Data Historian – Wonderware Historian software leverages the state-of-the-art
Wonderware System Platform, industry leading historian technology, Web-based reporting
capabilities, and renowned open data source connectivity from Wonderware. The resulting
historian solution is unlike any other data archiving and reporting solution found in the
market today. With blazing speed, broad scalability, highly efficient data storage and

Wonderware Training
 Section 1 – Course Introduction 1-9

retrieval, high availability and simple one-click historization setup, the Wonderware
Historian software has an industry reputation for low total cost of ownership.
Preconfigured Web-based reports and data analysis capabilities drive immediate value
from data captured by the Wonderware Historian.
z Batch Management – Wonderware batch management solutions perform repeatable and
consistent execution of batching processes across all hybrid industries, whether it is
electronic batch records (EBR) systems in regulated industries, Paper-On-Glass
capabilities in paperless production environments, or automated recipe management for
supervisory systems. From simple batch processes, where only the formula changes for
different products, to the most complex batch processes requiring dynamic allocation of
shared equipment, Wonderware has a solution. Each of these solutions ensures reduced
lifecycle costs and investment protection by leveraging the ArchestrA architecture.
z Product Quality Management and SPC – Delivering products with high quality – defined
as meeting specifications at the lowest possible cost – is a top priority for manufacturers
and industrial operations, and Wonderware software applications meet these quality
needs. InTouch HMI offers real-time data monitoring and alarming; Wonderware Historian
stores voluminous process data for quality analysis; Wonderware QI Analyst software
provides enterprise-wide SPC; Wonderware ActiveFactory software trends data;
Operations & Performance software provides spec management, genealogy, BOM
enforcement, OEE and Downtime monitoring; the Wonderware System Platform monitors
data levels, and application templates can help deliver nearly any quality capability;
InBatch software collects information on batch quality and recipe settings; and the list
goes on.
z Mobile Solutions – Wonderware mobile solutions feature the industry's leading Mobile
Workforce & Decision Support System. Wonderware IntelaTrac enables the delivery of
Best Practices to field workers improving Asset Management for the leading refiners,
chemical manufacturers, and power generators globally.
For more information on Wonderware software solutions and products, visit the Wonderware Web
site at http://www.wonderware.com.

System Platform - Part 1

1-10 Module 1 – Introduction

ArchestrA technology
ArchestrA technology, or architecture, helps reduce application engineering effort and deployment,
increase efficiency, provide optimization and standardization, and enable integration of distributed
automation systems and applications from virtually any vendor. Geographically dispersed
applications (from a few hundred to one million I/O, and from a single node to hundreds of
stations) can be rapidly and securely implemented.
The ArchestrA architecture leverages advanced software technologies to fill the gap between ERP
systems and control systems. This architecture provides the following:
z Framework which supports common services and a core set of system objects
z Domain Objects which are industry-specific objects
z Object Development Toolkit which enables third parties to create new domain objects
customized for specific needs
The supervisory control and manufacturing information environment is served by a variety of
systems, including (HMI), Distributed Control Systems (DCS), Supervisory Control and Data
Acquisition systems (SCADA), Process Information Management systems (PIM), Manufacturing
Execution Systems (MES), batch and recipe management systems, and advanced control/
simulation systems. The ArchestrA Framework supports core services that are required by most of
these different types of supervisory control and manufacturing information systems.
These core services include the following:
z Integrated Development Environment (IDE)
z Version management
z License management and centralized deployment
z System diagnostics and system administration
z Internationalization
z Data visualization and monitoring
z Event-based processing, scripting, and calculation capabilities
z Alarm and event management, historization and security
z Data acquisition and field device integration
z Inter-object communications and name service
z Reporting and ad-hoc query capability
z Support for industry standards such as OPC and SQL
The ArchestrA architecture consists of the following:
z Configuration and Deployment Related Components that are required for centralized
deployment of the runtime components. These components are installed just like any
other Windows application and include the following:
„ Centralized object repository (called Galaxy Repository)
„ Integrated Development Environment (IDE)
„ Object deployment services (called Bootstrap)
z Runtime Components that are centrally deployed and administered. These components
include the following:
„ PCs with core infrastructure (called Platforms)
„ Key software applications (Engines)
„ Objects (Framework Objects) that expose framework related functionality

Wonderware Training
 Section 1 – Course Introduction 1-11

Wonderware individual software products

Wonderware software solutions offer robust, best-of-breed software components that empower
customers to effectively develop and manage their automation and information applications in
continuous, discrete, process, hybrid, and batch manufacturing environments. All the latest
Wonderware software offerings leverage the latest ArchestrA technology and offer increased
functionality and flexibility as well as extensive connectivity.

Wonderware System Platform

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

Wonderware InTouch HMI

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

Wonderware HMI Reports

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

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

Wonderware ActiveFactory
The Wonderware ActiveFactory software provides data-trend analysis, sophisticated numerical-
data analysis using Microsoft Excel, comprehensive data reporting using Microsoft Word, and the
capability to publish real-time and historical plant information to the Web or company intranet site
using Wonderware Information Server. Plant knowledge workers using ActiveFactory information
can quickly troubleshoot problems, study potential process inefficiencies, and eliminate the time-
consuming process of locating the data.

System Platform - Part 1

1-12 Module 1 – Introduction

Wonderware Information Server

The Wonderware Information Server offers an easy solution for aggregating and presenting plant
production and performance data over the Web or company intranet. Using Wonderware
Information Server, large amounts of process data can be aggregated into highly informative
production reports tailored to the information needs of plant personnel. Content from the
Wonderware Information Server can be incorporated into other Web portals, helping to make
existing corporate IT portals more informative and valuable.

Wonderware Operations Software

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

Wonderware Performance Software

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

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

Wonderware InBatch Software

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

Wonderware Equipment Operations Module

Wonderware Equipment Operations Module helps manufacturers capture complete “as-built”
records for rapid response to unforeseen production events such as product recalls. Leveraging
the ISA-95 standard, it enables consistent execution of unit/line operations, improved reliability,
and repeatability of equipment setup.

Wonderware Training
 Section 1 – Course Introduction 1-13

Wonderware Manufacturing Execution Module

Wonderware Manufacturing Execution Module empowers Wonderware customers to define logical
manufacturing models in terms of routes, operations, resources, and bills of materials – as well as
their relationship. It enables the operational execution of production plans with accurate tracking
and control of work-in-process (WIP) information related to inventories, resource utilization, and
conformance to specifications.

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

Wonderware Toolkits
Wonderware Toolkits provide powerful extensibility to InTouch HMI and System Platform
applications by enabling developers to extend the capabilities of Wonderware products to meet
specific system integration needs. The Toolkits promote adherence to industry standards, provide
additional customization and intellectual property protection, and enhance the ability to interface
Wonderware products with other software and hardware.
Wonderware offers the following Toolkits:
Toolkit Enables developers to:
DAServer Toolkit Build custom device integration servers more easily
ArchestrA Object Toolkit Extend the ArchestrA architecture with objects that provide specific application or
device integration functionality
Historian Toolkit Create high-value industrial applications that integrate with data sources from the
System Platform and other data sources
Alarm Toolkit Produce custom distributed alarm providers and consumers
Wizard Toolkit Produce their own Wizards for inclusion in InTouch HMI
Script Toolkit Develop custom InTouch scripts
GRAccess Toolkit Create programmatic access to and interaction with System Platform Galaxy
configuration data
MXAccess Toolkit Create programmatic access to runtime data in a System Platform Galaxy

Wonderware Device Integration Servers

Device Integration Objects (DI Objects) within the Wonderware System Platform provide seamless
connectivity to any data source, and the DAServer Toolkit allows developers to create custom
connectivity servers. In collaboration with more than 100 third-party interface developers,
Wonderware provides the largest selection of connectivity options to hundreds of control systems
and other hardware devices. Wonderware has also fully embraced the openness of OPC
technology, exposing data via OPC from Wonderware products as an OPC Client and also
providing the means to connect to any third party OPC Server.

System Platform - Part 1

1-14 Module 1 – Introduction

Wonderware Enterprise Integration Application

Wonderware offers powerful capabilities to complete the manufacturing supply chain by linking the
manufacturing system to business applications like ERP, PLM, SCM, and LIMS systems.
Wonderware Enterprise Integration Application provides a scalable and configurable solution
designed to accommodate even the most complex requirements for tightly aligning business and
manufacturing systems.

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

Wonderware System Platform Framework

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

Wonderware Training
 Section 1 – Course Introduction 1-15

services (called Bootstrap). These components are installed just like any other Windows®
application. They are required for centralized deployment of the runtime components.
z Runtime Components: which include PCs with core infrastructure (called Platforms), key
software applications (Engines) and objects (Framework Objects) that expose framework
related functionality. These components are centrally deployed and administered.

System Platform - Part 1

1-16 Module 1 – Introduction

– Intentionally left blank –

Wonderware Training
 Section 2 – Wonderware System Platform 1-17

Section 2 – Wonderware System Platform

Section Objectives
z Introduce the concept of ArchestrA and how it relates to the manufacturing environment
z Describe the benefits of migrating to an ArchestrA architectural environment
z Clarify how Object Oriented tag-based products relates to SCADA
z Explain the difference between Object Oriented development process and Tag Based
development process
z Explain what a Galaxy is and how it relates to the Galaxy Database and the Galaxy
Repository
z Demonstrate how a Galaxy is created

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

System Platform
The Wonderware System Platform provides a single platform for all the SCADA, Supervisory HMI,
and Production and Performance Management needs of industrial automation and information
personnel. It provides a common and strategic industrial application services platform on top of
virtually any existing system, and is built upon the industry-standards based, ArchestrA real-time
SOA technology.
The Wonderware System Platform is designed to make it easier for manufacturers to adjust to the
ever-changing needs of customers and the overall market. Its diverse functionality extends
Wonderware customers’ software investments and encourages flexibility in application
development.
It supports consistent and reliable operations across industrial operations and manufacturing
facilities as well as promotes sustainable production and operational performance improvements.
The Wonderware System Platform contains an integral core set of capabilities and services to
support sustainable production and operations performance improvement via a comprehensive
set of six capability areas:
z Industrial domain services
z Software and device connectivity services
z Information and data management services
z Information-delivery and visualization services
z Application development services
z System management and extensibility services

System Platform - Part 1

1-18 Module 1 – Introduction

Industrial Domain Services

The Wonderware System Platform offers industrial domain services that are not provided by
commercial operating systems or generic IT products. It provides a powerful infrastructure that
enables Wonderware customers to leverage lower-cost commercial PC hardware and operating
systems in industrial applications.
Application functions are quickly customized. Whether you have no knowledge of computer
programming or consider yourself an expert software engineer, the System Platform can empower
you to conveniently interact with process systems from any remote location. The result is a
reduction of personnel costs and improved response times because the software continuously
monitors and deploys messages, 24/7.
Industrial Domain Services provide:
z Real-time, peer-to-peer communications and messaging, enabling instant responses
z High computing availability and redundancy for critical applications
z Centralized alarm- and event-monitoring for operational conditions
z Data-level security to protect plant equipment
z Audit logging and extended security protection for developers and system-maintenance
personnel
z Pager, mobile phone, PA system and e-mail alerts for unattended operational monitoring
z A single global Namespace to access data elements anywhere, without tag limitations
z Plant information and supervisory functions to script special behavior and responses
z Support for slow and/or intermittent data networks

Software and Device Connectivity Services

The Wonderware System Platform enables cost-effective communication to virtually any plant
information source. Unifying diverse systems can improve operations and information
management. Integrating business and manufacturing activities can also increase plant
profitability.
Software and Device Connectivity Services provide:
z Integration of manufacturing and business systems
z Easy importing and migration of legacy systems and external system configurations
z Conversion of non-structured devicecommunication models into structured systems to
increase the maintainability of applications and systems
z Connectors and communication servers for control devices, applications and systems
including:
„ Automation devices, control systems and HMIs
„ Historians and relational databases
„ Quality and maintenance systems
„ Enterprise resource management (ERP) and business systems
„ Manufacturing execution systems (MES)

Wonderware Training
 Section 2 – Wonderware System Platform 1-19

Information and Data Management Services

Furthermore, the Wonderware System Platform facilitates the management of all real-time and
historical information — including data transformation and storage. This information management
capability can increase a plant’s profitability because it enables immediate access to key
performance indicators (KPIs); SPC, downtime and OEE information; live data calculations; event
and alarm notifications; and historical data.
More effective information and content management can also improve production management
and enhance plant performance. For instance, the reliable information that the Wonderware
System Platform enables not only data visualization, but actionable control. The platform also
enhances batch management, real-time production monitoring and access to MES data.
Information and Data Management Services provide:
z Content management tools
z Streaming real-time data (available to all authorized users)
z A high-performance process historian and production database that offer:
„ A production history archive for a single production line, an entire facility or the
complete enterprise
„ Data compression, which reduces disk storage and makes more data available online
„ An historical archive that’s auto-configured, eliminating duplicate work
z Off-line and late data handling for:
„ Manual data
„ Labs and quality systems
„ Remote terminal unit (RTU) environments
z Correlation of events and alarms with production history
z Data transformation and normalization
z Data Buffering and Store & Forward features
z Simple and fast configuration with powerful process event monitoring

System Platform - Part 1

1-20 Module 1 – Introduction

Information-Delivery and Visualization Services

Delivering the right information, to the right user, at the right time, and in the form in which they
expect it is a key service provided by the Wonderware System Platform. Wonderware customers
can concurrently visualize manufacturing and business information, and dynamically implement
changes to reach their business objectives.
Quickly access real-time and historical information using the open and easy-to-use HMI solution
that seamlessly integrates with legacy and new plant systems. Proactively enhance your plants
profitability by taking action on information in real time, obtaining real-time and historical data from
beyond the boundaries of the secured process network. Create queries and run reports, even if
you have no SQL database knowledge. The Wonderware System Platform can even help you
achieve regulatory compliance with simple and accurate automated reports.

Capabilities
z Multiple client interfaces [i.e., Thick, Terminal Services Edition (TSE) or Web Client]
z Visualization and HMI
„ Expansive graphical user interface (GUI)
„ Access-level Windows authentication and data security, as well as enhanced
password encryption
„ Comprehensive alarm troubleshooting tools
z Information Analysis and Reporting
„ Integration with trending tools and Microsoft Office products
„ Production, SPC, downtime and batch analysis tools
z Automatic data retrieval calculations - reduction and aggregate methods
z Open SQL access, enabling simplified data queries with powerful retrieval modes
z Secure access across firewalls
z Multi-language client support

Wonderware Training
 Section 2 – Wonderware System Platform 1-21

Application Development Services

The Wonderware System Platform and its underlying ArchestrA technology provide easy and
intuitive development of modular industrial software solutions, which can be easily changed to
meet Wonderware customers¡¦ future needs. As a result, you can drive standards by developing
applications once and using them everywhere. The result is a decrease in the amount of time and
costs associated with creating, modifying, deploying, maintaining and standardizing software
applications.
Application Development Services provide:
z Flexible, comprehensive software development capabilities for HMI and/or MES
applications
z Advanced ArchestrA technology, which facilitates the assembly of applications that are
component-based and generated from standard templates
z SmartSymbol technology, enabling the creation of re-usable graphics
z Different development views, which show:
„ How the application is related to the facility or plant
„ How the application is distributed across the network
„ Parent-child relationships for templates and runtime components
z Multi-Developer Environment for concurrent development
z Modeling - Applications can be structured based on a plant model; are self-documenting;
and offer common security, validation and audit trails
z Unification with Microsoft products including:
„ Microsoft Windows operating systems
„ The Visual Studio development system
„ SQL Server, BizTalk server
„ SharePoint services
„ Microsoft Office
„ Internet Explorer internet browser

System Platform - Part 1

1-22 Module 1 – Introduction

System Management and Extensibility Services

Furthermore, the Wonderware System Platform facilitates the easy management, expansion and
modification of applications or the host computing architecture. These services provide a range of
architectural choices, both during the initial system design phase and throughout the lifetime of an
installed system.
Leverage the flexible and scalable ArchestrA software architecture for small and large systems —
systems that can be easily expanded to meet future requirements. Improve system
troubleshooting. Leverage Wonderware’s technological evolution and increased protection for
operating systems and databases. Decrease lifecycle costs for plant IT solutions. Change and
expand your system as a whole without disruption.
System Management and Extensibility Services provide:
z The ability to re-architect systems at any time to support different system topologies (i.e.,
Single Node, Client/Server, Peer-to-Peer or Web-centric
z Easy redistribution of server load
z Remote application installation and administration
z An online configuration database that centrally maintains software
z Remote change propagation
z Centralized computer diagnostics and distributed PC network management
In essence, the Wonderware System Platform facilitates consistent and reliable operations across
manufacturing and industrial operations to protect brand integrity. It empowers Wonderware
customers to extend their systems in virtually any direction to meet their current and future needs.

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

Wonderware Training
 Section 2 – Wonderware System Platform 1-23

The Need for ArchestrA

Quality, responsiveness, and cost efficiency have always been necessary for any plant or factory
that wishes to surpass the competition. Today, they are vital for any plant, factory, or enterprise to
survive.
The pace of change accelerates. Product cycles become shorter and more complex. New or
enhanced products must be commercialized at breakneck speed, or risk rapid failure. Such
offerings must also be quickly customizable for use in today’s global business spaces. Again, as
these markets grow ever more economically efficient, the choice for manufacturers is between
agility and finality.
That’s why today a variety of computer-based systems are used to operate plants as well as to
improve their efficiency. In most plants, multiple varieties of hardware and software systems
provide machine and process control, information management, and decision support. These
systems enable manufacturers to operate their businesses more effectively and add value to the
raw materials they process. Without these systems, many highly engineered consumer and
industrial products simply would not exist, because of the complexities involved in their
manufacture.
Unfortunately, even today, in most plants these systems operate independently. This hinders a
plant manager’s ability to synchronize and control production and business processes in a real-
time environment. In other words, the majority of manufacturers have not successfully integrated
the functionalities of automation/business/information systems into a single, unified infrastructure.
In the past, this has been an expensive and time-consuming process. Those that have
successfully integrated have done so at great cost in terms of money and resources. Moreover,
despite the huge investments made by companies in these systems over the years, managers still
find it difficult to quantify resulting tangible benefits.
The most compelling aspect of the problem now facing manufacturers is that the underlying
technology of these systems is rapidly becoming obsolete. As general technology lifecycles
shorten, manufacturers are pressed to procure and integrate new technologies with ever-
increasing speed — making the ultimate goal of productivity improvement even more difficult to
achieve.

System Platform - Part 1

1-24 Module 1 – Introduction

In most plants today, “islands of automation” within business and manufacturing systems hinder
the plant manager’s ability to synchronize business processes in real time.
Recognizing this challenge, Invensys has developed a solution, ArchestrA automation and
information architecture (ArchestrA).
A powerful new infrastructure for industrial applications, ArchestrA promises to provide an
information and control superstructure that will increase the productivity of a plant’s existing
systems, while enabling the plant to easily integrate important new technologies over the longer
term. Building on ArchestrA research and technology, the recently released I/A Series A2 system
(I/A Series A2) has taken the first major step toward reducing the risk of automation obsolescence
and protecting manufacturers’ investments far into the future.

Manufacturing Goals
For approximately a decade, manufacturers have been revising business practices, organization
charts, and systems infrastructures to become more market-driven and customer-centric. Their
overall objectives have been straightforward and consistent:
z Become more responsive to market shifts and the increased competition brought on by
globalization
z Develop greater agility and a more collaborative, data-driven environment•
z Synchronize the manufacturing process with planning and scheduling functions to
optimize enterprise performance
z Empower operators with critical information to foster improved plant performance
z Utilize existing assets more efficiently to increase production, without the need to expand
the plant or build new capacity
z Ensure the greatest possible return on assets, and improve profitability, in the face of
continuing manpower reductions
To achieve these goals, managers know they can no longer simply "invest in technology" and
expect improvements to come about automatically. In fact, millions of dollars have already been
invested with only marginal returns. However, management cannot afford to stand still, because

Wonderware Training
 Section 2 – Wonderware System Platform 1-25

there are significant rewards to be reaped by those who develop improved responsiveness,
greater agility, and a higher return on assets.
Compounding the problem, many of yesterday’s automation and information systems are
beginning to show their age, failing to offer the agility or rapid response that today’s producers
require. Acting as a massive anchor, they actually impede the organization’s forward progress as
they increasingly require greater amounts of maintenance and the corresponding expansion of
infrastructure support. But the original investment in these systems was so extensive — and so
visible to owners and investors — that it is understandably difficult to broach the subject of
"bulldozing" and starting over with the latest generation of technology. Further, it means not only
eliminating extensive hardware infrastructure, but also destroying an asset that is even more
valuable — the intellectual capital unique to the manufacturing mission.

Synchronization of Systems
Today’s collaborative manufacturing environment requires that manufacturers synchronize
automation systems with business/information systems to accomplish total supply chain
management.
To facilitate this collaborative environment, many manufacturers are working toward a rational,
cost-effective solution that does not require enormous investment and allows for the preservation
of as much existing infrastructure as possible. They are preserving, to the maximum extent
feasible, existing investments in hardware and software, as well as in intellectual properties
contained in application-specific software. They are working to synchronize the various
informational elements within the manufacturing domain, namely automation systems, business
systems, and information systems, thereby fulfilling these systems’ original promise of improved
manufacturing efficiency. They are identifying optimal long-term strategies based on total cost of
ownership.
The pace of change has increased to a point at which it is difficult for manufacturers to execute a
new strategy before market conditions change once again. Today’s manufacturer, however, must
have the ability to respond to challenges that are virtually unanticipated. Response times have
now become the cornerstones of manufacturing competitiveness, and will remain so for the
foreseeable future.
The challenge has been to develop an architectural infrastructure that optimizes quality, customer
satisfaction, and efficiency of operation, while facilitating quick response and easy reengineering.
And to identify and deploy a plant information superstructure that embraces existing systems while
providing expansion capabilities for the long term.
Such an architectural infrastructure is available through ArchestrA. This allows manufacturers to:
z Preserve a significant portion of their existing automation and information infrastructures
z Integrate and synchronize existing production systems and new applications
z Move ahead into the future, confident of shorter project execution times, reduced total cost
of ownership, and a proven, long-term strategy that will remain in a leadership position for
the life of the plant.

System Platform - Part 1

1-26 Module 1 – Introduction

ArchestrA Architecture
ArchestrA, developed by Invensys, is a software infrastructure designed to unify combinations of
Invensys, third-party, and customer internal applications, both current and emerging, into a
synchronized, plant-level application model, and to foster their ongoing adaptation and
improvement. It comprises a unique combination of new toolsets and new applications
infrastructure services, allowing the rapid generation of new applications, products, and services.
Because it enables easy upgrades via integration of existing systems with these new technologies,
it offers manufacturers the promise of extending the lifecycle of an entire plant’s information and
control system infrastructure.
ArchestrA facilitates the next logical extension of enabling software architecture designed to
accommodate emerging technologies and to ease the reuse of engineering from one project to
another. The objective of this unique technology is to dramatically reduce engineering and
maintenance time and expense when a manufacturer must modify or expand his company’s
process. Incorporating ArchestrA will considerably reduce the cost and time involved in executing
strategic change.

Wonderware Training
 Section 2 – Wonderware System Platform 1-27

ArchestrA enables manufacturers to synchronize the various informational elements within the
manufacturing domain and supply the information required by business systems in real time.
ArchestrA provides a number of key functions designed to free users from the complexities of
dealing with current underlying technologies. So users require only assembly skills, not
sophisticated programming knowledge, and are able to apply their time to functions in which they
have more expertise. By embedding common application services directly into a common
infrastructure, application engineers can design and reuse solutions that are instantly integrated.
The key elements of the software infrastructure are the following:
z Common design and development environment
z Deployment, scripting, and calculation services
z Alarm and event subsystems with reliable delivery
z Built-in distributed architecture services for scalability
z Integration with various types of field devices
z Inter-object communication and name service management
z Version management services
z Security model services
z Centralized license management and deployment services
z Centralized system diagnostics and administration
z Internationalization of objects and application services
z Graphical user interface (GUI) editing services

System Platform - Part 1

1-28 Module 1 – Introduction

Automation Information Pyramid

ArchestrA supports all layers of industry standard models. It is the basis for Supervisory,
Production and Plant Intelligence solutions. In addition, it extends functionality across the
enterprise enabling true manufacturing collaboration. The Automation Information Pyramid
illustrates these points. It displays the complete effectiveness of ArchestrA across all levels of the
manufacturing environment:
1. Plant Floor Connectivity
2. Supervisory
3. Production
4. Plant Intelligence
5. Manufacturing Collaboration
The following page illustrates these segments as they relate to the Automation Information
Pyramid.

Wonderware Training
Section 2 – Wonderware System Platform 1-29

Manufacturing
Collaboration

Plant
Intelligence

Production

Supervisory

Plant Floor
Connectivity

System Platform - Part 1

1-30 Module 1 – Introduction

Scalability
Wonderware Application Server provides a scalable and integrated architecture to meet the needs
of small, simple applications all the way up to highly challenging manufacturing information
management systems.
Wonderware Application Server resolves the problems associated with scaling automation
applications because there are no limitations on system size and performance issues are easily
addressed through the introduction of new nodes. New workstations and any data points defined
are automatically integrated into the initial application through the plant model. The common
distributed peer-to-peer Namespace means that all information is shared between the nodes
without the user having to perform any additional engineering or configuration.

Object Oriented vs. Tag Based Supervisory Control

There are several fundamental differences between Object-oriented and traditional Tag based HMI
and SCADA products. The following table illustrates the differences in how various processes are
managed in Object Oriented vs. Tag Based systems.

Process Object Oriented Tag Based

Structure Hierarchical Flat
Graphics Development Done Last Done Early
Background Process Developed in Objects Developed in Tags
Promotion of Standards Strictly Enforced Not Strictly Enforced
Global Application Change Progagated from Templates Changed in Tools like Excel
Data Represented By Physical Devices as Objects Data Types and communication
Bits as Tags

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

Wonderware Training
 Section 2 – Wonderware System Platform 1-31

Use of the word "Object-oriented" with SCADA

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

In order to fully realize the benefit of an Object-oriented architecture, a SCADA System today
needs to depict all of these things, along with the graphics as objects.

System Platform - Part 1

1-32 Module 1 – Introduction

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

Using object-oriented tools in manufacturing applications

Manufacturing applications typically have a lot of common components. These include common
types of:
z Plant devices and equipment
z Operating procedures
z Process measurements
z Calculations
z Graphics displays
This leads to a cookie cutter approach, where typically small software programs are developed as
objects/code modules that can be stamped out and joined together to form an application. Almost
all of the automation vendors have this capability today with their software. Where an object-
oriented SCADA System is different, is that after the cookies are stamped out, you can change the
stamp, and all of the cookies you already made are automatically changed.

Wonderware Training
 Section 2 – Wonderware System Platform 1-33

This is possible because when a SCADA package is truly object-oriented, it has the notion of a
parent-child relationship, where parent templates are developed and then "Child Objects" are
replicated or instantiated from the parent templates. Now all of the children are tied back to the
parent, so a change in the parent can be replicated to all of the children. This is an extremely
powerful development capability in that:
z Application creation is optimized by using parent Templates and automated child object
replication
z Project change orders are easily accommodated by making changes in the parent
template and having the child objects inherit the changes via change propagation
z Ongoing system changes and expansions are easier and more cost effective because of
automated object replication and change propagation

Traditional, Tag Based SCADA Development Process

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

System Platform - Part 1

1-34 Module 1 – Introduction

Object oriented Development Process- graphics are created last

Wonderware Application Server and the ArchestrA IDE have brought a new era to SCADA
Software development through the ability to create a complete plant device model. The developer
is abstracted from the complexities of the computing environment and allowed to concentrate on
"modeling" how the production facility is laid out and the different manufacturing cells and
processes that comprise plant-wide supervisory control. Once the plant model is captured, it is
easy to implement supervisory control functions. A small investment in creating Templates yields
big results in engineering productivity. The ten easy steps to creating a supervisory application
using the Application Server are:
1. A site survey is conducted to understand the layout of the manufacturing operation or process.
Piping and Instrument Diagrams (P&ID) can also be referenced to understand the specific
equipment in use.
2. A list is developed of similar pieces of equipment, like common types of motors, valves,
transmitters, control loops, drives, etc. Distinct areas of operation are also identified.
3. Templates are configured for each common device or component in the facility. For example,
there may be 100 transmitters of a particular type that can be modeled as a single device
template. This process sets up the standards for the supervisory application and for any
applications that are created in the future. These templates will be used to develop objects
which represent a specific device, such as a level transmitter LIC101. In addition, templates
contain all of the logic, input/outputs, scripting, history configuration, security and alarms and
events for the device.
4. Device templates can be contained within each other to build-up a more complicated device,
for example, a mixer may contain a level transmitter, pump, inlet / drain valves and agitator.
5. Device templates have attributes which represent real I/O available in the PLC or control
system. These attributes are then linked to the I/O through Device Integration Objects.
6. The application can then be assembled by using a simple drag and drop capability inside if the
ArchestrA IDE. As templates are dropped into their individual plant areas, an object instance is
created that is linked back to the template. This is the "Object-Oriented" nature of the
Application Server, which provides incredible power when it comes time to modify anything in
the system. The software does all the work as the user is simply configuring templates that
represent the equipment in the plant.
7. Objects are then assigned to security groups. This can be done on an individual basis or by
area of the plant. These security groups have common permissions. Roles are created to map
rights onto each security group. Users can be given one or more roles. This offers a great
amount of flexibility in changing user permissions and in managing the security model.
8. The model created in the ArchestrA IDE can now be deployed to the computers that will host
the application. Notice that absolutely no consideration needs to be given to how the
supervisory stations are going to be laid-out or which computer needs to have a specific part
of the system running on it. The Application Server is a fully distributed system, which can
reside on a single computer or on hundreds of computers. Standard system objects, such as
Platforms and Engines, represent specific computers that are used to host objects when they
are deployed.
9. Graphics are then configured using InTouch®, the world's most popular HMI software
package. This can also be done using the Smart-Symbol functionality contained in InTouch 9.0
SP 2 which allows a graphic element to be created and linked to a template in the ArchestrA
IDE. That way the display graphics are also object-oriented and tightly coupled to the plant
model.

Wonderware Training
 Section 2 – Wonderware System Platform 1-35

10. Once the application is developed, maintenance of the system is easy. Changes made to
Templates can be propagated to the "Child Objects" linked to the Templates. For example, if
the units associated with a level transmitter need to change from gallons to liters, this can be
done once in the template, and the changes can automatically propagate to all the operator
displays in the plant.

System Platform - Part 1

1-36 Module 1 – Introduction

What is a Galaxy?
It’s important to understand what a Galaxy is before one is created. A Galaxy is the entire
application, the complete ArchestrA system consisting of a single logical name space and a
collection of WinPlatforms, AppEngines and objects. One or more networked PC’s that constitute
an automation system. It defines the name space that all components and objects live in and
defines the common set of system level policies that all components and objects comply with.
A Galaxy Database is the relational database containing all persistent configuration information for
all objects in a Galaxy.
And a Galaxy Repository is the software sub-system consisting of one or more Galaxy Databases.

Creating a Galaxy
Each ArchestrA IDE session requires connection to a specified Galaxy. In other words, the
ArchestrA IDE cannot be started in a Galaxy-neutral state. When you attempt to start the
ArchestrA IDE, the Connect to Galaxy dialog box is displayed.

This dialog box is comprised of three groups of options:

z Galaxy Repository/Galaxy connect selections: This consists of the GR Node Name and
Galaxy Name boxes.
z Action buttons: Connect, New Galaxy, Delete Galaxy, About and Cancel.
z Licensing information
If the Galaxy Name box is empty, you have not yet created a Galaxy on the computer shown in the
GR Node Name box. Before you can start the ArchestrA IDE, you must either browse for a Galaxy
on another node or create a new Galaxy.

Wonderware Training
 Section 2 – Wonderware System Platform 1-37

All new Galaxies are created with no security. They also have the following characteristics: two
users (DefaultUser and Administrator, both with full access to everything), two security roles
(Default and Administrator, both with full privileges) and one security group (Default). When
creating a new Galaxy, you must select the appropriate Galaxy type:
Default Galaxy: Creates a Galaxy that includes all objects needed for a System Platform
application. It also creates a backup file (.cab) at the end of the process and makes it available
to this list.
Base_Application_Server.cab: Same as Default Galaxy, but uses the backup file (.cab) to
create the galaxy. It does not creates a backup at the end, making the process faster.
Base_InTouch.cab: Creates a Galaxy that includes only the object needed for tag-based
Managed InTouch applications.
Reactor_Demo_Application_Server.cab: Creates a Galaxy with the Reactor Demo based
on a System Platform application.
Reactor_Demo_InTouch.cab: Creates a Galaxy with the Reactor Demo based on a tag-
based Managed InTouch application.
If you previously created one Galaxy on the GR node shown, the Galaxy’s name is automatically
shown. Click Connect to start the ArchestrA IDE and to connect to that Galaxy. If you previously
created more than one Galaxy on the GR node shown, the most recently accessed Galaxy name
is shown. Choose the desired Galaxy from the Galaxy Name list and click Connect to start the
ArchestrA IDE and to connect to that Galaxy.

System Platform - Part 1

1-38 Module 1 – Introduction

– Intentionally left blank –

Wonderware Training
 Lab 1 – Creating a Galaxy 1-39

Lab 1 – Creating a Galaxy

Introduction
This lab illustrates the steps necessary to create a Galaxy and connect to it with the ArchestrA
IDE. Throughout this class you will use this Galaxy to develop a sample application.

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

System Platform - Part 1

1-40 Module 1 – Introduction

Summary Lab Instructions

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

Create and Connect to a new Galaxy (page 1-41)

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 1 – Creating a Galaxy 1-41

Detailed Lab Instructions

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

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

3. The New Galaxy dialog box is displayed.

System Platform - Part 1

1-42 Module 1 – Introduction

4. Enter TrainingGalaxy in the Galaxy name field.

5. Verify Base_Application_Server.cab is selected in the Galaxy Type field.

This must be the

node that contains
the Galaxy
Repository (the
name of the Host
computer).

6. Click the Create button to continue.

The Create Galaxy dialog box will display indicating the Galaxy creation progress.

When the galaxy creation process is complete the Close button will enable.

7. Click Close.

Wonderware Training
 Lab 1 – Creating a Galaxy 1-43

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

This closes the Connect To Galaxy dialog box and displays the ArchestrA IDE.

System Platform - Part 1

1-44 Module 1 – Introduction

– Intentionally left blank –

Wonderware Training
 Section 3 – The ArchestrA IDE 1-45

Section 3 – The ArchestrA IDE

Section Objectives
z Discuss ArchestrA IDE
z Introduce the Template Toolbox and Application Views
z Discuss the object Check-in/Check-out process.

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

The ArchestrA IDE User Interface

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

System Platform - Part 1

1-46 Module 1 – Introduction

Key Functions of the ArchestrA IDE

The Main Window is the user interface in which you can create your application and deploy it to
your enterprise. This main window provides the key platform where a wealth of functionality
capability can be accessed and configured. Some of these key functions include the following.
z Galaxy Configuration
„ Connect to an existing Galaxy on the network
„ Create a new Galaxy
„ Destroy a Galaxy
„ Import/Export Objects (aaPackage, .csv)
„ Import/Export script function libraries (.dll, .tlb, .olb, .wdf, .aaSLIB)
z Security Configuration
„ Configure User security
„ Configure Object security
z Object Configuration
„ Create new objects
„ Check out objects
„ Edit objects
„ Configure Historization through objects
„ Configure objects for Alarms and Events
„ Extending object functionality
„ Check in objects with comments
„ Deploy/undeploy objects
„ Propagate changes to runtime objects
„ View object’s configuration errors/warnings
„ Upload runtime changes to Galaxy database
z IDE Configuration
„ Set user preferences
„ Create a Tool Box
As the main aspects of the ArchestrA IDE Main View (for example, Menu options, Toolbars,
Template Toolbar and Application Views, etc.) are identified and discussed, they are elaborated
on in greater detail as to how these Key Functions can be used

Wonderware Training
 Section 3 – The ArchestrA IDE 1-47

The ArchestrA IDE User Interface

Main View

The Main Window of the ArchestrA IDE is composed of the following components:
z Title bar
z Menu bar
z Toolbar
z Template Toolbox
z Application Views
z Object Editor Area
z Operations View
z Status bar
When you first log in to the ArchestrA IDE, the Main Window displays the Template Toolbox and
Application Views docked on the left, the Toolbar docked at the top, and the Object Editor Client
Area on the right. Upon subsequent logins by the same user, the Main Window displays the
positions for these controls as they were at the end of the last log in session.
The Title Bar displays the name of the utility. The other elements of the Main Window are
described below.

System Platform - Part 1

1-48 Module 1 – Introduction

Menu Bar
The ArchestrA IDE Menu Bar is a dynamic element that includes the following menus:

Galaxy, Edit, View, Object, Window, and Help. Depending on what object or Main Window
element is in focus, what condition it is in, or whether certain functions are logically permitted,
some menu commands may be deactivated. The following is a description of menu commands.
Galaxy menu – Providing Galaxy or user-level global commands, the Galaxy menu includes the
following:

z New – For creating a new Instance, Derived Template, or Template Toolset.

z Open – For opening the editor of the object in focus. The editor appears in the Object
Editor Client Area of the Main Window.
z Open Read-Only – For opening the editor of the object in focus, but only in read-only
mode. There are several conditions that can place this restriction on opening an object’s
editor. One example would be when the object is checked out to someone else.
Additionally, if you do not have configuration permissions for the object in question.
z Close – For terminating the object edit session in focus. This command is available only if
the editor for one or more objects is open. If the object has been modified, you are
prompted to save the new data to the Galaxy Repository. The same validation scenario
applies as described in the Save menu command.
z Import – For importing Automation Objects, Script Function Library, and Galaxy Loads.
z Export – For exporting Automation Objects, All Automation Objects, Script Function
Libraries, and a Galaxy Dump.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-49

z Save – For saving the currently-opened object’s configuration, which is persisted to the
Galaxy Repository. This command is available only if the editor for at least one object is
open and configuration data has been modified in at least one of them. Validation occurs
on the editor level; if errors or warnings are identified during validation, they are displayed
in a message box and the user is given the choice to continue saving or cancel the save.
z Save All – For saving ALL the currently-opened object’s configuration, which is persisted
to the Galaxy Repository. This command is available only if the editor for at least one
object is open and configuration data has been modified in at least one of them. Validation
occurs on the editor level; if errors or warnings are identified during validation, they are
displayed in a message box and the user is given the choice to continue saving or cancel
the save.
z Configure – For configuring Security, the Time Master, or to Customize Toolsets.
z Galaxy Status – For viewing information relating to the Galaxy such as the total number
of instances, total number of templates and other related Galaxy information.
z Properties – For viewing the properties of the object in focus.
z Change Galaxy – For selecting a Galaxy repository that is different from the one to which
you are currently connected, this command opens the Select Galaxy dialog box.
z Change User – For changing the logged in user of this ArchestrA IDE, this command
opens the ArchestrA IDE Login dialog box.

Edit menu – providing edit capabilities, the Edit menu includes the following commands:

z Rename – For renaming the object in focus.

z Rename Contained Name – For renaming the contained name of the object in focus.
z Delete – For deleting the object in focus.
z Find – For locating specific items of information based on a variety of configurable search
criteria.
z User Information – For viewing the Prompts, Initial Scan State, Scan State Defaults, and
User Defaults.

System Platform - Part 1

1-50 Module 1 – Introduction

View menu – similar to a standard Microsoft View menu, this menu provides commands for
controlling the Main Window display. On your initial ArchestrA IDE login, all four Main Window
components listed below are visible (checked) and the client language is set to the one chosen
during installation. Subsequent logins by the same user implement the previously saved ArchestrA
IDE settings. This menu includes the following commands:

z Model – For bringing focus to the Model view of the Main Window.
z Deployment – For bringing focus to the Deployment view of the Main Window.
z Derivation – For bringing focus to the Derivation view of the Main Window.
z Template Toolbox – For bringing focus to the Template Toolbox of the Main Window.
z Graphic Toolbox – For bringing focus to the Graphic Toolbox of the Main Window.
z Operations – For displaying the progress and results of a set of Galaxy database
operations that can be done at the same time as other application-building operations.
z Synchronize Views – For specifying that a selected object stay selected as you move
through the views.
z Reset Layout – For resetting everything back to its original default locations.
z Toolbars – For toggling on/off the Toolbar of the Main Window.
z Status Bar – For toggling on/off the Status Bar of the Main Window.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-51

Objects menu – the Objects menu includes the following commands:

z Check-Out – For checking out an object from the Galaxy Repository so that you can
maintain sole authority to configure that object. Nobody else connected to the Galaxy can
affect the configuration of the object until you have checked it back in to the Galaxy.
z Check-In – For checking in to the Galaxy Repository an object which was previously
checked out. This command opens the Check-In Object dialog box.
z Undo Check-Out – For reversing a previous check-out without affecting the configuration
of the object in question. The result of this command is the object can be checked out by
anyone connected to the Galaxy.
z Override Check Out – Use this command to disable the checked out flag on the selected
object. This command typically requires special security permissions and should be used
only in those circumstances in which it is certain that object configuration is not being done
by the user who originally checked out the object. If the object’s editor is currently open,
the override function fails.
z Validate – For checking allowable attribute value ranges, compiling its scripts, updating
and binding its references, validating its extensions, updating its status, and validating
other configuration parameters that may be unique to the object.

Note: See “Validating Objects” on page 1-53 for additional information regarding this feature.

z View in Object Viewer – For allowing the evaluation of attributes and conditions when the
objects are deployed. It provides a visual display of the actions being executed.
z Deploy – For deploying the object or objects currently in focus to the nodes their
configurations denote, this command opens the Deploy Object dialog box.
z Undeploy – For undeploying the object or objects currently in focus from the nodes that
currently host them, this command opens the Undeploy Object dialog box.
z Assign To – For assigning objects to a different platform.
z Unassign – For unassigning objects to a different platform.
z Set As Default – For setting a System Object, such as WinPlatform or AppEngine, as the
default for assigning appropriate objects.

System Platform - Part 1

1-52 Module 1 – Introduction

z Upload Runtime Changes – For uploading a deployed object’s configuration to the

Galaxy Repository. This function is useful when changes to certain attributes
(Writeable_UC, Writeable_UC_Lockable, Writeable_USC, Writeable_USC_Lockable) are
made in the configuration environment, but at a later time, the runtime object’s
configuration is determined to be preferred. Select the desired object and click Upload.
The runtime configuration overwrites the configuration environment data in the Galaxy
Repository.
Window menu – For manipulating the Object Editor Client Area of the Main Window, this menu is
available if at least one object’s editor is open. This menu includes the following commands:

z Cascade – Standard Windows command for cascading (layering) multiple object editors.
z Tile Horizontally – Standard Windows command for displaying the editors horizontally.
z Tile Vertically – Standard Windows command for displaying the editors vertically.
z Close All – For closing all open object editors. If any data was changed on any editor, you
are prompted to save those changes individually for each editor.
z Windows – For selecting through a separate dialog box which editors to activate or how
they are to be displayed.
Help menu – similar to a standard MS Help menu, the ArchestrA IDE Help menu includes the
following commands:

z Help Topics – Standard Help command, used for opening the ArchestrA IDE’s HTML
Help documentation system.
z Object Help – Provides information about the object in focus.
z About ArchestrA IDE – Opens the About ArchestrA IDE dialog box which provides
software version and copyright information.

Operations Pane
The Operations pane displays the progress and results of a set of Galaxy database operations
that can be done at the same time as other application-building operations. Currently, validating
the configuration of objects is the only operation that uses this pane.

Important! Validation can be done on both templates and instances, but only on those that are
checked in.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-53

Validating an object checks its configuration; that includes checking allowable attribute value
ranges, compiling its scripts, updating and binding its references, validating its extensions,
updating its status, and validating other configuration parameters that may be unique to the object.

Note: A primary use of validation is to validate objects that were configured prior to the importing
of relevant script libraries. Such objects would have a status of Bad. Validating these Bad objects
corrects references to the script libraries and updates their status to Good.

To display the Operations pane, either

z Right-click on an object (multi-select is allowed) and click Validate on the shortcut menu.
z Click Operations on the View menu.
The following pane is then displayed in the Main Window.

To hide the Operations pane, click the X close button.

During the validation of an object, its icon and name are displayed along with the status of the
operation. The status of the object (Status column) is dynamically represented by an icon: no icon
indicates Good status, an Error or Warning icon indicates either of those states. When validation is
complete, the Command Result column displays either a "Succeeded" or "Failed" message, which
may contain additional information about the validation results.

Note: You can validate all objects in the Galaxy by running the Validate operation on the Galaxy
object. In that case, Command Result messages are displayed after all objects in the Galaxy are
validated.

If multiple objects are validated, the list of objects is sorted by object name. You can click a column
heading to re-sort according to alphanumeric or icon groupings. Use the check mark column
heading to sort for objects that are checked out and, therefore, cannot be validated. The object’s
icon indicates checked out status with a check mark.
You can perform any operation on an object listed in the Operations pane that is possible in the
Template Toolbox or Application Views. Right-click on the object and select commands from the
shortcut menu. You can open an object's editor from the Operations pane by double-clicking it. To
view an object’s properties (particularly, the Errors/Warnings page of the Properties dialog box),
double-click its status icon. You can also copy a line of text in the Operations pane list by clicking
Copy from the shortcut menu (or Ctrl+C). The Operations pane, like the Template Toolbox and
Applications Views, is also updated as the status and conditions of objects in the Galaxy change.

Validating Objects
Each object in a Galaxy has a set of possible configurations that authorizes its proper use in an
application. That set of configuration possibilities is validated by the object either while you are
configuring it or when you save that configuration to the Galaxy database.

System Platform - Part 1

1-54 Module 1 – Introduction

Validation of an object’s configuration includes checking allowable attribute value ranges,

compiling its scripts, updating and binding its references, validating its extensions, updating its
status, and validating other configuration parameters that may be unique to the object.
Typically, each option on an object’s editor that requires a string or numeric input has an allowable
range of inputs. If you type an input outside the allowable range and then attempt to change editor
page, close the editor or save the object’s configuration, a message is displayed about the input
error indicating the allowable range.
Some configuration settings are dependent on associations with external components, such as
script function libraries and relative references to other objects’ attributes. The status of these
external components can change, perhaps rendering some capability of the object inoperative.
For instance, an object may refer to a value of an attribute of another object, which is subsequently
deleted. That scenario would break the configuration of the remaining object. Objects may be
configured prior to the importing of associated script function libraries. In each case, the object
would have a status of Bad. You can verify that an object’s configuration is valid and reset its
status to Good by manually validating it with the Validate command on the Object menu.

Manual Validation
To manually validate one or more objects, select the object(s) and click Validate on the shortcut
menu (by right-clicking the object) or on the Object menu. You can select objects from the
Template Toolbox, the Application Views or the Find dialog box.

Important! Manual validation can be done on both templates and instances, but only on those that
are checked in.

Using the Find dialog together with the Validate command is an especially useful tactic. For
instance, you can find objects in Error state, select them all, right-click on one of them, and click
Validate on the shortcut menu.
The Validate command opens the Operations pane in the ArchestrA IDE. See section on
Operations Pane for more information.
Only one validation operation can be run at a time. But you can multi-select more than one object
for each validation operation. The set of objects are validated serially.

Note: Validation operations cannot be canceled.

Continue using the ArchestrA IDE to perform other operations, if necessary, while validation is
ongoing, including work on objects in the validation set. If an object is not available for validation
when the command is initiated on it, validation is not be performed. Also, if validation is in process
on an object, other operations initiated by you on the object fail. Failure to perform validation on an
object is indicated in the Command Results column of the Operations pane.
To validate all objects in the Galaxy, validate the Galaxy object.

Toolbar
The ArchestrA IDE Toolbar consists of icons for quick access to frequently used commands. It is
shown below, and each icon, from left to right, is described afterwards. The description titles
associated with each below are based on the tool tip that appears when you hover over each
Toolbar icon.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-55

Change Galaxy – For selecting a Galaxy repository that is different from the one to
which you are currently connected, this command opens the Select Galaxy dialog box.

Import Automation Object – For importing a template definition file (.aapdf). This
command opens the standard Microsoft Open dialog box with the default file extension
(.aapdf). One or more files can be selected at a time. Validation is done with regard to the
selected file(s) being a valid template definition file. A progress indicator then provides a visual
view of the importing process. After the file(s) is imported, one or more new objects is added to
Galaxy Repository and the Template Toolbox displays the new object(s).

Open – For opening the editor of the object in focus. The editor appears in the Object
Editor Client Area of the Main Window.

Save – For saving the currently-opened object’s configuration, which is persisted to the
Galaxy Repository. This command is available only if the editor for at least one object is open
and configuration data has been modified in at least one of them. Validation occurs on the
editor level; if errors or warnings are identified during validation, they are displayed in a
message box and the user is given the choice to continue saving or cancel the save.

Find – For locating specific objects based on a variety of configurable search criteria.

Check-Out – For checking out an object from the Galaxy Repository so that you can
maintain sole authority to configure that object. Nobody else connected to the Galaxy can
affect the configuration of the object until you have checked it back in to the Galaxy.

Check-In – For checking in to the Galaxy Repository an object which was previously
checked out. This command opens the Check-In Object dialog box.

Undo Check-Out – For changing an object’s status from checked out to checked in.
Afterwards, any user can check out and configure the object. Undo Check Out places a
notation in the object’s change log. Changes you made to the object when it was checked out
are backed out. An error message is displayed when the object’s configuration editor is open.

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

Deploy – For deploying the object or objects currently in focus to the nodes their
configurations denote, this command opens the Deploy Object dialog box.

Undeploy – For undeploying the object or objects currently in focus from the nodes that
currently host them, this command opens the Undeploy Object dialog box.

System Platform - Part 1

1-56 Module 1 – Introduction

Delete – For deleting the object in focus.

Customize Toolsets – For maintaining the toolset categories displayed in the Template
Toolbox, this command opens the Customize Toolsets dialog box.

User Information – For configuring global user preferences for the ArchestrA IDE.
Using this command opens the Configure User Information dialog box.

Galaxy Status – For accessing the status of the current Galaxy.

Model View – For displaying the Model view in the Main Window.

Deployment View – For displaying the Deployment view in the Main Window.

Derivation View – For displaying the Derivation view in the Main Window.

Template Toolbox – For displaying the Template Toolbox in the Main Window.

Graphic Toolbox – For displaying the Graphic Toolbox in the Main Window.

Operations View – For displaying the Operations View in the Main Window.

IDE Help – Standard Help command, used for opening the IDE’s HTML Help
documentation system.
The availability of the previously described icons is dynamic depending on which part of the
ArchestrA IDE’s Main Window is in focus, whether a particular action is allowed, or whether
something has been changed in the configuration environment. Depending on these conditions,
some icons may be unavailable.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-57

Template Toolbox
This part of the Main Window hosts object template toolsets, which contain object Templates, from
which instances are created or other object templates are derived. The Template Toolbox contains
separate toolset bars for each toolset in the Galaxy Repository. Click the toolset bar to open that
toolset and display the object templates contained in the chosen toolset.
When you first log in, the default toolset with default object templates is opened. Once a user has
logged in to the Galaxy Repository, the Template Toolbox is loaded with the toolset that was
displayed during the last login session.
An example of a Template Toolbox view is as follows:

The items with “$” prefixes are templates or templates which were derived from other templates.

System Platform - Part 1

1-58 Module 1 – Introduction

Application Views
The Application Views pane displays the galaxy configuration based on how an object is related to
other objects:
z Model View - This defines the Object relationship to the automation scheme layout. The
Objects are organized into Areas to represent the physical plant layout.
z Deployment View - This view defines the Object instance relationship to the PC that the
Object code is running on.
z Derivation View - This view displays what the derivation path is from Base Template to
Instance. All templates and instances are displayed in this view.
The Model view is the default display when the ArchestrA IDE is first started. Subsequent
ArchestrA IDE sessions retain the user’s last setting.

Model View
The Model view presents objects in terms of their physical or containment relationships, and
allows you to organize them through a folder structure. This view most accurately represents an
application perspective of the processes that users are emulating: for instance, specific process
areas, tanks, valves, pumps and their relationships based on containment.
An example of a Model view is as follows:

Galaxy Name

This view is used to display the assignment of Object Instances to their area. All Object instances
belong to one and only one area.
Areas can be hierarchical. This means that an area can contain an area and the parent area
collects the statistics for all its Objects and its sub-areas.
The above diagram represents the tree view that is displayed within the model view. This
represents the area based relationships of each of the objects. The diagram is read left to right and
top to bottom, so an Area can host Application objects, DeviceIntegrationObjects,.and Objects that
contain Objects
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Area" root of the tree.
The top of the tree is the GalaxyObject, This is displayed using the name that was given to the
Galaxy when it was created.
To assign one object to another, drag-and-drop it. To unassign an object currently assigned to
another object, drag-and-drop it to the Unassigned Area folder.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-59

Deployment View

Note: More detail of the Deployment View is discussed in Module 2, Section 2, “The Deployment
Model”, page 2-13.

The deployment view is used to display the assignment of the automation scheme to physical
machines and process engines. This view describes where the objects are running. This view
does not represent your physical plant environment.
An example of a Deployment view is as follows:

This diagram represents the tree view that is displayed within the deployment view. This
represents the topology view based on which PC and Engines the objects run on. The diagram is
read left to right and top to bottom, so a Platform can host an AppEngine. Also, an AppEngine can
host an Area.
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Host" root of the tree.
To assign an object to another, drag-and-drop it onto the host object. An inappropriate assignment
match is not allowed. Conversely, to unassign an object, drag-and-drop it to the Unassigned folder.

System Platform - Part 1

1-60 Module 1 – Introduction

Derivation View
The Derivation view presents objects and templates in terms of their genealogy relationships. The
derivation view is the only tree view that shows both templates and instances. The purpose of this
view is to display to the user from which templates and derived templates an instance inherits its
properties.
An example of a Derivation view is as follows:

This view contains all templates and instances. The tree is displayed in alphabetical order at each
level within the tree.
The base templates created within the ApplicationObject Toolkit is on the left, as all other
templates and instances are derived from these an extra level will be added to the tree.
The items with “$” prefixes are templates or templates which were derived from other templates.
Base templates are shown in the second level of the tree structure, and derived templates and
object instances are appropriately indented based on their relationship with parent objects.
Templates with no associated instances are grouped together under Unused Templates. Under
each branch of the tree, child objects are listed in alphabetical order. Default objects are displayed
in bold.
Unlike the Model and Deployment views, you cannot drag-and-drop objects from one branch to
another in the Derivation view. The parent-child relationship between a template and a
downstream object cannot be changed dynamically. You can perform other commands on objects
in this view.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-61

Graphic Toolbox
The Graphic Toolbox contains the global ArchestrA graphics that can be used in the Galaxy. It lets
you organize your symbols in special folders, called Toolsets. The Graphics Toolbox shows a
treeview of toolsets which contains ArchestrA Symbols and Client Controls.
It allows you to define graphics as a standard that you can re-use, such as a generic valve symbol.
Symbols in the Graphic Toolbox can later be used by Automation templates and instances. You
can store ArchestrA Symbols here, if you only want to use them in InTouch and not in any other
Automation object content.
An example of a Graphic Toolbox is as follows:

Object Icons
When viewing the objects, there are several states that are reflected in the way the icons for that
particular object are represented.
For instance, notice the different types of icons in the following example:

System Platform - Part 1

1-62 Module 1 – Introduction

Three Types of Status Indicators

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

Icon Description
Undeployed (see AnalogDevice_001 and DDESuiteLinkClient_001 in example above)

(no indicator) Deployed (see AppEngine_002 in previous example)

Deployed with configuration changes (see AppEngine_001 in example above)

Deployed with software update required (see WinPlatform_001 in example above)

Configuration status indicators include:

Icon Description
Configuration warning

Configuration error

(no indicator) Configuration good

Redundancy status indicators include:

Icon Description
AppEngine undeployed, its redundant pair deployed.

AppEngine deployed, its redundant pair not deployed.

AppEngine deployed, its redundant pair not deployed pending configuration updates.

AppEngine deployed, its redundant pair not deployed pending required software update.

InTouch status indicator:

Icon Description
Applies to InTouchViewApp deployment when files are being transferred.

Wonderware Training
 Section 3 – The ArchestrA IDE 1-63

Checking Out/Checking In Objects

Users of the ArchestrA IDE reserve an object for making private changes by checking it out. The
user can then modify the object and save private versions of it before releasing it to the Galaxy
(check in) for others to see and use. You can also back out changes made to the object through
the undo check out feature.

Note: All ArchestrA IDEs connect to a Galaxy display current status for each object in the Galaxy,
and a change history for each object can be reviewed.

If any of the objects you attempt to check out are already checked out to other people then a dialog
appears indicating their status. Also, if some of the objects you attempt to check out are already
checked out to you, the operation is ignored.
The Galaxy marks the objects as checked out to you, making them unavailable for check out to
other users, and it updates the object’s revision history. A check mark is shown next to an object’s
icon in the ArchestrA IDE.
To check out unreserved objects
a. Select them in the Template Toolbox or Application Views.
b. On the Object menu, click Check Out.

Or, right-click on the object and select Check Out. Optionally, an object is automatically
checked out to you when you open its configuration editor. If the object is already checked out,
you can open its editor only in read-only mode.

System Platform - Part 1

1-64 Module 1 – Introduction

To determine an object’s status and history, open the Properties dialog box.

The user responsible for an operation at a specific date and time is listed on the Change Log
page. Comments typed by a user in the Check In dialog box (see image later) are listed under the
Comment heading.
To check an object in to the Galaxy database
a. Select it and, on the Object menu, click Check In

Wonderware Training
 Section 3 – The ArchestrA IDE 1-65

Or, right-click on the object and select Check In. The Check In dialog box is displayed.

Note: If the object was originally checked out to you when you opened its configuration editor,
the check in function can be combined with the save and close functions of the editor. If you
close the editor without making any changes to the object’s configuration, a check in operation
effectively does an undo check out (no change log recorded).

b. Enter a comment (optional) and click OK to finish checking in the object. Click Cancel to
terminate the check in process.
The Galaxy indicates whether any of the objects you are attempting to check in are check-out to
other people. If an object you are attempting to check in already is checked in, check in is ignored.
The Check In dialog box enables you to provide comments about configuration changes made
while the object was checked out. It is comprised of the following options:
z Comment: Use this box to enter your comments about configuration changes made to the
object.
z Don’t Prompt for Check-In Comments in the Future: Use this check box to turn off the
comment feature when checking in objects in the future. If you decide to reinstate this
feature, click User Information on the Edit menu and select Ask for Check In
Comments in the Configure User Information dialog box.

Undo Checkout, Override Check Out

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

System Platform - Part 1

1-66 Module 1 – Introduction

Object Viewer
Note: The Object Viewer is explained in more detail when the Runtime Environment is discussed
in Module 2, Section 3, “The Runtime Environment,”, page 2-27

The Object Viewer monitors the status of the objects and their attributes and can be used to
modify an attribute value for testing purposes.
To add an object to the Object Viewer Watch list, you can manually type the object and attribute
names into the Attribute Reference box in the menu bar and select Go. When prompted to enter
the Attribute Type, press the OK key.
You can save a list of items being monitored. Once you have a list of attributes in the Watch
Window, you can select all or some of them and save them to an XML file. Right-click on the
Watch window to save the selection or load an existing one. You can also add a second Watch
window that shows as a separate tab in the bottom of the Viewer.
Refer to the Platform and Engine documentation for information about attributes that may indicate
system health. These attributes provide alarm and statistics on how much load a platform or
engine may have when executing application objects or communicating with I/O servers and other
platforms.

Determining Galaxy Status

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

You see information about total instances, total templates, deployed instances with changes,
undeployed instances with changes, objects that have an error or warning state, objects that are
checked out, and object you have checked out.
c. Click OK.

Wonderware Training
 Section 4 – Automation Objects 1-67

Section 4 – Automation Objects

Section Objectives
z Introduce the various objects in the ArchestrA IDE
z Identify when and how they are used
z Explain how to create and configure instances of objects
z Introduce and explain the hosting and containment relationships of objects

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

Objects

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

Attributes and Attribute References

Every piece of configuration and data available within an object is called an attribute. Interaction
with objects, in configuration or runtime, is done through the attributes of the specific object.
Attribute references refer to data within an object's attributes; it consists of an object's reference
string plus an attribute's reference string, separated by a dot ("."):
ObjectName.AttributeName
An object reference cannot exceed 32 characters (including the $ character used in template
names) and must contain at least one non-numeric character.

System Platform - Part 1

1-68 Module 1 – Introduction

You should avoid assigning objects and attributes the same names because this may result in an
attribute reference can refer to two different things. For example, if you have two objects, A1 and
B2, where A1 is the container of B2, and object A1 has an attribute named B2, the reference string
A1.B2 could either refer to the B2 attribute within A1, or the B2 object contained in A1.

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

Wonderware Training
 Section 4 – Automation Objects 1-69

Application Objects

Application Objects are used to create devices in your Galaxy. These devices represent real
objects in your environment.
AnalogDevice Object
This object can act as either an Analog Input (with optional Output) or as an AnalogRegulator that
provides an external representation of a PID controller that exists elsewhere (typically a PLC or
DCS).
The AnalogDevice can be configured to have a personality of one of the two basic types:
z Analog – a basic Analog Input or Analog Output
z AnalogRegulator – an analog controller that represents an external PID controller
When configured as Analog, this Template is very similar in functionality to the Analog Tag within
InTouch today. Just as the InTouch Analog can be configured for Read or ReadWrite, the
Archestra AnalogDevice configured as type Analog can be configured as an analog input (with no
output capability) or as an analog output (with output capability). The Analog supports the basic
alarming capabilities of level alarms, ROC alarms and deviation alarms from a SP target value. In
addition, the Analog in ArchestrA provides additional functionality such as PV override enable, PV
mode (auto, manual), bad PV alarming, and separate output reference capability.
When configured as an AnalogRegulator, this Template provides both PV and SP monitoring of an
external PID controller. It provides SP output capability with an optional separate feedback
address for the SP. Other controller-oriented features include controller mode (manual vs.
cascade). All the alarm capabilities of the more basic AnalogDevice object are included, with the
difference that the SP value for deviation alarms is based on the SP value read from the controller.
Some of the common features of the AnalogDevice regardless of type (Analog or
AnalogRegulator) are:
z Supports optional scaling of input and output, both linear and square root conversions.
z Supports HiHi, Hi, Lo, and LoLo level alarms on PV with both value and time
deadbanding.
z Supports Rate of Change (ROC) alarming on PV for both positive-slope and negative-
slope ROC.
z PV Override – when true, allows the PV to be written by a user if the PV mode is set to
Manual.
z Adds SP read and write capability with optional separate read-back address. For data
integrity, the value of SP always represents the value read from the external controller, not
the requested SP that is output to the external controller.
z Supports minor and major deviation alarming when PV deviates from SP.

System Platform - Part 1

1-70 Module 1 – Introduction

z Initial Control Mode – When in Cascade, the SP can only be written by other objects.
When in Manual, a user can write the SP. When None, anything can write to it.
z Control Tracking – optional capability to read a Boolean control track flag from an external
device or object. When tracking is on, the SP is pure read-only and cannot be changed.
Boolean Object
The Boolean object is derived from the FieldReference object and is used for evaluations that
result in either of the truth values of ‘true’ of ‘false’, often coded 1 and 0 respectively.
DiscreteDevice Object
A Discrete Device is a general purpose Object that is used to represent a large class of physical
equipment common in manufacturing such as pumps, valves, motors, and conveyors. These
devices have two or more physical states (for example Open, Closed, Moving), and are optionally
controlled using a combination of discrete outputs. Their actual state is monitored via a
combination of discrete inputs.
The meaning of the states depends on the kind of Discrete Device. In the case of a pump, the
states might be configured as “Off” and “On”, while for a valve they might be configured as “Open”,
“Closed”, or “Moving”. Note that a control valve has a continuous position represented by 0 to
100% and is not typically represented with a Discrete Device, since its state is represented by a
continuous signal rather than discrete signal.
When a Discrete Device is commanded to a new state, it sets an appropriate combination of
discrete outputs for that state. When its monitored discrete inputs change, the Discrete Device
determines the new actual state of the equipment and sets the “PV” (process variable)
appropriately.
Through the use of the Discrete Device the operator is guaranteed that a value displayed on the
screen is a good and reliable value. This object will automatically display the state as “Bad” if the
quality of any of the inputs is bad or the inputs are in an invalid combination determined at
configuration time by the application developer.
Some of the features of the Discrete Device object are as follows:
z Input and Output states of the DiscreteDevice object are totally independent of each other
and can be configured as required by the user’s application.
z Input and Output can be linked by alarms, which allow the object to detect
CommandTimeout and UncommandedChange alarms, when devices unexpectedly
change, or fail to change when commanded.
z Supports devices with two to three commandable states (‘Passive’, ‘Active1’, and
‘Active2’) plus two additional states ‘Fault’ and ‘InTransition’ which cannot be commanded.
All those states with the exception of ‘InTransition’ and 'Passive' can trigger a state alarm.
z Supports the three input modes ‘Auto’, ‘Manual’, and ‘Simulate’.
z Supports the two control modes ‘Manual’ and ‘Cascade’.
z CtrlTrack allows a PLC to notify the Discrete Device that the PLC is in control of the state
of the actual physical device, and is no longer accepting commands. If configured this
way, the Command attribute of the DiscreteDevice object just tracks PV (i.e., the state
indicated by its inputs).
Double Object
The Double object is derived from the FieldReference object.
FieldReference Object
The FieldReference object is the generic object for accessing data from an external device. This
object can act as both the field input and a field output.

Wonderware Training
 Section 4 – Automation Objects 1-71

The FieldReference Object can be configured into three basic access modes:
z ReadOnly – Input object
z ReadWrite – Output object with scanned Feedback
z WriteOnly – Output
This object is very simple; it only allows the value to be historized.
Float Object
The Float object is derived from the FieldReference object.
Integer Object
The Integer object is derived from the FieldReference object.
Sequencer Object
The Sequencer object allows you to configure, execute, and manipulate a sequence of operations
associated with ArchestrA attributes within a Wonderware Application Server application.
You can use it to automate:
z repetitive manufacturing procedures with a finite number of steps
z supervisory processes with a finite number of steps

Note: There is an Online Seminar available for the ArchestrA Sequencer Object. To register,
visit www.wonderware.com/training or call 1-866-WW-TRAIN (1-866-998-7246) or email
Wonderware Training at [email protected].

SQLData
The SQLData Object is an ArchestrA application object that can be used to store data to, and
retrieve data from a SQL Server database. The SQLData Object provides the means to map data
in a SQL database to attributes in a Galaxy.
String Object
The String object is derived from the FieldReference object.
Switch Object
The Switch object is the object for accessing data from a simple discrete (0/1) device. This object
can act as both a discrete input and a discrete output.
The Switch Object can be configured into three basic access modes:
z ReadOnly – Input object
z ReadWrite – Output object with scanned Feedback
z WriteOnly – Output
The PV value can be historized, logged as an event, and alarmed when abnormal.
UserDefined Object
The UserDefined object is an empty object that you can use to create customized objects. You can
use the UserDefined object in the following ways:
z As a "container" for other objects. An object relationship in which one object is comprised
of other objects is called containment. Containment allows you to group various objects
together to make complex objects. For detailed information on object containment, see the
ArchestrA IDE documentation.

System Platform - Part 1

1-72 Module 1 – Introduction

To use the UserDefined object as a container object, you simply create an instance of the object,
and add ApplicationObjects to it while in the Model View. The only indication of this containment
structure is in the tree structure in the Template Toolbox or Model View. The UserDefined object
editor does not provide any indication of this containment relationship. To edit the configuration of
any contained objects, you must open the individual editors of those objects.

Note: A UserDefined object can only contain ApplicationObjects.

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

Device Integration Objects

A DeviceIntegration object (DIObjects) is an AutomationObject that represents communication

with external devices. DIObjects run on an AppEngine, and include DINetwork Objects and
DIDevice Objects. A DIDevice Object is a representation of an actual external device (for example,
a PLC or RTU) that is associated with a DINetwork Object. A DINetwork Object is a representation
of a physical connection to a DIDevice Object via the Data Access Server.
A more detailed discussion of the Device Integration Objects will take place later in this course in
Module 2, “Application Infrastructure”, Section 4, “Connecting to the Field” on page 2-41

Wonderware Training
 Section 4 – Automation Objects 1-73

System Objects

System objects are used to define system instances.

AppEngine Object
The AppEngine Object must have a Platform on which to run. The key functionality of this object
includes:
z hosting application objects, device integration objects and areas
z containing the logic to setup and initialize objects, when they’re deployed.
z containing the logic to remove objects from the engine, when they’re undeployed.
z determines the scan time within which all objects within that particular engine will execute.
In general the AppEngine contains no added value other then to support the creation, deletion,
startup, and shutdown of objects.
Area Object
The Area Object plays a key role in alarm and event distribution. All AutomationObjects belong to
an Area. Areas can contain sub-Areas. Areas provide a key organizational role in grouping alarm
information and assigning it to those who use alarm/event clients to monitor their areas of
responsibility.
This object is very simple; it only allows the value of three attributes to be historized:
z Active alarm counter
z Unacknowledged alarm counter
z Disabled (or silenced) alarm counter
InTouchViewApp Object
The InTouchViewApp object represents an InTouch for System Platform application. The
InTouchVewApp object manages the check-in, check-out, and deployment of an InTouch
application.
When you create an InTouchViewApp for a new InTouch application, WindowMaker is started by
the ArchestrA IDE. You then create the application the same way you would if WindowMaker had
been started from the InTouch Application Manager.
ViewEngine Object
The ViewEngine object is used to host InTouchViewApp objects. The ViewEngine object supports
common engine features such as deployment, undeployment, startup and shutdown. One
ViewEngine object can handle several InTouchViewApp objects.
WinPlatform Object
The WinPlatform platform object is a key base object. The key functionality of this object includes:
z Calculating various statistics related to the node it’s deployed to. These statistics are
published in attributes.
z Monitoring various statistics related to the node it’s deployed to. These monitored
attributes can be alarmed as well has historized.

System Platform - Part 1

1-74 Module 1 – Introduction

z Starting and stopping engines, based on the engines startup type, which are deployed to
it.
z Monitoring the running state of engines deployed to it. If the platform detects an engine
has failed it can (optionally based on the value of the engine’s restart attribute) restart the
engine.
There is a special instance of the platform object called the galaxy platform. This platform instance:
z Exists on the galaxy node.
z Is used by message exchange to bind unresolved attribute references

Templates and Instances

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

Wonderware Training
 Section 4 – Automation Objects 1-75

Using the Diaphragm valve template, you can quickly create an Diaphragm valve instance when
you need another Diaphragm valve in your application.

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

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

Creating and Deleting Instances

ApplicationObject instances are created from the templates provided by the Template Toolbox.
A default name is given to the new instance. The newly created Object instance is put into focus
and set to rename mode.
This view also allows the Object instance to be edited.
Object instances can be deleted from this view if the Object does not have any other Objects
assigned to it.
By default the first instance of the Platform object will be configured with the name of the Galaxy
Repository node name. This platform can then be renamed.

System Platform - Part 1

1-76 Module 1 – Introduction

There are two ways to create an instance of a template. This is indicated as follows:

Creating an Instance - Method 1

Drag and drop the template object from the Template Toolbox to the Application View. To delete an

instance of the Platform object highlight it and click on the Delete icon in the menu icon bar ,
or, right-click on it and select Delete.

Notice you are looking at

the Model View.

Wonderware Training
 Section 4 – Automation Objects 1-77

Once the instance has been created it displays as follows:

It can now be renamed using the naming convention as designated by your instructor.

Creating an Instance - Method 2

Highlight the object in the Template Toolbox for which you desire an instance. Then from the
Galaxy menu, select Galaxy/New/Instance or use the short cut which is Ctrl+N.

System Platform - Part 1

1-78 Module 1 – Introduction

– Intentionally left blank –

Wonderware Training
 Section 5 – System Requirements, Licensing and Support 1-79

Section 5 – System Requirements, Licensing and Support

Section Objectives
z Describe the necessary system requirements for a successful installation
z Discuss Licensing requirements
z Discuss Support services

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

System Requirements for Wonderware Application Server/Galaxy

Repository

Minimum Hardware Requirements

The following list shows the minimum computer hardware requirements to host Application Server
version 3.1 components.
z 2 gigahertz (GHz) or faster dual core processor, or a 3 GHz or faster single core
processor. A dual core processor is strongly recommended for optimal performance
z Minimum of 2 gigabytes (GB) RAM. For Galaxies with more than 500 objects, 4 GB
RAM is recommended in the GR node
z 30 GB of available disk space
z Super VGA (1024 x 768) or higher resolution video adapter and monitor.
z Network interface card
z CD-ROM or DVD drive
z Keyboard
z Mouse or a compatible pointing device
Development and Application nodes
z 2 GHz or faster processor
z Minimum 1 gigabyte (GB) RAM. For improved performance 4 GB RAM is strongly
recommended
z 30 GB of available disk space
z Super VGA (1024 x 768) or higher resolution video adapter and monitor
z Network interface card
z CD-ROM or DVD drive
z Keyboard
z Mouse or compatible pointing device
The hardware requirements for using the Alarm Client and Trend Client at run time are the same
as for the InTouch HMI version 10.1 run time.
The Windows Vista operating system imposes hardware requirements that may exceed the
minimum requirements for Application Server version 3.1. If you intend to install Application Server
3.1 on a computer running Windows Vista, see the following Microsoft web site for hardware
requirements:
www.microsoft.com/windows/products/windowsvista/editions/systemrequirements.mspx

System Platform - Part 1

1-80 Module 1 – Introduction

Software Requirements
This section describes the operating system, database, and other software requirements to install
Application Server version 3.1.
z Operating Systems
z SQL Server Database Requirements
z Other Software Requirements

Operating Systems
z Windows Server 2003 Standard Edition SP2 is the recommended operating system
for computers running server components.
z Windows XP SP3 is the supported XP version for this release.
z Windows XP Professional SP3 is the recommended operating system for computers
running client components.
The following table lists the supported operating systems that can be installed on computers
running as Application Server development, application, and GR nodes. Development and
application nodes are considered to be clients of the server GR node.

Operating Systems Wonderware Application Server Components

ArchestrA IDE ArchestrA Run Galaxy
(Development Time Repository
Node) (Application (GR Node)
Node)
Windows Vista Business (See Vista Restrictions) x x x
Windows Vista Business SP1 (See Vista Restrictions) x x x
Windows Vista Enterprise (See Vista Restrictions) x x x
Windows Vista Enterprise SP1 (See Vista Restrictions) x x x
Windows Vista Ultimate (See Vista Restrictions) x x x
Windows Vista Ultimate SP1 (See Vista Restrictions) x x x
Windows Server 2003 Standard Edition SP2 x x x
Windows Server 2003 Enterprise Edition SP2 x x x
Windows Server 2003 Standard Edition R2 SP2 x x x
Windows Server 2003 Enterprise Edition R2 SP2 x x x
Windows XP Professional SP3. See Note 2. x x See Note 2
Windows XP Tablet x

Notes:
1. The Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server
operating systems are not supported for Application Server version 3.1. An error occurs if you
attempt to install or upgrade Application Server version 3.1 on a computer running any edition
of the Windows 2000 operating system.
2. The computer designated as the Galaxy Repository node can run on Windows XP Pro only as
a single-node configuration of Application Server. Windows Server 2003 is the recommended
operating system for the GR node.
3. You can run Application Server only on computers running a 32-bit operating system. You
cannot run Application Server on a computer running a 64-bit operating system.
4. The Bootstrap, IDE, and Galaxy Repository are supported by the following language versions
of Microsoft operating systems: English, Japanese, Chinese, German, and French. The
Galaxy Repository is also supported by the English, Japanese, Chinese, German, and French
versions of Microsoft SQL Server 2005.

Wonderware Training
 Section 5 – System Requirements, Licensing and Support 1-81

SQL Server Database Requirements

Microsoft SQL Server 2005 with SP2 is the only database supported by Application Server version
3.1. You must use the Standard or Enterprise editions of SQL Server 2005. Neither the Compact,
Express, nor the Workgroup editions of SQL Server 2005 can be used as the Galaxy Repository.
z SQL Server 2005 SP2 must be installed on the computer designated as the ArchestrA
Galaxy Repository node prior to installing Application Server.
z You also cannot install and use Application Server on a computer that has both Microsoft
SQL Server 2000 and Microsoft SQL Server 2005 installed.
z The Galaxy Repository locks the SQL Server maximum memory usage to 65% of the
computer's physical memory.
z TCP/IP must be enabled on the computer hosting a SQL Server 2005 database. The TCP/
IP protocol setting can be verified from the SQL Server 2005 Network Configuration under
SQL Server Configuration Manager.
z The Microsoft SQL Server 2005 login for BUILTIN\Administrators group must be present
and enabled.

Other Software Requirements

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

Alarm Client and Trend Client Requirements

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

Using Application Server with Windows Vista

This section describes specific restrictions when using the Windows Vista operating system with
Application Server and how to configure multiple Network Information Cards on a computer
running Windows Vista.

System Platform - Part 1

1-82 Module 1 – Introduction

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

Using Multiple Network Interface Cards with Windows Vista

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

Wonderware Training
 Section 5 – System Requirements, Licensing and Support 1-83

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

System Platform - Part 1

1-84 Module 1 – Introduction

Wonderware System Platform Licensing

Licensing
To calculate the licenses needed to implement an application based on the Wonderware System
Platform, it is necessary that you understand and gather the following information:

Application Server IO Count Number of I/O points accessed by the Galaxy.

Application Server Platform Count Number of dedicated Application Object Server nodes in the
application.
Historian Server Count Number of Historian Server nodes in the application.
Information Server and Clients Count Number of Information Server nodes in the application and
number of nodes that are going to access the servers
remotely.
Device Integration Server Count Number of Device Integration Server nodes in the
application.
InTouch for System Platform Count Number of visualization nodes required in the application.
ActiveFactory Count Number of dedicated ActiveFactory nodes in the application.
Development Studio Count Number of development workstations in the application.

Wonderware System Platform

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

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

The Wonderware System Platform license is available in different sizes, each one offered as a
unique combination of the following:
z Application Server IO-count
z Historian Server Tag-count
z the number of Application Server Platforms included

Wonderware Training
 Section 5 – System Requirements, Licensing and Support 1-85

Wonderware System Platform Options licenses, listed below, are added to this license as
needed, depending on the size of the system and requirements:
z additional Historian Servers with Platform available at different Tag-counts
z additional Information Servers with Platform
z additional Device Integration Servers
z additional Application Server Platforms

Wonderware Clients
In addition to the Wonderware System Platform, one or more of the following Wonderware
Clients are usually required:
z InTouch for System Platform (also available as Terminal Services Edition if needed)
z Information Server Client
z ActiveFactory
The InTouch for System Platform license includes an Application Server Platform and is
available in different flavors, as follows:
z InTouch for System Platform with Trend/Analysis*
z InTouch for System Platform without Trend/Analysis*
z InTouch for System Platform Read-only with Trend/Analysis*

* Trend/Analysis refers to an ActiveFactory license.

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

z Information Server Advanced Client
z Information Server Standard Client; which lacks InTouch Write Back, InBatch and QI
Analyst integration.
The ActiveFactory license supports Terminal Services Server applications (except with a Per
Device license).

Wonderware Development Studio

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

System Platform - Part 1

1-86 Module 1 – Introduction

An Unlimited version of the Wonderware Development Studio license includes all the above
products, plus:
z Information Server
z Information Server Client
z ActiveFactory
z InControl
The Wonderware Development Studio license is available in different sizes, each one offering a
unique combination of:
z Application Server IO-count
z InTouch Tag-count
z Historian Server Tag-count

Wonderware Training
 Section 5 – System Requirements, Licensing and Support 1-87

Installation
For instructions on installing Wonderware Application Server, see the installation document
located in the root folder of the installation CD.
Additionally, refer to the “Wonderware Software Installation” series of online seminars where a
session corresponding to System Platform - Part 1 may be available.
Wonderware eLearning training options are located at http://www.wonderware.com/training.

Product support
Wonderware provides responsive, award-winning teams of specialists committed to delivering
world-class customer support, training, and consulting services. For information on the various
customer support programs, contact your local distributor or access the Wonderware Technical
Support site online at http://www.wonderware.com/support/mmi/
You will find a variety of information on the Technical Support site including the Wonderware
Developer Network (WDN) Library, Documentation, FAQs, Tech Alerts, Tech Articles, Tech Notes,
and Tech Support Forums. When you first enter the site, you will have limited access. To gain
access to the different areas and services, you must first register.
Also on the Technical Support site is the Technical Support Policies, Terms & Conditions guide
which provides information on how to contact Technical Support, information on the support
policies and procedures, and much more.

System Platform - Part 1

1-88 Module 1 – Introduction

– Intentionally left blank –

Wonderware Training
 Section 6 – Application Planning 1-89

Section 6 – Application Planning

Section Objectives
z Explain a project workflow and area devices and why they are needed
z Identify functional requirements and naming conventions
z Expand on the concept of ArchestrA and how it relates to the manufacturing
environment.
z Explain the benefits of migrating to an ArchestrA architectural environment.

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

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

Suggested Project Workflow

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

Identify Field Devices and Functional Requirements

Define Naming Conventions

Define the Area Model

Plan Templates

Define the Security Model

Define the Deployment Model

System Platform - Part 1

1-90 Module 1 – Introduction

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

Identifying Field Devices and Functional Requirements

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

Identifying Field Devices

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

Wonderware Training
 Section 6 – Application Planning 1-91

The following diagram shows a simple P&ID:

),&


)9
37


77
),& 


)9
'5,9(
/,& )7

 

&7

/7
 37


)7
)9 

&7
'5,9( 

)9

The key for this P&ID is as follows:

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

System Platform - Part 1

1-92 Module 1 – Introduction

Identifying Functional Requirements

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

Defining Naming Conventions

The second step in the workflow is to define the naming conventions for templates, instances, and
object attributes. Naming conventions should adhere to:
z Conventions that you use within your company.
z ArchestrA IDE naming restrictions. For example, you might have an instance tagname of:
YY123XV456
with the following attributes:
OLS, CLS, Out, Auto, Man
The following illustration shows how the naming convention in a traditional Human-Machine
Interface (HMI) is different from the naming within ArchestrA IDE:

+0,V $UFKHVWU$

<<;9?2/6 2/6 For more

information refer
<<;9?&/6 &/6 to the InTouch to
IAS Migration
<<;9?2XW <<;9 2XW document
<<;9?$XWR $XWR

<<;9?0DQ 0DQ

,QGLYLGXDO7DJV 2EMHFW 2EMHFW

$WWULEXWHV

Wonderware Training
 Section 6 – Application Planning 1-93

For ArchestrA IDE, references are created using this naming convention:
<objectname>.<attributename>
For example:
YY123XV456.OLS

Defining the Area Model

The third step of the project workflow is to define the Area model. An Area is a logical grouping
within your application that represents a portion of the layout of your plant. In a typical
manufacturing plant, you would define the following Areas: Receiving Area, Process Area,
Packaging Area and Discharge Area. You will need to define and document all of the Areas of your
plant that will be part of your application.
Each object will need to be assigned to a particular Area. When you install Application Server, a
single placeholder is created by default, called "Unassigned." Unless you specify otherwise, all
object instances will be assigned to this placeholder location.
The following are a few tips for creating Areas:
z If you create all of your Areas first, you can easily assign an object instance to the correct
Area if you set that particular Area as the Default Area; otherwise, you will have to move
them out of the unassigned Area later.
z It is helpful to create a System Area to which you can assign instances of WinPlatform and
AppEngine objects. WinPlatform and AppEngine objects are used to support
communications for the application, and do not necessarily need to belong to a plant-
related Area or any Area for that matter.
z Alarms will be grouped according to Areas.
z Areas can be nested.
When building an Area hierarchy, keep in mind that the base Area that is assigned to a Platform
determines how the underlying objects will be deployed. If a plant area (physical location) is going
to contain two computers running AutomationObject Server platforms, then two logical Areas will
have to be created for the one physical plant area.
One approach for creating instances of an object is to create an instance for one Area at a time. If
you use this approach, then mark the Area as the default, so that each instance is automatically
assigned to the selected Area. Before you begin to create instances in another Area, change the
default to the new Area.
A final consideration for constructing Areas is that the various Areas equate to alarm groups. It is
at the Area level that alarm displays can easily be filtered.

Planning Templates
A template is an element that contains common configuration parameters for objects that are used
multiple times within a project. Templates are instantiated to represent specific objects within the
application.
For example, you might need multiple instances of a valve within your application, so you would
create a valve template that has all of the required properties. This allows you to define once and
reuse multiple times. If you change the template, the changes can be propagated to the instances.
You can use simple drag-and-drop within the ArchestrA IDE to create instances from templates.
Additional information on how to actually develop objects using templates is covered in Module 3,
“Planning for Object Templates” on page 3-5.

System Platform - Part 1

1-94 Module 1 – Introduction

The next two steps, defining the security model, and defining the deployment model, are done
once the initial Plant Model is in place. These are steps are detailed in subsequent modules in this
training course. Please refer to additional information which is available in the Wonderware A2
Deployment Guide.
Define Security Model: Each attribute of an AutomationObject is given a security classification.
This provides the ability to define who can write to attributes of an object.
Define Deployment Model: The Deployment Model view shows which objects instances reside
on which computers. In the ArchestrA environment, the physical location of object instances is not
required to approximate the real-world environment it models. The Deployment view does not
need to reflect your physical plant environment.

Wonderware Training
 Lab 2 – Identifying the Mixer 1-95

Lab 2 – Identifying the Mixer

Introduction
This lab provides several detailed diagrams which identify components of a simulated factory
layout for this training scenario, as well as the main pieces of equipment that you will model and
develop during this course.
The following diagrams provided in this lab will be used as references:
z Factory Layout
z Heat Exchanger: Process Diagram & Field I/O Signals
z Mixer: Process Diagram & Field I/O Signals
Your instructor will assign you a student number that you will use to create the unique identifiers
for each heat exchanger and mixer assigned to you.
This lab will help familiarize you with the plant processes on which the remaining labs are based.

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

System Platform - Part 1

1-96 Module 1 – Introduction

Summary Lab Instructions

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

This lab contains several intricate parts that are not easily summarized.
Please refer to the Detailed Lab Instructions on the next page.

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 2 – Identifying the Mixer 1-97

Detailed Lab Instructions

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

Identify the Sample Application

This lab is an instructor-led group discussion and therefore does not have specific steps. In this lab
you will study and discuss the diagrams on the following pages with your instructor, and create the
IDs for the heat exchangers and mixers assigned to you.

Description of the Mixer System

The mixer system consists of the following devices and functionality:
3 valves:
z Inlet 1: Inlet 1, opens to add the first material into the tank
z Inlet 2: Inlet 2, opens to add the second material to the tank
z Outlet: drains the tank
2 pumps:
z Pump 1: Pump 1, pumps the first material into the tank
z Pump 2: Pump 2, pumps the second material into the tank
1 motor:
z Agitator: Mixes the materials in the tank
2 meters
z LIT: Current level of the tank
z TT: Current temperature of the tank
Description of the Process
In this class a simulated mixer system process continuously executes batches (runs) with the
following steps:
1. Add first material to the tank
2. Add second material to the tank
3. Mix the material in the tank
4. Drain the tank

System Platform - Part 1

1-98 Module 1 – Introduction

Specifically, the devices of the mixer system are automatically operated by the simulation to
perform the steps indicated previously through the following sequence:

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

Note: The simulation uses randomization to ensure the LIT and TT meter values differ from batch
to batch.

Wonderware Training
Lab 2 – Identifying the Mixer 1-99

System Platform - Part 1

1-100 Module 1 – Introduction

Wonderware Training
Lab 2 – Identifying the Mixer 1-101

System Platform - Part 1

1-102 Module 1 – Introduction

Wonderware Training
 Lab 2 – Identifying the Mixer 1-103

– Intentionally left blank –

System Platform - Part 1

1-104 Module 1 – Introduction

Wonderware Training
 Module 2

Application Infrastructure
Section 1 – The Plant Model 2-3
Lab 3 – Creating the Plant Model 2-5
Section 2 – The Deployment Model 2-13
Lab 4 – Creating the Deployment Model 2-17
Section 3 – The Runtime Environment 2-27
Lab 5 – Using Object Viewer 2-31
Section 4 – Connecting to the Field 2-41
Lab 6 – Connecting to the Field 2-51
2-2 Module 2 – Application Infrastructure

Module Objective
z Explain the concept and describe the need of developing a Plant Model before
configuring the Wonderware Application Server
z Identify key factors necessary for building successful applications.
z Explain Galaxies and introduce you to the ArchestrA IDE
z Explain Plant Modeling as it relates to Objects and Object Instances

Wonderware Training
 Section 1 – The Plant Model 2-3

Section 1 – The Plant Model

Section Objectives
z Explain the importance of having a model of the plant facility
z Examine the concept of how to utilize ArchestrA Application Server to model a specific
facility

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

Modeling of the Facility

With the Wonderware Application Server it is possible to create a working model of the plant
manufacturing environment which will utilize the product. Having this model will enable you to
implement a structured naming convention that will facilitate the coordination of all the processes
and areas. It will also provide the ability to create objects representing your actual plant, configure
them to your own specifications and create templates from them which will enable you to
propagate one area to another.
The ArchestrA plant application model allows you to organize a distributed computing application
by:

Plant Section Area Production Manufacturing

Line Cell

Once a plant application model has been developed, applications can be easily extended or
replicated based on the structure you have provided. With this Facility Model you can:
z Rapidly create application standards
z Deploy applications across multiple plants or projects
This provides universal application development capabilities. Additionally, it provides the ability to
build industrial applications that ensure consistent engineering quality and operational best
practices.

System Platform - Part 1

2-4 Module 2 – Application Infrastructure

Reporting Alarms Based on Area Model

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

• Area AutomationObjects All AutomationObjects and Area objects report

detected alarms through the Area, which distributes
them to alarm and event clients.
• WinPlatform AutomationObjects Report their own alarms and events
• AppEngine AutomationObjects Report their own alarms and events

• Device IntegrationObjects Report their own alarms and events

WinPlatforms, AppEngines and Device Integration objects do not report their alarms and events to
Area AutomationObjects even though they belong to Areas. This allows alarm clients to receive
alarm notifications without any dependencies on Area AutomationObjects. For example, a
deployed and running WinPlatform can report alarms even though its Area is not deployed and
running.
Using the Area model will become a filtering mechanism for alarms when we cover the Module on
Alarms and History.

Wonderware Training
 Lab 3 – Creating the Plant Model 2-5

Lab 3 – Creating the Plant Model

Introduction
This lab illustrates the steps necessary to create the plant model for the Galaxy based on the
information gathered in Lab 2, “Identifying the Mixer”. You will create an additional $Area instance
named ControlSystem to accommodate future system objects created throughout the rest of this
class.
To help organize the templates, you will develop a custom toolset named Training to hold the
templates created in the class.

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

System Platform - Part 1

2-6 Module 2 – Application Infrastructure

Summary Lab Instructions

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

Create a Template Toolset (page 2-7)

a. Create a new Template Toolset named Training under the Galaxy.
Create the Plant Model (page 2-8)
b. Create a derived template from the $Area object named $tArea and assign it to the Training
template toolset.
c. Create the following instances out of the new $tArea template:
z Discharge
z Intake
z Production
z Line1
z Line2
z ControlSystem
d. Arrange the new $tArea instances to model the factory layout defined in Lab 2.

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 3 – Creating the Plant Model 2-7

Detailed Lab Instructions

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

Create a Template Toolset

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

System Platform - Part 1

2-8 Module 2 – Application Infrastructure

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

Create the Plant Model

3. In the Template Toolbox, right-click the $Area template and select New / Derived Template.

Wonderware Training
 Lab 3 – Creating the Plant Model 2-9

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

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

6. Ensure that the Model view is selected.

System Platform - Part 1

2-10 Module 2 – Application Infrastructure

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

8. Name the new instance Discharge.

9. Repeat the previous 2 lab steps to create the following Areas:
z ControlSystem
z Intake
z Line1
z Line2
z Production
The ControlSystem Area will be used in this example to accommodate future system objects
created throughout the rest of this class.

Wonderware Training
 Lab 3 – Creating the Plant Model 2-11

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

System Platform - Part 1

2-12 Module 2 – Application Infrastructure

– Intentionally left blank –

Wonderware Training
 Section 2 – The Deployment Model 2-13

Section 2 – The Deployment Model

Section Objectives
z Explain the concept of the Deployment Model.
z Demonstrate the structure and organizational execution of the Deployment Model.

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

Deploying the Galaxy

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

Planning for Deployment

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

Object Viewer,
IDE Configuration Environment deploys to
Run-time environment
Galaxy database : [Does not exist in run-time environment]

Templates : [Does not exist in run-time environment]

Instance Objects : Instance objects [Run-time configuration and

behavior]

Security: General permissions : [Does not exist in run-time environment]

Security: Operational permissions : Run-time permissions to acknowledge alarms and

modify attributes

Scripts configuration : Scripts execution

Alarms configuration : Alarms generate and acknowledge

History configuration : History Logs

[Wonderware Historian]

System Platform - Part 1

2-14 Module 2 – Application Infrastructure

Deploy an Object
a. Select the object in an Application view.
b. On the Object menu, click Deploy. The Deploy dialog box appears.

c. Select one or more of the following

z Cascade Deploy: Select this check box to deploy the object selected for deployment as
well as any objects it hosts. This option is selected by default if the object is a host. If you
are deploying an individual host object, clear the check box. Objects being deployed
across multiple platforms will be deployed in parallel.
z Include Redundant Partner: Select this check box to also deploy an AppEngine's
redundancy partner object. This option is selected and unavailable when the redundant
engine has pending configuration changes or software updates.
d. In the Currently deployed objects area, select one or more of the following options. These
options are not available if the selected object has not been deployed before.
z Skip: If one of the objects you are deploying is currently deployed, selecting Skip makes
no changes to the already-deployed object.
z Deploy Changes: If one of the objects you are deploying is currently deployed, this option
updates the object in question with new configuration data.
z Redeploy Original: If one of the objects you are deploying is currently deployed, this
option deploys the same version as previously deployed. For example, use this option to
redeploy an object that is corrupted on the target computer.
z Force Off Scan: If one of the objects you are deploying is currently deployed, this option
sets the target object to off scan before deployment occurs.
e. In the Currently undeployed objects area, select the Deploy New Objects check box to
start a normal deployment.
f. In the Deploy Status Mismatch area, select the Mark as Deployed check box to mark the
object as deployed in the Galaxy. A mismatch happens when the object is previously deployed
to a target node, but the Galaxy shows the object is undeployed. Clear this option to redeploy
the object to the target node.
g. In the Initial Scan State area, select one of the following:

Wonderware Training
 Section 2 – The Deployment Model 2-15

z On Scan: Sets the initial scan state to on scan for the object(s) you are deploying. If the
host of the object you are deploying is currently off scan, this setting is ignored and the
object is automatically deployed off scan. While deploying multiple objects the deploy
operation will deploy all of the selected objects "off-scan." Once all of the objects are
deployed the system will set the scan-state to "on-scan."

Note: Objects can only execute when both the host/engine is "on scan" and the object is "on
scan." If either the host/engine or the object is "off scan," the object can not execute.

Note: Always deploy Areas to their host AppEngines on scan. Since Areas are the primary
providers to alarm clients, deploying Areas off scan results in alarms and events not being
reported until they are placed on scan.

z Off Scan: Sets the initial scan state to off scan for the object(s) you are deploying. If you
deploy objects off scan, you must use the ArchestrA System Management Console
Platform Manager utility to put those objects on scan and to function properly in the
runtime environment.

Note: The System Management Console controls on the state of the host/engine. The
ObjectViewer controls the state of the objects.

Note: The default scan setting is set in the User Default settings in the Configure User Information
dialog box.

h. Click OK to deploy the object(s). The Deploy progress box appears. When the deploy is
complete, click Close.

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

System Platform - Part 1

2-16 Module 2 – Application Infrastructure

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

Note: Undeploying can fail if the target object has objects assigned to it. Make sure you select
Cascade Undeploy in the Undeploy dialog box.

a. On the Object menu, click Undeploy. The Undeploy dialog box appears.

In the upper right of this dialog box, the Undeploy Object Count box shows the number of objects
being undeployed. You can select a single object in Application view and, if you selected
Cascade Undeploy and other objects are assigned to the selected object, the total number of
objects appears in this box.
b. Select one or more of the following. Some of these options might not be available, depending
on the kinds of object you select.
z Cascade Undeploy: Select to undeploy the selected object as well as any objects it
hosts.
z Include Redundant Partner: Select to also undeploy an AppEngine's redundancy partner
object.

Note: The AppEngine in a redundant pair that was configured as the Primary can be undeployed
alone because objects hosted by it run on the deployed Backup AppEngine, which becomes
Active.

z Force Off Scan: If one of the objects you are undeploying is currently on scan, selecting
Force Off Scan sets the target object to off scan before undeployment. If you do not select
Force Off Scan and the target object is on scan, the undeployment operation fails.
z On Failure Mark as Undeployed: Marks the object as undeployed in the Galaxy when
the object targeted for undeployment is not found

Wonderware Training
 Lab 4 – Creating the Deployment Model 2-17

Lab 4 – Creating the Deployment Model

Introduction
This lab illustrates the steps necessary to create a deployment model for the Galaxy based on a
standalone setup and a single $AppEngine. You will begin by organizing the system objects using
the plant model created in the previous lab. Then, after creating the deployment model, you will
send the complete Galaxy to the runtime environment by deploying all objects.

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

System Platform - Part 1

2-18 Module 2 – Application Infrastructure

Summary Lab Instructions

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

Create the WinPlatform Object (page 2-18)

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

Create the AppEngine Object (page 2-18)

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

Create the Deployment Model (page 2-18)

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

Deploy the Objects (page 2-18)

f. Cascade deploy the GRPlatform.

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 4 – Creating the Deployment Model 2-19

Detailed Lab Instructions

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

Create the WinPlatform Object

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

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

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

System Platform - Part 1

2-20 Module 2 – Application Infrastructure

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

Note: Notice the color of the bottom right icon changes to yellow. This indicates the
object is the first Platform, and is therefore the GR Platform. By default, the first Instance of a
platform will be the GR platform and will use its Node name.

5. Name the new instance GRPlatform.

6. In the Model view, assign the GRPlatform instance to the ControlSystem area.

Wonderware Training
 Lab 4 – Creating the Deployment Model 2-21

Create the AppEngine Object

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

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

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

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

System Platform - Part 1

2-22 Module 2 – Application Infrastructure

11. Name the new instance AppEngine.

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

Wonderware Training
 Lab 4 – Creating the Deployment Model 2-23

Create the Deployment Model

13. Select the Deployment view.

14. Assign the AppEngine instance to the GRPlatform.

System Platform - Part 1

2-24 Module 2 – Application Infrastructure

15. Assign all remaining areas to the AppEngine instance.

Deploy the Objects

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

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

Wonderware Training
 Lab 4 – Creating the Deployment Model 2-25

17. Leave the default settings.

18. Click OK. This will display a second Deploy dialog box indicating the deployment progress.
As soon as the process is complete, the Close button is enabled.

19. Click Close to return to the ArchestrA IDE.

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

System Platform - Part 1

2-26 Module 2 – Application Infrastructure

– Intentionally left blank –

Wonderware Training
 Section 3 – The Runtime Environment 2-27

Section 3 – The Runtime Environment

Section Objectives
z Explain the concept of the Runtime Environment
z Illustrate the differences in the Development environment and the Runtime environment
z Explain the use of the Object Viewer in monitoring the Runtime environment

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

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

Object Viewer
The Object Viewer monitors the status of the objects and their attributes and can be used to
modify an attribute value for testing purposes.
To add an object to the Object Viewer Watch list, right-click the attribute from the Attribute Name
panel and select Add to Watch.
You can save a list of items being monitored. Once you have a list of attributes in the Watch
Window, you can select all or some of them and save them to an XML file by right-clicking on the
Watch window and selecting Save. A previously saved Watch window can also be loaded to
monitor previously saved attributes. You can also add a second Watch window that shows as a
separate tab in the bottom of the Viewer.

System Platform - Part 1

2-28 Module 2 – Application Infrastructure

Deployed Objects section

Objects deployed on the Platform.

Attributes section
Individual attributes of the object.

Attribute Monitoring section Location

for monitoring attribute activity.

Uploading Run-time Configuration

You can upload run-time configuration changes to the Galaxy database. This lets you keep any
attribute values that changed during run time.
The values of certain attributes can be set in the configuration environment, but they can also be
changed by the user at run time. As a result, the values of these attributes can differ between the
run-time and configuration environments.
For example. you create an object with a UDA myInteger. In the Object Editor, you specify an
initial value of 30.
Then you deploy the object. At run time, you write a new value to myInteger of 31. If you redeploy
this object, the original value of 30 overwrites any value assigned during run time.
If you want to upload run-time changes to the Galaxy, make sure the selected objects are:
z Not edited and checked in since last deployment or upload
z Not in Pending Update state
z Checked in
Objects whose configuration are successfully uploaded have a new version number and a change
log entry for the upload operation. The run-time object’s version number also has a new version
number. That version number matches the version in the configuration database.
If you select an object that is currently checked out to you, a warning appears during run-time
upload. If you continue, you lose all configuration changes you made to the checked out object.
The Galaxy performs an Undo Check Out operation on it before the run-time attributes are copied
to the Galaxy database.

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

To upload run-time changes to the Galaxy

Wonderware Training
 Section 3 – The Runtime Environment 2-29

a. Select one or more objects in the Model view or Deployment view. For example, you could
select an entire hierarchy from AppEngine down.
b. In the Object menu, click Upload Runtime Changes. The run-time attributes of the selected
objects are copied over those in the Galaxy database.

System Platform - Part 1

2-30 Module 2 – Application Infrastructure

– Intentionally left blank –

Wonderware Training
 Lab 5 – Using Object Viewer 2-31

Lab 5 – Using Object Viewer

Introduction
This lab illustrates the steps necessary to use Object Viewer to monitor live data from your
Galaxy’s runtime environment. Different watch windows are added to organize the attributes to be
monitored. The watch windows are then saved in a single file for future use.

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

System Platform - Part 1

2-32 Module 2 – Application Infrastructure

Summary Lab Instructions

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

Using ObjectViewer (page 2-33)

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

Instance Attribute Name

GRPlatform CPULoad
GRPlatform DiskSpaceFree[1]
GRPlatform RAMAvailableAvg

c. Create a new watch window called Engine Info and add the following attribute references:

Instance Attribute Name

AppEngine Scheduler.ScanPeriod
AppEngine ScanState
AppEngine ScanStateCmd

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 5 – Using Object Viewer 2-33

Detailed Lab Instructions

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

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

System Platform - Part 1

2-34 Module 2 – Application Infrastructure

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

Deployed Objects section.

Objects deployed on the Platform.

Attributes section.
Individual attributes of the object.

Attribute Monitoring section.

Location for monitoring attribute

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

Wonderware Training
 Lab 5 – Using Object Viewer 2-35

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

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

System Platform - Part 1

2-36 Module 2 – Application Infrastructure

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

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

Wonderware Training
 Lab 5 – Using Object Viewer 2-37

7. Repeat the previous step for the following attributes:

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

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

System Platform - Part 1

2-38 Module 2 – Application Infrastructure

9. Right-click in the new Watch List 1 and select Rename Tab to rename the default Watch List
1 tab.
10. The Rename Tab dialog box displays. Enter Engine Info for the Tab Name field and click OK.
11. On the Object List (left section of Object Viewer) select the AppEngine object to display its
attributes.

Wonderware Training
 Lab 5 – Using Object Viewer 2-39

12. On the Attribute List (right section of Object Viewer) locate the following attributes, right-
click on them, and select Add to Watch to add them to the watch list. You can also multiple-
select by holding the Ctrl key and clicking each one.
z Scheduler.ScanPeriod
z ScanState
z ScanStateCmd

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

System Platform - Part 1

2-40 Module 2 – Application Infrastructure

The Save As dialog box displays.

14. Navigate to the C:\Wonderware Training folder and enter My Watch Windows in the File
name field.

15. Click Save to save the watch list to the selected location.

Wonderware Training
 Section 4 – Connecting to the Field 2-41

Section 4 – Connecting to the Field

Section Objectives
z Become familiar with Device Integration Objects, I/O Server and Data Access Server
z Overview of DI Objects

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

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

Dynamic Data Exchange (DDE)

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

Note: NetDDE, an older protocol previously used for communication over the network to
Wonderware and non-Wonderware sources, is strongly discouraged and has been phased out by
Microsoft. SuiteLink is the recommended communication protocol for use with Wonderware
sources.

System Platform - Part 1

2-42 Module 2 – Application Infrastructure

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

DDE and SuiteLink I/O Addressing

DDE and SuiteLink identifies an element of data in an I/O data source program by using a three-
part naming convention that includes the application name, topic name and item name. To obtain
data from another application, the client program opens a communication channel to the server
program by specifying these three items. Additionally, if the communication channel is between
applications running in different computers, a node name must be specified too.
Node: Name of the computer the I/O data source program or service is running on.
Application: Name of the source program or service that provides I/O data to the client
application. This is the name of the executable file without the extension.
Topic: It's an application-specific sub-group of data elements.
Item: Name of the actual individual data point to be access once the communication channel
is opened.
For example, in the case of Excel as a server program, the application name is "Excel", the topic
name is the name of the specific spreadsheet that contains the data and the item name is the
identification of the cell on the spreadsheet to/from which the data is to be read/written.

Wonderware Training
 Section 4 – Connecting to the Field 2-43

OPC
OPC is open connectivity in industrial automation and the enterprise systems that support
industry. Interoperability is assured through the creation and maintenance of open standards
specifications.
The first standard (originally called simply the OPC Specification and now called the Data Access
Specification) resulted from the collaboration of a number of leading worldwide automation
suppliers working in cooperation with Microsoft. Originally based on Microsoft's OLE COM
(component object model) and DCOM (distributed component object model) technologies, the
specification defined a standard set of objects, interfaces and methods for use in process control
and manufacturing automation applications to facilitate interoperability. The COM/DCOM
technologies provided the framework for software products to be developed. There are now
hundreds of OPC Data Access servers and clients.
A typical analogy for needing the original Data Access Specification is printer drivers in DOS and
then in Windows. Under DOS the developer of each application had to also write a printer driver
for every printer. So AutoCAD wrote the AutoCAD application and the printer drivers. And
WordPerfect wrote the WordPerfect application and the printer drivers. They had to write a
separate printer driver for every printer they wanted to support: one for an Epson FX-80 and one
for the H-P LaserJet, and on and on. In the industrial automation world, one industrial device
manufacturer wrote their Human Machine Interface (HMI) software and a proprietary driver to each
industrial device (including every PLC brand). Another industrial device manufacturer wrote their
HMI and a proprietary driver to each industrial device (including every PLC brand, not just their
own).
Windows solved the printer driver problem by incorporating printer support into the operating
system. Now one printer driver served all the applications! And these were printer drivers that the
printer manufacturer wrote (not the application developer). Windows provided the infrastructure to
allow the industrial device driver's solution as well. Adding the OPC specification to Microsoft's
OLE technology in Windows allowed standardization. Now the industrial devices' manufacturers
could write the OPC DA Servers and the software (like HMIs) could become OPC Clients.
The resulting selfish benefit to the software suppliers was the ability to reduce their expenditures
for connectivity and focus them on the core features of the software. For the users, the benefit was
flexibility. They could now choose software suppliers based on features instead of "Do they have
the driver to my unique device?" They don't have to create a custom interface that they must bear
the full cost of creating and upgrading through operating system or device vendor changes. Users
were also assured of better quality connectivity as the OPC DA Specification codified the
connection mechanism and compliance testing. OPC interface products are built once and reused
many times; hence, they undergo continuous quality control and improvement.
The user's project cycle is shorter using standardized software components. And their cost is
lower. These benefits are real and tangible. Because the OPC standards are based in turn upon
computer industry standards, technical reliability is assured.
The original specification standardized the acquisition of process data. It was quickly realized that
communicating other types of data could benefit from standardization. Standards for Alarms &
Events, Historical Data, and Batch data were launched.

System Platform - Part 1

2-44 Module 2 – Application Infrastructure

Device Integration Objects

A DeviceIntegration object (DIObjects) is an AutomationObject that represents communication

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

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

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

There is a one-to-one relationship between an instance of the DDESuiteLinkClient object and a

running I/O Server. If you want to reference data points in more than one I/O Server, you must
configure and deploy more than one DDESuiteLinkClient object. For example, you would need to
configure one DDESuiteLinkClient object to communicate to an TCP I/O Server and another one
to talk to the GEHCS I/O Server.
When you configure the DDESuiteLinkClient object, you can specify one or more I/O Server topics
to which access is required. At run time, all items that the Galaxy application requires for a

Wonderware Training
 Section 4 – Connecting to the Field 2-45

specified topic are updated with the latest values from the I/O Server. The rate at which the values
are updated depends on how the topics were configured within the target I/O Server.
If you want to connect to a DDE I/O Server, specify login information that the DDESuiteLinkClient
object uses to connect to the I/O Server.
From other objects and from scripts, you can reference the topics you configured for the
DDESuiteLinkClient object. For example, you might configure the input source for a
FieldReference object to reference an item for one of the topics. Thus, the FieldReference object
input source is receiving data from an I/O Server through the DDESuiteLinkClient object.
To aid in rapid application development, you can create a list of topic items that appear in the
ArchestrA Attribute Browser. To do this, specify the item address and associate it with a user-
defined attribute name (alias). Creating the item list is not required in order to reference data from
the I/O Server.
The reference syntax for a DDESuiteLinkClient object data point is:
<objectname>.<topicname>.<itemname>
OR
<objectname>.<topicname>.<attributename>
The <objectname> is the name that you choose to give to the DDESuiteLinkClient object.
Each I/O topic for a DDESuiteLinkClient object is also known as a "scan group." Run-time object
attributes allow you to monitor errors related to the data quality for item values in a scan group.
InTouchProxy
The InTouchProxy Object is a gateway between Galaxy application objects and data that is
available through an InTouch application. The InTouchProxy object allows you to browse a
selected InTouch application tagname dictionary, add selected tags as attributes in the Galaxy
application, then read these attributes from the InTouch application at run time.

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

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

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

There is a one-to-one relationship between an instance of the InTouchProxy object and a running
InTouch node. An InTouch "node" is a unique combination of the computer name and InTouch
application. If you want to reference data points in more than one InTouch node, you must
configure and deploy more than one InTouchProxy object. For example, you would need to
configure one InTouchProxy object to get data from an InTouch application running on Computer1
and another one to get data from an InTouch application running on Computer2.
When you configure the InTouchProxy object, you might want to specify one or more existing
InTouch tagnames (items) to use as object attributes. At run time, if these attributes are added in
the client (for example, the Object Viewer watch window), they are updated with the latest values
from the InTouch items. InTouch sends a new data value for an item to the InTouchProxy object

System Platform - Part 1

2-46 Module 2 – Application Infrastructure

each time the value changes. Any items that you configure for an InTouchProxy object
automatically becomes available within the ArchestrA Attribute Browser.
From other objects and from scripts, you can reference the attributes you created for InTouch
items. For example, you might configure the input source for a FieldReference object to reference
one of these InTouchProxy object attributes. Thus, the FieldReference object's input source would
be receiving data from a tag in an InTouch node through the InTouchProxy object. The reference
syntax for an InTouchProxy object data point is:
<objectname>.<InTouchTagName>
The <objectname> is the name that you choose to give to the InTouchProxy object.
The group of specified InTouch items for an InTouchProxy object is also known as the "scan
group." Only one scan group exists in the InTouchProxy object. Run-time object attributes within
the scan group allow you to monitor errors related to the data quality for InTouch item values in a
scan group.
OPCClient
The OPCClient object is a key member of the core set of AutomationObjects within the ArchestrA
system infrastructure. The OPCClient object is a DeviceIntegration (DI) object that allows access
to a running OPC Data Access (DA) Server. A third-party OPC DA Server can provide data points
to Galaxy application objects through the OPCClient object.

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

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

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

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

Wonderware Training
 Section 4 – Connecting to the Field 2-47

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:
z Subscriptions, which are implemented via scan groups. Read transactions, which are
implemented via block reads (when available in the source DIObject). Write transactions,
which are implemented via block writes (when available in the source DIObject).

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

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

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

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

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

Time and Quality Propagation

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

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

System Platform - Part 1

2-48 Module 2 – Application Infrastructure

z Set the scan mode for each scan group that belongs to your device integration objects
within the Galaxy.

I/O Server
Different I/O data sources have different requirements. Two main groups are identified:
z Legacy I/O Server applications (SuiteLink, DDE, and OPC Servers) do not require a
platform on the node on which they run. They can reside on either a standalone or
workstation node.
However, the DI Objects used to communicate with those data sources such as the
DDESuiteLinkClient object, OPCClient object, and InTouchProxy objects must be
deployed to an AppEngine on a Platform. Although it is not required that these DI Objects
be installed on the same node as the data server(s) they communicate with, it is highly
recommended in order to optimize communication throughput.
z For Device Integration objects like CIP and TCP DINetwork objects, both the DAServer
and the corresponding DI Objects must reside on the same computer hosting an
AppEngine.
I/O Servers can run on Workstations, provided the requirements for visualization processing, data
processing, and I/O read-writes can be easily handled by the computer. Run the I/O Server and
the corresponding DI Object on the same node where most or all of the object instances (that
obtain data from that DI Object) are deployed.
This implementation expedites the data transfer between the two components (the I/O Server and
the object instance), since they both reside on the same node. This implementation also minimizes
network traffic and increases reliability.
However, it is good practice to evaluate the overhead necessary to run each

Data Access Server (DA Server)

DAServers, are designed to provide simultaneous connectivity between plant floor devices and
modern DDE, SuiteLink and/or OPC based client applications. DAServers support the OPC Data
Access 2.05 specification and offer additional features beyond the standard, including powerful
diagnostics and remote configuration capabilities. They offer enhanced communication
diagnostics and performance.
Each DAServer is designed to provide simultaneous connectivity between client applications
based on Wonderware SuiteLink, OPC and DDE protocols that run on Microsoft's Windows®
operating systems and the data devices supported by the specific protocol being translated.
Several standard features are available with each DA Server, including:
z Compliance with OPC version 2.05
z Stand-alone operation mode
z Support for hot configuration, device additions and device- and server-specific parameter
modifications
z A wide range of DA
Servers support connectivity to numerous protocols and products. Wonderware's current DA
Servers offering also includes support for:
z Allen-Bradley's CIP protocol for ControlLogix
z Allen-Bradley's TCP protocol
z Allen-Bradley's DH Plus protocol
z Siemens' Simatic Net S7

Wonderware Training
 Section 4 – Connecting to the Field 2-49

z Modbus® Serial protocol

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

System Platform - Part 1

2-50 Module 2 – Application Infrastructure

– Intentionally left blank –

Wonderware Training
 Lab 6 – Connecting to the Field 2-51

Lab 6 – Connecting to the Field

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

Objectives
Upon completion of this lab you will be able to:
z Create and configure a $DDESuiteLinkClient object to connect to an IO Server or DA
Server using SuiteLink as the communication protocol
z Monitor the connection status of the $DDESuiteLinkClient object on runtime

System Platform - Part 1

2-52 Module 2 – Application Infrastructure

Summary Lab Instructions

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

Create the Device Integration object (page 2-53)

a. Derived a new template from the $DDESuiteLinkClient object, name it
$tDDESuiteLinkClient, and assign it to the Training template toolset.
b. Create an instance of the $tDDESuiteLinkClient template and name it InControl.
c. Configure the General tab of the new instance as follows:
z Server node: <ask your instructor>
z Server name: RTEngine
z Communication protocol: SuiteLink
d. On the Topic tab, add a topic called tagname and import the InControl Items List.csv file
from the C:\Wonderware Training folder.
e. In Model view, assign the InControl instance to the ControlSystem area.

Deploy the Object (page 2-58)

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

Verify the Connection in Runtime (page 2-61)

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 6 – Connecting to the Field 2-53

Detailed Lab Instructions

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

Create the Device Integration object

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

3. Name the new template $tDDESuiteLinkClient.

4. Move the $tDDESuiteLinkClient object to your Training toolset.

System Platform - Part 1

2-54 Module 2 – Application Infrastructure

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

Configure the Instance

6. Double-click on the InControl instance to open its configuration editor.

7. In the General tab, configure the object as follows:

z Server node: <ask your instructor>. The following figure uses ‘TRAININGPC’ as an
example.
z Server name: RTEngine
z Communication protocol: SuiteLink

Wonderware Training
 Lab 6 – Connecting to the Field 2-55

8. Select the Topic tab.

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

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

The Open dialog box displays.

System Platform - Part 1

2-56 Module 2 – Application Infrastructure

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

12. Click the Open button.

Wonderware Training
 Lab 6 – Connecting to the Field 2-57

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

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

System Platform - Part 1

2-58 Module 2 – Application Infrastructure

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

16. Click the OK button.

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

Deploy the Object

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

Wonderware Training
 Lab 6 – Connecting to the Field 2-59

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

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

22. Leave the default settings and click the OK button.

This will display a second Deploy dialog box indicating the deployment progress.

System Platform - Part 1

2-60 Module 2 – Application Infrastructure

As soon as the process is complete, the Close button will enable.

23. Click the Close button to return to the ArchestrA IDE. The different views now display the
instance in its deployed state.

Wonderware Training
 Lab 6 – Connecting to the Field 2-61

Verify Connection in Runtime

24. In Model view, open Object Viewer by right-clicking the InControl instance and selecting
View in Object Viewer.

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

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

System Platform - Part 1

2-62 Module 2 – Application Infrastructure

30. Click OK.

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

Verify that the InControl.ConnectionStatus Value is Connected.

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

Wonderware Training
 Module 3

Application Objects
Section 1 – Templates and Instances 3-3
Section 2 – The $UserDefined Object 3-9
Lab 7 – Modeling the Heat Exchanger 3-11
Section 3 – Change Control and Propagation 3-25
Lab 8 – Configuring Change Control and Propagation 3-27
Section 4 – The $AnalogDevice Object 3-35
Lab 9 – Modeling a Meter 3-37
Section 5 – The $DiscreteDevice Object 3-41
Lab 10 – Modeling a Valve, Pump, and Motor 3-45
Section 6 – Containment 3-61
Lab 11 – Creating the Mixer 3-67
3-2 Module 3 – Application Objects

Module Objectives
Be able to
z Identify and work with templates
z Derive and configure templates

Wonderware Training
 Section 1 – Templates and Instances 3-3

Section 1 – Templates and Instances

Section Objectives
This section:
z Introduces you to the concept of templates and explain how to derive a template.

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

Templates
One of the major benefits of Application Server is that it allows you to re-use existing engineering.
Working with templates is the best way to illustrate such capability.
A template is an entity that represents the common functional requirements of a field device
(valves, pumps), a group of field devices (skids, stations), or a user function (algorithms). These
requirements reflect information such as number of Inputs and Outputs, alarm conditions, history
needs, and security. One object template performs the equivalent functions of multiple InTouch
tags and scripts.
A template is created either from a base template or from another derived template. Base
templates are the objects provided with the Application Server. Base templates cannot be
modified.

Note: You should avoid creating instances directly from base templates, since you will not be able
to take advantage of advanced configuration and maintenance capabilities.

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

System Platform - Part 1

3-4 Module 3 – Application Objects

Using the Diaphragm valve template, you can quickly create an Diaphragm valve instance when
you need another Diaphragm valve in your application.

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

Propagation
If you need to change something about all diaphragm valves, you can change the template for the
diaphragm valve and all diaphragm valves in your application inherit the changes, assuming the
attributes are locked in the parent template. This makes it easy to maintain and update your
application.

Wonderware Training
 Section 1 – Templates and Instances 3-5

Planning for Object Templates

The fourth step in the workflow is to determine the templates that you will need. A template is an
element that contains common configuration parameters for objects that are used multiple times
within a project. Templates are instantiated to represent specific objects within the application.
Both the templates and the instances created from them are called ApplicationObjects.
For example, you might need multiple instances of a valve within your application, so you would
create a valve template that has all of the required properties. This allows you to define once, and
reuse multiple times. If you change the template, the changes can be propagated to the instances.
You can use simple drag-and-drop within the ArchestrA IDE to create instances from templates.

Wonderware Application Server is shipped with a number of pre-defined templates to help you
create your application quickly and easily. Review these templates and determine if any of their
functionality match the requirements of the devices on your list. If not, you can create (derive) new
templates from the supplied UserDefined templates.

For your project planning, document which existing template can be used for which objects, and
what templates you will need to create yourself.
A child template that you derive from a parent template can be highly customized. You can
implement user-defined attributes (UDAs), scripting, and alarm and history extensions.

System Platform - Part 1

3-6 Module 3 – Application Objects

Note: You can use the Galaxy Dump and Load Utility to create a .CSV file, which you can then
modify using a text editor and load back into the galaxy repository. This allows you to make bulk
edits to the configuration quickly and easily.

Deriving a Template
Templates are either derived from Base Objects, existing templates or created within the
ObjectToolkit and imported.
Base templates cannot have their attributes configured. However, a template can be derived from
one of the base templates. That derived template can then be configured and customized for
attributes unique to the object it is modeling. Once that derived template is configured, instances of
it can be created. Each instance will have all the attributes of the derived template.
Upon derivation the new template is created within the default toolset. The new template is created
and placed into rename mode. The new template will inherit all attributes and associations of the
original template that were locked. If the default toolset does not exist then the system will create it
when the derived template is created. Creating a derived template is available from the Template
Toolbox and the Derivation view as well as by using keyboard shortcut keys.
When creating an instance of an object that object instance will need to be configured
independently. When deriving a template an instance of the template is created that takes on all of
the attributes of the template from which it was created. This propagation of objects of a like kind
can have a tremendous impact on the ability to create multiple instances of template derived
objects containing fully replicated attributes.

Wonderware Training
 Section 1 – Templates and Instances 3-7

Leveraging of Template Instances

To derive a Template from another one, do the following:
a. Select the Template in the ArchestrA IDE the new Template is to be derived from.
b. Right-click the selected Template and click Derived Template on the Create submenu of the
context menu. The new Template is created, placed in the same toolset as the original
Template, and set in rename mode.
c. Rename the derived Template.

Note: The new Template is created in the Galaxy in a checked in state. It can be viewed in the
Template Toolbox or in the Derivation View of the Application Views pane.

System Platform - Part 1

3-8 Module 3 – Application Objects

– Intentionally left blank –

Wonderware Training
 Section 2 – The $UserDefined Object 3-9

Section 2 – The $UserDefined Object

Section Objectives
This section:
z Introduces you to the $UserDefined object and its functionality.

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

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

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

The Analog Field Attribute supports the following data types:

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

System Platform - Part 1

3-10 Module 3 – Application Objects

The Discrete Field Attribute provides the enabling and configuration for the following functionality:
z State Labels
z History
z State Alarm
z Bad Value Alarm
z Statistics
The UserDefined object is an object that you can use to create customized objects. You can use
the UserDefined object as a template, or as a container.
As a template
Use the UserDefined object as a template containing Field Attributes associated to multiple
variables in a system. In this case, the object provides a simple and manageable structure as
all the variables are contained in the same object.
For example, you might create a UserDefined object called “Tank” and configure Field
Attributes that represent variables associated to the tank system:
z LT100 - Analog Field Attribute - Input from a level transmitter configured with options
such as: Scaling, Limit alarms and Statistics (Min/Max/Avg).
z TT100 - Analog Field Attribute - Input from a temperature transmitter configured with
options such as Rate of Change alarm and Statistics (Min/Max/Avg).
z SW100a - Discrete Field Attribute - Input from a limit switch configured with options
such as State Labels and State alarm.
z SW100b - Discrete Field Attribute - Input from a limit switch configured with options
such as State Labels and State alarm.
z XV100a - Discrete Field Attribute - InputOutput to a solenoid valve configured with
options such as State Labels, State alarm, and Statistics (Open/Close time).
z XV100b - Discrete Field Attribute - InputOutput to a solenoid valve configured with
options such as State Labels, State alarm, Statistics (Open/Close time).
References between attributes in the object can be accomplished by using relative reference,
for example:
The “Tank” can be customized to raise an alarm when both XV100a and XV100b valves are
open. For example, you can add a Boolean UDA called “ValueOpenAlarm”, extend it with an
Alarm Extension, and then add the following OnExecute script:
IF me.XV100a == "Open" AND me.XV100b == "Open" THEN
me.ValueOpenAlarm = true;
ELSE
me.ValueOpenAlarm = false;
ENDIF;
As a “container”
Use the UserDefined object as a “container” for other objects. An object relationship in which
one object is comprised of other objects is called containment. Containment allows you to
group various objects together to make complex objects.

Wonderware Training
 Lab 7 – Modeling the Heat Exchanger 3-11

Lab 7 – Modeling the Heat Exchanger

Introduction
In this lab the $UserDefined object is used to model the heat exchanger device identified in Lab 2.
The InControl object created in the previous lab provides the connection to the live values for the
four temperature transmitters within the heat exchanger.

Objectives
Upon completion of this lab you will be able to:
z Configure and use object templates to create instances that will inherit configurations
z Use the Field Attributes functionality provided by the $UserDefined object
z Use the Galaxy Browser to build references to instance attributes within the Galaxy

System Platform - Part 1

3-12 Module 3 – Application Objects

Summary Lab Instructions

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

Create the Heat Exchanger Template (page 3-13)

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

Access mode: Input

Data type: Float
Engineering units: Deg F
Enable I/O scaling: checked
Raw value - Maximum: 4095.0
EU value - Maximum: 250.0
EU range value - Minimum: -5.0
EU range value - Maximum: 255.0

Create a Heat Exchanger Instance (page 3-17)

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

Field Attribute Instance Attribute Name

T1 InControl tagname.HE1XX_TC1
T2 InControl tagname.HE1XX_TC2
T3 InControl tagname.HE1XX_TC3
T4 InControl tagname.HE1XX_TC4

Deploy the object (page 3-20)

e. Deploy the object.
View the Heat Exchanger Data in Runtime (page 3-23)
f. Open Object Viewer from within the ArchestrA IDE.
g. Using the watch list created in Lab 5, add a new watch window named HeatEx with the
following attributes from the HeatEx_001 instance:
z T1
z T2
z T3
z T4
h. Save the watch list.

Wonderware Training
 Lab 7 – Modeling the Heat Exchanger 3-13

See the next page for Detailed Lab Instructions

Detailed Lab Instructions

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

Create the Heat Exchanger Template

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

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

System Platform - Part 1

3-14 Module 3 – Application Objects

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

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

Wonderware Training
 Lab 7 – Modeling the Heat Exchanger 3-15

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

Name: T1
Access mode: Input
Data type: Float
Engineering units: Deg F
Enable I/O scaling: checked
Raw value: Maximum: 4095.0
EU value: Maximum: 250.0
EU range value: Minimum: -5.0
EU range value: Maximum: 255.0

System Platform - Part 1

3-16 Module 3 – Application Objects

8. Repeat steps 5 and 6 to add three more field attributes, using the same configuration as T1.
Name the attributes T2, T3 and T4.

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

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

11. Click OK.

12. Click the Close button.

Wonderware Training
 Lab 7 – Modeling the Heat Exchanger 3-17

Create a Heat Exchanger Instance

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

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

16. In the Inherited field attributes section, select the T1 attribute.

System Platform - Part 1

3-18 Module 3 – Application Objects

17. In the I/O section, click on the Input source ellipsis button to assign a reference using the
Galaxy Browser.

18. The Galaxy Browser window appears.

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

20. In the InControl panel (right) select tagname.HE1XX_TC1 where XX is your student number.
In this example, the student number is 00.

Wonderware Training
 Lab 7 – Modeling the Heat Exchanger 3-19

21. Click OK.

The Input source attribute contains the selected reference:

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

23. Click the Save and Close button .

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

25. Click OK.

System Platform - Part 1

3-20 Module 3 – Application Objects

Deploy the Object

Notice that the HeatEx_001 instance icon includes a orange square. This indicates the object is
not deployed.
26. Select the Deployment view, right-click the HeatEx_001 instance and select Deploy.

Wonderware Training
 Lab 7 – Modeling the Heat Exchanger 3-21

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

27. Click OK to accept the default settings.

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

28. Click Close when the deployment is complete.

System Platform - Part 1

3-22 Module 3 – Application Objects

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

Wonderware Training
 Lab 7 – Modeling the Heat Exchanger 3-23

View the Heat Exchanger Data in Runtime

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

31. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
Window to add a new tab to the watch list.
32. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the default Watch List 1 tab.
The Rename Tab dialog box is displayed.
33. Enter HeatEx for the Tab Name field and click OK.

System Platform - Part 1

3-24 Module 3 – Application Objects

34. In the Attribute List (right section of Object Viewer) locate the following attributes, right-click
on them, and select Add to Watch to add them to the watch list:
z T1
z T2
z T3
z T4

You will observe the attribute values changing in real time. The Quality attribute should reflect
Good data.
35. Right-click in the Watch List (bottom section of Object Viewer) and select Save to save the
watch list.

Wonderware Training
 Section 3 – Change Control and Propagation 3-25

Section 3 – Change Control and Propagation

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

This section presents the concept of attribute locking and provides an illustrations on how locking
attributes can propagate to previously derived instances.
Locking an attribute in a Template indicates that its value is to be logically “shared” with all derived
objects (Templates or instances). In other words, when the value changes in the template, that
change is propagated to all the derived children of the object. When an attribute is “locked” in the
Template, the value can be changed in that Template but not in any of the derived children.
Based on this concept, an attribute can have one of three logical lock types:

z Unlocked: Both Templates and instances can have these. Attribute is read-write. The
object has its own copy of the attribute value and is not shared by derived objects.

z Locked: Only Templates can have these. Attribute value is read-write. Derived objects
don’t have a unique copy of the attribute value, but instead share the locked one (it is
Locked In Parent – see next item). By changing the value of a locked attribute, the logical
value of that attribute is updated in all derived objects.

z Locked In Parent: Both Templates and instances can have these. Attribute is read-
only. The object does not have a unique copy of the attribute value, but references the one
in the ancestor in which the attribute is Locked.

Locking an Attribute

System Platform - Part 1

3-26 Module 3 – Application Objects

To lock a Template attribute, do the following:

a. Select the desired Template in the ArchestrA IDE and start its editor.
b. Enter a value in an attribute field in the object’s editor.
c. Select the locking mechanism for that attribute. Some editors may have lock icons associated
with certain edit fields, but this possibility is within the scope of the developer of the object’s
editor.
d. Save and close the object editor.
The locked attribute in any derived templates and instances created from this template are locked
and unavailable. To test this, you can derive a new template or create an instance from the original
template, and then check the new object’s editor. The locked attribute is unavailable for editing.

Unlocking an Attribute
To unlock a Template attribute, do the following:
a. Select the desired Template in the ArchestrA IDE and start its editor.
b. Select the locking mechanism for the locked attribute in the object’s editor. Some editors may
have lock icons associated with certain edit fields, but this possibility is within the scope of the
developer of the object’s editor.
c. Save and close the object editor.
The previously locked attribute in any instances created from this template are now unlocked. The
previously locked attribute in any templates derived from this template are still Locked (in me). The
previously locked attribute in any instances of derived templates remain in Locked in Parent.

Wonderware Training
 Lab 8 – Configuring Change Control and Propagation 3-27

Lab 8 – Configuring Change Control and

Propagation
Introduction
This lab illustrates how to modify the template for the heat exchanger to change the engineering
units from ‘Deg F’ to ‘Celsius’, locking the attribute so the changes are propagated to the existing
instance. It also illustrates that by locking the scaling configuration of the object it cannot be
changed on derived objects.

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

System Platform - Part 1

3-28 Module 3 – Application Objects

Summary Lab Instructions

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

Lock the Attributes (page 3-29)

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

Engineering units: ‘Celsius’ and locked

Scaling section: locked

Verify the Changes to the Existing Instance (page 3-31)

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

Redeploy the Object (page 3-32)

c. Redeploy the object.

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 8 – Configuring Change Control and Propagation 3-29

Detailed Lab Instructions

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

Lock the Attributes

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

System Platform - Part 1

3-30 Module 3 – Application Objects

2. In the Field attributes section, select the T1 attribute and change the configuration as follows:
Engineering units: ‘Celsius’ and locked
Scaling section: locked

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

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

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

Wonderware Training
 Lab 8 – Configuring Change Control and Propagation 3-31

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

Verify the Changes to the Existing Instance

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

System Platform - Part 1

3-32 Module 3 – Application Objects

7. Save and Close the editor.

Redeploy the Object

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

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

9. Leave the default settings and click OK.

Wonderware Training
 Lab 8 – Configuring Change Control and Propagation 3-33

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

10. Click Close.

System Platform - Part 1

3-34 Module 3 – Application Objects

– Intentionally left blank –

Wonderware Training
 Section 4 – The $AnalogDevice Object 3-35

Section 4 – The $AnalogDevice Object

Section Objectives
This section:
z Introduces you to the concept of the $AnalogDevice object and its functionality.

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

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

AnalogDevice Object as a Basic Analog Input/Output Object

When configured as a basic analog device, this object provides a means for reading and optionally
writing analog signals from the field or from another object. The basic I/O characteristics are:
z The process value (PV) is read from the field (except when the AnalogDevice object is
configured to be in Manual mode).
z You can configure the AnalogDevice object to enable or disable analog output. If you
enable output, you can configure the output destination address to be the same (default)
or different from the input source address. Commands to change the PV will result in an
output to field. For data integrity, the value of PV represents the value read from the
external controller (except when the AnalogDevice object is in Manual mode), not the
requested PV that is output to the external controller.
z The input and outputs can be optionally scaled between raw counts and engineering unit
values using either linear or square-root conversions.
The AnalogDevice object supports alarming for PV conditions, such as when the PV:
z Exceeds level limits, such as Lo, Hi, LoLo, and HiHi.
z Exceeds rate-of-change limits, for both positive and negative directions.
z Exceeds major and minor deviations from a target value.
z Has a quality value of BAD.
In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV
value. If you enable the PV override, then you can use the PV.Mode attribute to place the
AnalogDevice object into either Auto or Manual mode. When the AnalogDevice object is in Auto
mode, the PV is updated from the field and matches the value and quality of the PVAuto attribute.
When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated
from the field, but the PV value does not. Instead, the PV can be set by a user write or a script, and
the quality is always set to UNCERTAIN.
Finally, you can configure the AnalogDevice object to historize key variables, including PV and
PV.Mode.

System Platform - Part 1

3-36 Module 3 – Application Objects

AnalogDevice Object as an Analog Regulator Object

When configured as an analog regulator device, the AnalogDevice object provides a means for
reading and optionally writing two separate analog signals from the field or from another object:
one PV value and one setpoint (SP) value. The basic I/O characteristics are:
z The process value (PV) is read from the field (except when the AnalogDevice object is
configured to be in Manual mode), but is never written.
z The SP value is both read from the field and written to the field. You can configure the SP
output destination address to be the same (default) or different from the input source
address. Commands to change SP result in an output to field. For data integrity, the value
of SP always represents the value read from the external controller, not the requested SP
that is output to the external controller.
z The PV and SP can be optionally scaled between raw counts and engineering unit values
using either linear or square-root conversions.
The AnalogDevice object supports alarming for PV conditions, including when the PV:
z Exceeds level limits, such as Lo, Hi, LoLo, and HiHi.
z Exceeds rate-of-change limits, for both positive and negative directions.
z Exceeds major and minor deviations from the SP value.
z Has a quality value of BAD.
In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV
value. If you enable the PV override, then you can use the PV.Mode attribute to place the
AnalogDevice object into either Auto or Manual mode. When the AnalogDevice object is in Auto
mode, the PV is updated from the field and matches the value and quality of the PVAuto attribute.
When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated
from the field, but the PV value does not. Instead, the PV can be set by a user write or a script, and
the quality is always set to UNCERTAIN.
Other controller-oriented features that can be configured for an AnalogDevice object of type
analog regulator include:
z Controller mode (CtrlMode attribute). You can use the controller mode to govern what
types of writes are allowed to the SP value within the system. Controller mode options are
Manual, Cascade, and None. When the object is in Manual mode, only end users are
allowed to command a change in the value of SP. In Cascade mode, only scripts or other
supervisory objects are allowed to command a change to SP. Finally, if None is specified
for the controller mode, any type of write is allowed for the SP.
z Control tracking. A Boolean control track flag can be read from an external device or
object. When tracking is on, the external controller "owns" the value of the SP; the SP is
purely read-only and cannot be commanded to be changed and output to the field.

Wonderware Training
 Lab 9 – Modeling a Meter 3-37

Lab 9 – Modeling a Meter

Introduction
This lab illustrates how to use the $AnalogDevice object to model a meter template which will be
used later to create the objects for the mixer level and temperature transmitters identified in Lab 2.
The template created in this lab will be integrated later with other templates to form the mixer
object; because of this, no instances will be created yet for this object.

Objectives
Upon completion of this lab you will be able to:
z Configure an $AnalogDevice object

System Platform - Part 1

3-38 Module 3 – Application Objects

Summary Lab Instructions

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

Create the Meter Template (page 3-39)

a. Derived a new template from the $AnalogDevice object, name it $Meter, and assign it to the
Training template toolset.
b. Configure the object as follows:

Type: Analog (locked)

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 9 – Modeling a Meter 3-39

Detailed Lab Instructions

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

Create the Meter Template

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

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

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

System Platform - Part 1

3-40 Module 3 – Application Objects

4. Configure the General tab as follows:

Type: Analog (locked)

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

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

Wonderware Training
 Section 5 – The $DiscreteDevice Object 3-41

Section 5 – The $DiscreteDevice Object

Section Objectives
This section:
z Introduces you to the concept of the $DiscreteDevice object and its functionality.

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

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

DiscreteDevice Object States

The DiscreteDevice object has two key attributes that represent the current state (PV) and the
commanded state (Cmd). Both of these are enumerations. The DiscreteDevice object can have up
to five states that can be configured with state names that are appropriate to the equipment being
monitored. The actual meanings of the states are dependent on the equipment:
z Passive
The passive state represents the state of the discrete device when it is idle, stopped, or
closed (the typical non-running position). For example, the passive state for a motor might
be "Off."
z First Active
The first active state (Active1) represents the state of the discrete device when it is
considered to be running. For example, the active state for a motor might be "Forward."
You can use outputs to control the first active state.

System Platform - Part 1

3-42 Module 3 – Application Objects

z Second Active
(Optional) Some discrete devices have more than one active state. For example, a motor
might have a second active state of "Backward." You can use outputs to control the
second active state (Active2).
z Transition
(Optional) The discrete device is in a transition state any time it is changing from one valid
state to another. For example, if you have a valve with a passive state of "Off" and an
active state of "On," the transition state might be "Moving."
z Fault
The fault state occurs when the feedback that is coming from the field is incorrect or
impossible based on how the discrete device works. For example, a fault would occur if
the Hi and Lo limit is being reached at the same time for a single device. Examples of fault
state names are "Error," "Bad," or "Broken."

Monitoring a Discrete Device through Inputs

If you configure the DiscreteDevice object to have inputs (feedback) from the field, the input values
are used to update the overall state of the device. A DiscreteDevice object can have up to four
inputs. After defining the inputs, map the different input combinations to the possible states for the
device.
For example, you might have a valve on your discrete device that can be either opened or closed.
You have defined the passive state of the device as Closed, the first active state as Opened, and
the fault state as Bad. You would then create references for two field inputs: one for the open
position (Valve_Open), and one for the closed position (Valve_Close). You then would map the
inputs to the defined states. For example:
Valve_Open Valve_Close Mapped State
0 0 Transition
0 1 Closed
1 0 Opened
1 1 Bad
where:
1=TRUE
0=FALSE

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

Wonderware Training
 Section 5 – The $DiscreteDevice Object 3-43

z When the object is in Simulate mode, the PV value is set equal to the Cmd value, rather
than read from the field.

Controlling a Discrete Device through Outputs

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

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

Statistical Features
The DiscreteDevice object offers advanced built-in state tracking calculations that can be used for
equipment monitoring and time-in-use tracking, including:
z The most recent time durations of the Active1, Active2 and Passive states.
z The total accumulated time durations of the Active1, Active2 and Passive states, with
optional alarming on the Active1 and Active2 total durations.
z The number of transitions into the Active1, Active2 and Passive states.
z A commandable reset of all statistics.

System Platform - Part 1

3-44 Module 3 – Application Objects

– Intentionally left blank –

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-45

Lab 10 – Modeling a Valve, Pump, and Motor

Introduction
This lab illustrates how to use the $DiscreteDevice object to model a valve, a pump and a motor
template which will be used later to create the mixer’s inlet and outlet valves, as well as the
transfer pumps and agitator identified in Lab 2.
Initially, the templates for the pump and the motor are quite similar. Later, you will extend the
motor template to handle the speed associated with the mixer’s agitator.
The templates to be created in this lab will be integrated later with other templates to form the
mixer object; because of this, no instances will be created for these objects at this time.

Objectives
Upon completion of this lab you will be able to:
z Configure a $DiscreteDevice object

System Platform - Part 1

3-46 Module 3 – Application Objects

Summary Lab Instructions

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

Create the Valve Template (page 3-49)

a. Derive a new template from the $DiscreteDevice object, name it $Valve, and assign it to the
Training template toolset.
b. Configure the object’s General tab as follows:

Enable inputs: Checked (locked)

Enable outputs: Checked (locked)

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

Enable second active state: Unchecked (locked)

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

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

Number of Inputs: 2 (locked)

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

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

Number of outputs: 1 (locked)

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

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-47

Create the Pump Template (page 3-52)

f. Derived a new template from the $DiscreteDevice object, name it $Pump, and assign it to the
Training template toolset.
g. Configure the object’s General tab as follows:

Enable inputs: Checked (locked)

Enable outputs: Checked (locked)

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

Enable second active state: Unchecked (locked)

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

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

Number of Inputs: 1 (locked)

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

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

Number of outputs: 1 (locked)

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

System Platform - Part 1

3-48 Module 3 – Application Objects

Create the Motor Template (page 3-57)

k. Derived a new template from the $DiscreteDevice object, name it $Motor, and assign it to the
Training template toolset.
l. Configure the object’s General tab as follows:

Enable inputs: Checked (locked)

Enable outputs: Checked (locked)

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

Enable second active state: Unchecked (locked)

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

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

Number of Inputs: 1 (locked)

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

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

Number of outputs: 1 (locked)

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-49

Detailed Lab Instructions

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

Create the Valve Template

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

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

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

System Platform - Part 1

3-50 Module 3 – Application Objects

6. Configure the States tab as follows:

Enable second active state: Unchecked (locked)

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

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-51

7. Configure the Inputs tab as follows:

Number of Inputs: 2 (locked)

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

System Platform - Part 1

3-52 Module 3 – Application Objects

8. Configure the Outputs tab as follows:

Number of outputs: 1 (locked)

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

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

Create the Pump Template

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

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-53

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

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

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

System Platform - Part 1

3-54 Module 3 – Application Objects

14. Configure the States tab as follows:

Enable second active state: Unchecked (locked)

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

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-55

15. Configure the Inputs tab as follows:

Number of Inputs: 1 (locked)

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

System Platform - Part 1

3-56 Module 3 – Application Objects

16. Configure the Outputs tab as follows:

Number of outputs: 1 (locked)

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

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

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-57

Create the Motor Template

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

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

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

System Platform - Part 1

3-58 Module 3 – Application Objects

22. Configure the States tab as follows:

Enable second active state: Unchecked (locked)

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

Wonderware Training
 Lab 10 – Modeling a Valve, Pump, and Motor 3-59

23. Configure the Inputs tab as follows:

Number of Inputs: 1 (locked)

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

System Platform - Part 1

3-60 Module 3 – Application Objects

24. Configure the Outputs tab as follows:

Number of outputs: 1 (locked)

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

25. Click the Save and Close button and check in the $Motor template.

Wonderware Training
 Section 6 – Containment 3-61

Section 6 – Containment

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

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

Creating Contained Templates

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

Name Description
Tagname The unique name of the individual object. For example, Valve1.
Contained Name The name of the object within the context of its container object. For
example, the object whose Tagname is Valve1 may also be referred to
as Tank1.Outlet, if Tank1 contains it and it has the contained name
"Outlet".
Hierarchical Name Hierarchical names that are fully-qualified names of a contained object
include the name of the objects that contain it.
Since the object that contains it may also be contained, there are
potentially multiple hierarchical names that refer to the same object.
For example, if:
“Reactor1” contains Tank1 (also known within Reactor1 by its contained
name “SurgeTank”).
"Tank1" contains Valve1 (also known within Tank1 by its contained
name "Outlet").
Valve1 could be referred to as:
"Valve1"
"Tank1.Outlet"
"Reactor1.SurgeTank.Outlet".

System Platform - Part 1

3-62 Module 3 – Application Objects

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

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

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

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

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

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

Wonderware Training
 Section 6 – Containment 3-63

An example of a containment hierarchy is a tank that contains the following objects:

z Inlet Valve
z Agitator
z Outlet Valve
z Level

System Platform - Part 1

3-64 Module 3 – Application Objects

To enable referencing and flexibility within scripting, these objects can be referenced in several
different ways. Each object has a unique Tagname, such as:
z Inlet Valve = InletValve01
z Agitator = Agitator01
z Outlet Valve = OutletValve01
z Level = Level01

Wonderware Training
 Section 6 – Containment 3-65

Within the context of each hierarchy, the contained names are unique, in that the names only refer
to this tank system and the contained objects.
So if the tank is named Tank01, the contained names are:
z Tank01.Inlet
z Tank01.Agitator
z Tank01.Outlet
z Tank01.Level

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

z Me.Outlet: Allows a script running within the parent object to generically reference its child
outlet instance.
z MyContainer.Inlet: Allows a script running in any of the children instances to reference
another child instance named Inlet that belongs to the same parent.

System Platform - Part 1

3-66 Module 3 – Application Objects

Renaming Contained Objects

Before you rename a contained name of an object, make sure that the object is not checked out to
another user or currently deployed.
The new contained name must comply with naming restrictions. Template names can be up to 32
alphanumeric or special characters, including the required $ as the first character. The second
character cannot be $ and the name must include at least one letter. You cannot use spaces.
Contained names also cannot be the same contained name as an existing contained object within
the same level of hierarchy in the containment relationship.

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

To rename an object's contained name

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

Containment and the Derivation View

The Derivation View does not show containment relationships. It shows templates and instances
with regard to containment in the follow ways:
z Non-contained instances show their tagnames.
z Contained instances show their tagnames and hierarchical names.
z Non-contained templates show their object name.
z 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.

Wonderware Training
 Lab 11 – Creating the Mixer 3-67

Lab 11 – Creating the Mixer

Introduction
This lab uses the templates created in Labs 9 and 10 to create dedicated templates for each of the
Mixer’s components identified in Lab 2. Using the $UserDefined template to create a template for
the mixer itself, you will use object containment to integrate all the pieces together and build the
“mixer system”.
The InControl object created in Lab 6 provides the connection to the live values for each of the
objects that are part of the mixer.

Objectives
Upon completion of this lab you will be able to:
z Create and configure a containment relationship between objects.

System Platform - Part 1

3-68 Module 3 – Application Objects

Summary Lab Instructions

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

Create the Mixer Template (page 3-71)

a. Derived a new template from the $UserDefined object, name it $Mixer, and assign it to the
Training template toolset.
Create the Mixer’s Valves Templates (page 3-71)
b. Derived three new templates from the $Valve object, name them $Inlet1, $Inlet2 and $Outlet,
and assign them to the $Mixer template.
Create the Mixer’s Pumps and Agitator templates (page 3-77)
c. Derived two new templates from the $Pump object, name them $Pump1 and $Pump2, and
assign them to the $Mixer template.
d. Derived a new template from the $Motor object, name it $Agitator, and assign it to the
$Mixer template.
Create the Level and Temperature Meter Templates (page 3-73)
e. Derived a new template from the $Meter object, name it $LIT, and assign it to the $Mixer
template. Configure the object as follows:

Engineering units: Liters (locked)

EU value Minimum: 0.0 (locked)
EU value Maximum: 100.0 (locked)
EU range value Minimum: -5.0 (locked)
EU range value Maximum: 105.0 (locked)

f. Derived a new template from the $Meter object, name it $TT, and assign it to the $Mixer
template. Configure the object as follows:

Engineering units: Celsius (locked)

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

Create a Mixer Instance (page 3-77)

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-69

h. Configure the input and output references for the contained objects as follows
where XX is your student number.
For Agitator_001
AuxContact.InputSource: InControl. tagname.T1XX_AG_AuxContact
CmdStart.OutputDestination: InControl tagname.T1XX_AG_CmdStart

For Inlet1_001
CLS.InputSource: InControl tagname.T1XX_IV1_CLS
OLS.InputSource: InControl tagname.T1XX_IV1_OLS
CmdOpen.OutputDestination: InControl tagname.T1XX_IV1_CmdOpen

For Inlet2_001
CLS.InputSource: InControl tagname.T1XX_IV2_CLS
OLS.InputSource: InControl tagname.T1XX_IV2_OLS
CmdOpen.OutputDestination: InControl tagname.T1XX_IV2_CmdOpen

:
For LIT_001
PV.Input.InputSource: InControl tagname.T1XX_LT_PV

For Outlet_001
CLS.InputSource: InControl tagname.T1XX_OV_CLS
OLS.InputSource: InControl tagname.T1XX_OV_OLS
CmdOpen.OutputDestination: InControl tagname.T1XX_OV_CmdOpen

For Pump1_001
FlowSwitch.InputSource: InControl tagname.T1XX_TP1_FlowSwitch
CmdStart.OutputDestination: InControl tagname.T1XX_TP1_CmdStart

For Pump2_001
FlowSwitch.InputSource: InControl tagname.T1XX_TP2_FlowSwitch
CmdStart.OutputDestination: InControl tagname.T1XX_TP2_CmdStart

For TT_001
PV.Input.InputSource: InControl tagname.T1XX_TT_PV

i. Deploy the object.

System Platform - Part 1

3-70 Module 3 – Application Objects

View the Mixer Data in Runtime (page 3-93)

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

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

k. Save the watch list.

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 11 – Creating the Mixer 3-71

Detailed Lab Instructions

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

Create the Mixer Template

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

Create the Mixer’s Valves Templates

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

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

System Platform - Part 1

3-72 Module 3 – Application Objects

8. Name the new template $Inlet2.

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

The Training template toolbox should now look like the following:

Create the Mixer’s Pumps and Agitator templates

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

The Training template toolbox should now look like the following:

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-73

The Training template toolbox should now look like the following:

Create the Level and Temperature Meter Templates

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

The Training template toolbox should now look like the following:

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

System Platform - Part 1

3-74 Module 3 – Application Objects

16. Configure the General tab as follows:

Engineering units: Liters (locked)

EU value Minimum: 0.0 (locked)
EU value Maximum: 100.0 (locked)
EU range value Minimum: -5.0 (locked)
EU range value Maximum: 105.0 (locked)

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-75

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

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

System Platform - Part 1

3-76 Module 3 – Application Objects

20. Configure the General tab as follows:

Engineering units: Celsius (locked)

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

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-77

Create a Mixer Instance

22. Using the Template Toolbox and the Model view, create an instance of the $Mixer template
using the default name of Mixer_001.

23. Assign the instance to the Line1 area.

System Platform - Part 1

3-78 Module 3 – Application Objects

Configure the Agitator

24. Double-click the Agitator_001 instance.

The Agitator_001 configuration editor appears.

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-79

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

28. Click OK.

29. Select the Outputs tab.
30. Click the ellipsis to configure the Output Destination Reference.
31. From the InControl Instance, select the tagname.T1XX_AG_CmdStart attribute, where XX is
your student number.
32. Click OK.

System Platform - Part 1

3-80 Module 3 – Application Objects

The attribute reference appears in the Output Destination Reference:

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-81

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

Input Name Instance Attribute

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

System Platform - Part 1

3-82 Module 3 – Application Objects

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

Output Name Instance Attribute

Output 1: CmdOpen InControl tagname.T1XX_IV1_CmdOpen

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-83

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

Input Name Instance Attribute

Input 2 : CLS InControl tagname.T1XX_IV2_CLS
Input 1: OLS InControl tagname.T1XX_IV2_OLS

System Platform - Part 1

3-84 Module 3 – Application Objects

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

Output Name Instance Attribute

Output 1: CmdOpen InControl tagname.T1XX_IV2_CmdOpen

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-85

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

Instance Attribute
InControl tagname.T1XX_LT_PV

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

System Platform - Part 1

3-86 Module 3 – Application Objects

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

Input Name Instance Attribute

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-87

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

Output Name Instance Attribute

Output 1: CmdOpen InControl tagname.T1XX_OV_CmdOpen

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

System Platform - Part 1

3-88 Module 3 – Application Objects

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

Input Name Instance Attribute

Input 1: FlowSwitch InControl tagname.T1XX_TP1_FlowSwitch

Wonderware Training
 Lab 11 – Creating the Mixer 3-89

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

Output Name Instance Attribute

Output 1: CmdStart InControl tagname.T1XX_TP1_CmdStart

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

System Platform - Part 1

3-90 Module 3 – Application Objects

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

Input Name Instance Attribute

Input 1: FlowSwitch InControl tagname.T1XX_TP2_FlowSwitch

Wonderware Training
 Lab 11 – Creating the Mixer 3-91

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

Output Name Instance Attribute

Output 1: CmdStart InControl tagname.T1XX_TP2_CmdStart

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

System Platform - Part 1

3-92 Module 3 – Application Objects

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

Instance Attribute
InControl tagname.T1XX_TT_PV

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

Deploy the Object

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

61. Leave the default settings and click OK.

Wonderware Training
 Lab 11 – Creating the Mixer 3-93

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

62. Click Close.

View the Mixer Data in Runtime

63. Right-click on the Mixer_001 instance and select View in Object Viewer. If you closed Object
Viewer before, you can use File / Load Watch List to open the file you saved earlier.
64. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
Window to add a new tab to the watch list.
65. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the watch list to Mixer.

System Platform - Part 1

3-94 Module 3 – Application Objects

66. Using the Object List (left section of Object Viewer) and the Attribute List (right section of
Object Viewer), locate and add the following attributes to the selected watch list by right-
clicking on each attribute and selecting Add to Watch:

Object List Attribute List

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

Wonderware Training
 Lab 11 – Creating the Mixer 3-95

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

System Platform - Part 1

3-96 Module 3 – Application Objects

– Intentionally left blank –

Wonderware Training
 Module 4

Extending the Objects

Section 1 – UDAs 4-3
Section 2 – Extensions 4-7
Lab 12 – Configuring the Motor Speed 4-11
Section 3 – Introduction to QuickScript .NET 4-21
Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient 4-43
Lab 14 – Configuring Automatic Reference 4-51
4-2 Module 4 – Extending the Objects

Module Objectives
z Be able to work with extending the objects and configuring them for additional
functionality.

Wonderware Training
 Section 1 – UDAs 4-3

Section 1 – UDAs

Section Objective
This section introduces and explains UDAs and how they are configured and used.

This section introduces and explains UDAs and how they are configured and used.

User Defined Attributes (UDAs)

UDAs (User Defined Attributes) are part of the ApplicationObject script environment. They allow
users to not only add logic to an existing ApplicationObject but also to expose new behavior via
added (user defined) attributes. More specifically, they allow users to:
z Add a new attribute to an object
z Configure its data type
z Specify the attribute category
z Set initial values and locks on the new attribute
z Set whether the new attribute is an array and how many elements comprise it
z Set alarms and historization for the new attribute (done on the Extensions page)
z Define security and references to other objects (done on the Extensions page)

Note: After you add an attribute to an instance, it appears in the Attribute Browser list for use with
the scripting and attribute extension functions.

Put to the extreme, scripts and UDAs can be used to create a completely new type of
ApplicationObject starting from an empty container object that has no behavior / logic itself.
You can add UDAs to a template or an instance. When you add a UDA to a template, the UDA, its
data type, and category are automatically locked in the child instances.
If UDA parameters such as initial values and security classifications are locked in the template,
they cannot be changed in child instances. If these parameters are unlocked in the template, the
initial value and security are editable and lockable in derived templates. When unlocked in either
the base or derived template, the value is editable in instances.
After you add an attribute to an instance, it appears in the Attribute Browser list for use with the
scripting and attribute extension functions.

System Platform - Part 1

4-4 Module 4 – Extending the Objects

The UDAs page is comprised of three main functional areas and a set of function buttons. These
are described below.

UDAs Name List

Data Type Group

Inherited UDAs
Name List

The main areas of the UDAs page include:

z UDAs list: Lists all UDAs currently associated with the object. Click the Add button to add
a new UDA.
z Inherited UDAs list: Lists all UDAs associated with the object's parent. The object
automatically includes these UDAs. They can only be edited by modifying the parent
template.
z Data type list: Shows the data type options for configuring the selected UDA.
Select from the data types Boolean, Integer, Float, Double, String, Time, ElapsedTime or
InternationalizedString.
Allowed categories are Calculated, Calculated retentive, Object writable and User writeable.
You can lock writable attributes. If you select Calculated for an attribute, only scripts running on the
same object can write to the attribute.
You can create an array for each data type except InternationalizedString. Select This is an
array and specify the array's length in the Number of elements box.
The Value parameter specifies the initial setting for the attribute when the object is deployed. Enter
value data for each data type. In the case of a non-arrayed Boolean, select the True/False check
box to use a True value. Clear the check box to use a False value. For an arrayed Boolean, select
the desired element and provide a default value by typing either true or false.

Wonderware Training
 Section 1 – UDAs 4-5

When using UDAs in scripting, note the following:

z When using Calculated and Calculated Retentive UDAs as counters, they must be
manually initialized. For instance, if you use me.UDA=me.UDA+1 as a counter in a script,
you must also initialize the UDA with something like me.UDA=1 or me.UDA=<some
attribute value>.
z Calculated UDAs can be initialized in OnScan and Execute scripts (that is, scripts with
those types of Execution Type triggers), but not Startup scripts.
z Calculated Retentive UDAs must be initialized in Startup scripts, and can be initialized in
OnScan and Execute scripts. The main purpose of a Calculated Retentive UDA is to
retain the attribute's current value after a computer reboot, redundancy-related failover, or
similar occurrence in which valid checkpoint data is present. Therefore, your Startup script
should contain a statement testing the Boolean value of the attribute,
StartingFromCheckpoint, on the object's AppEngine. If the value is TRUE, you should not
initialize the UDA; if the value is FALSE, you should initialize the UDA.

System Platform - Part 1

4-6 Module 4 – Extending the Objects

– Intentionally left blank –

Wonderware Training
 Section 2 – Extensions 4-7

Section 2 – Extensions

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

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

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

InputOutput
Extension Group

Input
Extension Group

Output
Extension Group

Alarm
Extension Group

History
Extension Group

Extendable Attributes list

Boolean Label
Extension Group

The main functional areas of the Extensions page include:

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

System Platform - Part 1

4-8 Module 4 – Extending the Objects

attribute's value and quality, and updates the extended attribute's value and quality every
scan. Changes read from the source are not written back to the Destination attribute.
z Input Extension Group: Use to configure an attribute to be a reference source for
another object. In other words, the extended attribute acquires the update value of the
Source attribute.
z Output Extension Group: Use to configure an attribute to be writeable to an external
object's attribute. In other words, when the value or quality (from Bad or Initializing to
Good or Uncertain) of the extended attribute is modified, the value of the Destination
attribute is updated.
z Alarm Extension Group: Use to create an alarm condition when a Boolean attribute's
value is set to TRUE.
z History Extension Group: Use to historize the value of an attribute that does not already
have history capabilities.
z Boolean Label Extension: Specify custom text strings for the False state and the True
state. These custom text strings appear in the Active alarm state list in the Alarm
extension area for you to select. If you are using the InTouch HMI, you can see these
custom text strings in InTouch.
To create and associate an extension with an object
1. On the Extensions page of the object's editor, select an attribute in the Extendable Attributes
List. The four extension groups dynamically change according to allowed extension rules for
the selected attribute type.
2. Select the check box of the kind of extension you want to apply to the selected attribute. The
associated parameters for each kind of extension are then made available.
3. For InputOutput Extension, enter a Source attribute by either typing in the reference string or
clicking the attribute browser button at right. Use the Attribute Browser dialog box to search
for the desired reference string in an object. Then if Destination is different from Source, click
Output Destination Differs from Input Source, and enter a Destination attribute by either
typing in the reference string or clicking the attribute browser button. An X is placed in the
InputOutput column of the selected attribute.
Caution! If you clear the Output Destination Differs from Input Source check box, the
content of the Destination box automatically becomes "---". In the run-time environment, "---"
is interpreted as the same reference as the Source value entered during configuration time. In
the run-time, you can change the Source reference. Therefore, during configuration, do not
lock the Destination parameter if you clear the Output Destination Differs from Input
Source check box.
4. For Input Extension, enter a Source attribute by either typing in the reference string or
clicking the attribute browser button at right. Use the Attribute Browser dialog box to search
for the desired reference string in an object. An X is placed in the Input column of the selected
attribute.
5. For Output Extension, enter a Destination attribute by either typing in the reference string or
clicking the attribute browser button at right. Use the Attribute Browser dialog box to search
for the desired reference string in an object. Select the Output Every Scan check box if you
want the extended attribute to write to the Destination attribute every scan period of the
object (otherwise, the write executes only when the value is modified or when quality changes
from Bad or Initializing to Good or Uncertain). An X is placed in the Output column of the
selected attribute.
6. For Alarm Extension, select a Category from the list: Discrete, Value LoLo, Value Lo,
Value Hi, Value HiHi, DeviationMinor, DeviationMajor, ROC Lo, ROC Hi, SPC, Process,

Wonderware Training
 Section 2 – Extensions 4-9

System, Batch or Software. Type a Priority level for the alarm (default is 500). Also, choose
between Use Object Description for Alarm Message or typing in another alarm message in
the Message box. An X is placed in the Alarm column of the selected attribute.
7. For History Extension, enter values for the remaining parameters: Force Storage Period,
Engineering Units, Value Deadband, Trend High and Trend Low, if available (depends on
the data type of the selected attribute). An X is placed in the History column of the selected
attribute.
8. For Boolean Extensions,
9. Lock the value if desired. The lock symbol is available only when you are extending a
template. Otherwise, it indicates the lock condition of the value in the parent object.
10. Set the security classification for the attribute if available. See "Security Icons" in "Working
with Object Editors" for more information.
11. Save and close the object editor to include the new attribute extensions in the configured
object.

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

System Platform - Part 1

4-10 Module 4 – Extending the Objects

The Value to be Sent value is sent during the next scan cycle, and the Next Value to be Sent value
is sent during the following scan cycle.
In other words, for Boolean data types and User sets, the following examples apply:

Previous Scan Cycle Scan Cycle Set

Value to be Sent Next Value to be Sent
Value Sent Requests
0 1,0,0,1,1 1 none
1 1,0,0,1,1 0 1
0 1,1,0,0 1 0
1 1,1,0,0 0 none

Note: In the case of Boolean data types used in Supervisory sets (sets between
ApplicationObjects and ArchestrA) or a mixture of Supervisory and User sets during a single scan
cycle, the behavior is the same as the other data types.

Important! When the same attribute is extended with an Input extension and an Output extension,
writes to the Output extension's Destination occur every scan regardless of whether the extended
attribute has changed. This behavior occurs even when the Output Every Scan check box is
cleared, increasing the potential for additional network traffic. The behavior described in this note
does not apply to an InputOutput extension.

Wonderware Training
 Lab 12 – Configuring the Motor Speed 4-11

Lab 12 – Configuring the Motor Speed

Introduction
In Lab 2, you identified that the motors, such as the agitator in the mixer, have a signal that
indicates the speed of the motor when it is running, and that this speed has a setpoint associated
with it to specify the desired speed for the process.
When you created the $Motor template in Lab 10 using the $DiscreteDevice, it was explained that
this object does not include, by default, attributes that can be used to indicate the speed of the
motor.
In this lab the $Motor template is modified by adding the attributes and functionality necessary to
include the speed data (and its setpoint) as identified in Lab 2.

Objectives
Upon completion of this lab you will be able to:
z Add and configure UDAs to your objects
z Extend attributes with input and output functionality

System Platform - Part 1

4-12 Module 4 – Extending the Objects

Summary Lab Instructions

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

Add and Extend the UDAs (page 4-13)

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

Configure the Agitator Instance (page 4-17)

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

Extendable Attribute Instance Attribute

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

Where XX is your student number.

View the Agitator Speed Data in Runtime (page 4-18)

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 12 – Configuring the Motor Speed 4-13

Detailed Lab Instructions

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

Add and Extend the UDAs

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

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

4. Name the UDA Speed and press Enter.
5. Configure the Speed UDA as follows:

Data type: Float

Category: Object writeable

System Platform - Part 1

4-14 Module 4 – Extending the Objects

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

Data type: Float

Category: User writeable

7. Select the Extensions tab.

8. Select the Speed attribute.

Wonderware Training
 Lab 12 – Configuring the Motor Speed 4-15

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

Input extension: checked

Source: ---.---

Ensure the Speed Attribute is selected before

configuring Input extension.

System Platform - Part 1

4-16 Module 4 – Extending the Objects

10. Select the SpeedSP attribute.

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

InputOutput extension: checked

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

Ensure the SpeedSP Attribute is selected before

configuring Input extension.

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

Wonderware Training
 Lab 12 – Configuring the Motor Speed 4-17

Configure the Agitator Instance

13. Double-click on the Agitator_001 instance to open its configuration editor.
14. Select the Extensions tab.
15. Select the Speed attribute.
16. Configure the Speed Attribute Input extension as follows, where XX is your student number.
00 is used in the following examples.

Instance Attribute
InControl tagname.T1XX_AG_Speed

Ensure the Speed Attribute is selected before

configuring Input extension.

System Platform - Part 1

4-18 Module 4 – Extending the Objects

17. Select the SpeedSP attribute

18. Configure the InputOutput extension for the SpeedSP attribute as follows, where XX is your
student number.

Instance Attribute
InControl tagname.T1XX_AG_SpeedSP

Ensure the SpeedSP Attribute is selected before

configuring Input extension.

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

View the Agitator Speed Data in Runtime

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

Wonderware Training
 Lab 12 – Configuring the Motor Speed 4-19

23. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the watch list to Extensions.
24. Add the following Agitator_001 attributes to the watch list:
z Cmd
z PV
z Speed
z SpeedSP
25. Double-click the SpeedSP attribute to open the Modify Numeric Value window.
26. Set the SpeedSP attribute to any valid float value. In this example, 50 is used.

27. Click OK.

When the Agitator_001 is running the Speed attribute will indicate the actual speed of the motor
around the SpeedSP (speed setpoint).
28. Save the watch list.

System Platform - Part 1

4-20 Module 4 – Extending the Objects

– Intentionally left blank –

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-21

Section 3 – Introduction to QuickScript .NET

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

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

System Platform - Part 1

4-22 Module 4 – Extending the Objects

Scripts Page
The Scripts page has six areas.

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-23

The main areas of the Scripts page include:

z 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.
z 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.
z Configure Execution Order: Sets the execution order of multiple scripts (inherited and
local) associated with this object.
z Aliases area: Lets you create and modify aliases that apply to the script you are working
on. Aliases are logically descriptive names for typically long ArchestrA reference strings
that you can use in the script to make the script more readable.
z Declarations area: Provides a place to add variable declaration statements, such as DIM
MyArray[1] as FLOAT;. These declared variables live from the startup to the shutdown of
the object and can be used to hold values that persist from one execution of the script to
the next. They apply only to the script in which they are declared.
z Scripts area: In this area you can write the body of the script and perform additional script
configuration.
z Execution type: Select Startup, OnScan, OffScan, Shutdown, or Execute.
„ Basics area: Provides a location to set the expression, triggering conditions, and
other settings that run the script in the run-time environment. The Basics area shows
only when an Execution type of Execute is selected.
z Script Editor box: Shows the script you are writing.

Script Development Environment

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

System Platform - Part 1

4-24 Module 4 – Extending the Objects

Script Execution Types

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

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

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-25

Time-based scripts, WhileTrue, WhileFalse, and Periodic are evaluated and executed
based on the elapsed time from a timestamp generated from the previous execution, not
on an elapsed time counter. Because of this it is possible that a change in the system
clock can result in the interval between execution of these script to be off.
For example, a periodic script is set to run every 60 minutes. The script executes at 11:13
am, therefore we would expect it to execute 60 minutes later at 12:13 PM. However, let's
assume that a time sync event has occurred and the node's time is adjusted from 11:33
am to 11:30 am. The script will still execute when the system time reaches 12:13 PM. But
because of the time change the actual (True) time period that has elapsed between
executions is 63 minutes.
Quality changes: When the DataChange Trigger type is selected, the Quality changes
checkbox enables. Select this box to trigger the script to run when the Quality of the
Expression value changes. In this configuration the script will run whether or not the
Expression value changes.
Deadband: When the DataChange Trigger type is selected, Deadband specifies the
amount the expression value must change before the script is executed.
OffScan
Called when the object is taken OffScan. Primarily used to clean up the object and account for any
needs that should be addressed as a result of the object no longer executing.
Shutdown
Called when the object is about to be taken out of memory, usually as a result of the AppEngine
stopping. Primarily used to destroy COM objects and .NET objects and clean up memory.

System Platform - Part 1

4-26 Module 4 – Extending the Objects

Attribute References

Relative References
References that go up the hierarchy to parent objects are called relative references.
Relative references, such as Me, are valid reference strings. A valid reference string must always
contain at least a relative reference or one substring.
The following are valid relative references that refer to the current object:
z Me
z MyContainer
z MyPlatform
z MyEngine
z MyArea
Relative references are especially useful in templates because absolute references typically do
not apply or make sense.
When you use relative references, like MyContainer, you can refer to contained objects within that
container. For example, a reference to MyContainer.InletValve.PV is equivalent to
Tank1.InletValve.PV in the following hierarchy:
Tank1 Cannot reference at this level because this is not contained
Inlet Valve (InletValve) Can reference at this level because this object is contained
Outlet Valve (OutletValve) Can reference at this level because this object is contained

Using Aliases
Accessing external attributes via an alias into an external attribute reference table is the most
versatile approach when using script code in templates. However, it forces the user to deal with an
indirection.
First the user has to specify an alias for an external reference (for example, PVofInletValve) in the
Alias Reference table (see below). Then the alias can be used directly in the script code:
If PVofInletValve==”Open” Then
{Do something}
Endif;
This script can be locked in the template without locking down which attribute on what object is
actually used in an instance derived from this template.
The actual mapping to an attribute is done via the Alias Reference table exposed by the script
editor. The table exposes the following fields:

Alias Reference
PVofInletValve Valve101.PV
… …

The Alias field is filled in automatically as the script text is parsed.

Note: Aliases do not need to specify the default property ‘Value’. Correspondingly the specified
reference does not need to include the property field.

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-27

Accessing Properties Other than Value

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

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

Accessing Array References

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

UDAs and Scripting

When using UDAs in scripting, keep the following list in mind.
z If you use Calculated and Calculated retentive UDAs, they must be manually initialized.
For example, if you use me.UDA=me.UDA+1 as a counter in a script, you must also
initialize the UDA with something like me.UDA=1 or me.UDA=<some attribute value>.
z Calculated UDAs can be initialized in scripts with Execution type triggers of On Scan
and Execute, but not initialized in Startup scripts.
z Calculated retentive UDAs can be initialized nearly anywhere, however the advantage of
initializing on Startup is the StartingFromCheckpoint attribute can be evaluated. For
example, a Calculated retentive UDA retains the attribute’s current value after a
computer restart, redundancy-related failover, or similar situation in which valid checkpoint
data is present. Your Startup script should contain a statement testing the Boolean value
of the StartingFromCheckpoint attribute on the object’s AppEngine. If the value is TRUE,
do not initialize the UDA. If the value is FALSE, initialize the UDA.

System Platform - Part 1

4-28 Module 4 – Extending the Objects

Language Definition
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the
case is preserved throughout editor sessions.
Both single line and multi-line comments are supported. Single line comments start at a ‘ in a
source code line that has no matching ending ‘ in the line. Multi-line comments start with a { and
end with a } and can span multiple lines as the name suggests.
Examples:
Dim A; ’This is a single line comment
Dim B; {This is an example of a multi-
line comment}
Spaces and indentation can be used as desired to improve readability, except that at least one
space must appear between adjacent identifiers, and spaces and line breaks cannot appear within
identifiers and numbers. Individual statements are distinguished by a semicolon that marks the
end of a statement.

QuickScript.NET Operations that Require 1 Operand

Operation Description
~ Complement
- Negation
NOT Logical NOT

QuickScript.NET Operations that Require 2 Operands

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

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-29

QuickScript.NET Precedence of Operators

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

Precedence Operator
1 (highest) (, )
2 - (negation), NOT, ~
3 **
4 * , /, MOD
5 +, -
6 SHL, SHR
7 <, >, <=, > =
8 ==, <>
9 &
10 ^
11 |
12 =
13 AND
14 (lowest) OR

QuickScript.NET Variables
Local variables or attributes can be used interchangeably within the same script. However, local
variables go out of scope at the end of the script function they are used in. However, variables
declared in the general section of the script exist and keep their value throughout the lifetime of the
object that the script is associated with. Thus this kind of variable turns into a ‘member variable’ of
the script class. Other scripts attached to the same object cannot access this variable.
Variables can be used on both the left and right hand side of statements and expressions.
Each variable must be declared within the script by a separate DIM statement followed by a
semicolon The DIM statement syntax is as follows:
DIM <variable_name> [ ( <upper_bound> [, <upper_bound >[, < upper_bound >]] )
] [ AS <data_type> ];

where

variable_name ::= <letter> { <letter> | <digit> | <special_character> }

letter ::= A-Z | a-z
digit ::= 0-9
special_character ::= _
upper_bound ::= 1-2,147,483,647
data_type ::= Boolean | Discrete | Integer | Float | Real | Double | String |
Message | Time | Object
The variable name is limited to 255 Unicode characters. Note that, in contrast to attribute names,
variable names must not contain dots. Variable names and the data type identifiers are not case
sensitive. If there is a naming conflict between a declared variable and another named entity in the
script (attribute name, alias, name of an object leveraged by the script), the variable name takes
precedence over the other named entities.

System Platform - Part 1

4-30 Module 4 – Extending the Objects

For example, let’s assume that your script accesses the hosting object’s PV attribute in the script
text and you declare ‘DIM PV AS Integer;’. Within the declaring script, expressions using ‘PV’ in a
statement will refer to the value associated with the local variable ‘PV’ rather than the attribute
‘PV’.

Note: The naming convention for QuickScript.NET variables is more restrictive than in
QuickScript. In QuickScript additional special characters are allowed:
QuickScript_special_character :- _!@-?#$%\&

In contrast to QuickScript arrays with up to three dimensions are supported. Only the upper bound
of each dimension can be specified and is fixed after the declaration; i.e., a statement analogous
to VB’s ReDim statement is not supported. The lower index of each array dimension is always 1.
The data type declaration (AS <data_type>) is optional. If omitted, the data type of the variable is
Integer (as in QuickScript).

Data Type
Default
(as specified in Comment
Value
AS <data_type>)
Boolean, Discrete False Discrete and Boolean are synonymous. Discrete is still
supported for migration from InTouch.
True=1, False=0
Integer 0 Signed
–2147483648 to 2147483647
Float, Real NaN Float and Real are synonymous. Real is still supported for
migration from InTouch.
For range information please refer to Appendix
Double NaN For range information please refer to Appendix
String, Message “” Maximum length (2147483647)
(empty
string)
Time 0 Resolution is 100 nanoseconds, used to reflect an absolute
date / time the content reflects the number of 100-nanosecond
intervals since 00:00 January 1, 0001.
ElapsedTime 0 100 nanosecond ticks represents a time span.
Object Nothing Leveraged for accessing OLE Automation servers.

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

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-31

QuickScript.NET Control Structures

QuickScript.NET provides four primary control structures in the scripting environment:
z IF ... THEN ... ELSEIF ... ELSE ... ENDIF
z FOR ... TO ... STEP ... NEXT Loop
z FOR EACH ... IN ... NEXT
z WHILE Loop

IF … THEN … ELSEIF … ELSE … ENDIF

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

Data Type Mapping

Boolean, Discrete Directly used (no mapping needed)
Integer Value = 0 evaluated as False
Value != 0 evaluated as True
Float, Real Value = 0 evaluated as False
Value != 0 evaluated as True
Double Value = 0 evaluated as False
Value != 0 evaluated as True
String, Message Cannot be mapped. Using an expression
that results in a string type as the
boolean_expression results in a script
validation error.
Time Cannot be mapped. Using an expression
that results in a time type as the
boolean_expression results in a script
validation error.
Object Cannot be mapped. Using an expression
that results in an object type as the
boolean_expression results in a script
validation error.

The first block of statements is executed if boolean_expression evaluates to True. Optionally a

second block of statements can be defined after the keyword ELSE. This block is executed if the

System Platform - Part 1

4-32 Module 4 – Extending the Objects

boolean_expression evaluates to False. In order to facilitate deciding between multiple

alternatives an optional ELSEIF clause can be used as often as needed. The ELSEIF clause
allows for easy mimicking of switch statements offered by some other programming languages.
Example:
If value = 0 Then
Message = ”Value is zero”;
ElseIf value > 0 Then
Message = ”Value is positive”;
ElseIf value < 0 then
Message = ”Value is negative”;
Else
{Default. Should never occur in this example}
EndIf

FOR … TO … STEP … NEXT Loop

A FOR-NEXT loop is used to perform a function (or set of functions) within a script several times
during a single execution of a script. The general format of the FOR-NEXT loop is as follows:
FOR <analog_var> = <start_expression> TO <end_expression> [STEP
<change_expression>]
[statements]
[EXIT FOR;]
[statements]
NEXT;
Where:
z analog_var is a variable of type Integer, Float, Real, or Double.
z start_expression is a valid expression, to initialize analog_var to a value for execution of
the loop.
z 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.
z (This holds true if loop is incrementing up, otherwise, if loop is decrementing, loop
termination will occur if analog_var is less than end_expression.)
z change_expression is an expression, to define the increment or decrement value of
analog_var after execution of the NEXT statement. The change_expression can be either
positive or negative. If change_expression is positive, start_expression must be less than
or equal to end_expression or the statements in the loop will not execute. If
change_expression is negative, start_expression must be greater than or equal to
end_expression for the body of the loop to be executed. If STEP is not set, then
change_expression defaults to 1.
It is possible to exit the loop from within the body of the loop via the EXIT FOR statement.
The FOR loop is executed as follows:
1. analog_var is set equal to start_expression.
2. The system tests to see if analog_var is greater than end_expression. If so, the loop exits. (If
change_expression is negative, the system tests to see if analog_var is less than
end_expression.)

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-33

3. The statements in the body of the loop are executed. Here the loop can potentially be exited
via the EXIT FOR statement.
4. analog_var is incremented by 1 - or by change_expression if it is specified.
5. Steps 2 through 4 are repeated.

Note: FOR-NEXT loops may be nested. The number of levels of nesting possible depends on the
memory and resource availability.

FOR EACH … IN … NEXT

The FOR EACH loop can only be used with collections exposed by .NET objects and OLE
Automation servers .A FOR-NEXT loop is used to perform a function (or set of functions) within a
script several times during a single execution of a script. The general format of the FOR-NEXT
loop is as follows:
FOR EACH <object_variable> IN <collection_object >
[statements]
[EXIT FOR;]
[statements]
NEXT;
Where:
z object_variable is a variable of type <some COM interface>
z collection_object is a variable holding a collection object.
As in the case of the FOR … TO loop it is again possible to exit the execution of the loop via the
statement ‘EXIT FOR;’ from within the loop.

Note: Collections are frequently leveraged by VB and VBA / JScript. Microsoft’s office suite is built
around the concept of collections. Furthermore Microsoft® started to expose more and more of the
Windows® system via collections.

Example:
Dim fso As IFileSystem;
Dim folder As IFolder;
Dim fileCollection As IFileCollection;
Dim file As IFile;
Dim fileName as String;

fso = new FileSystemObject;

folder = fso.GetFolder(“C:\Temp”);
fileCollection = folder.Files;
For Each file In fileCollection
fileName = file.name;
Next;
FOR EACH will allow for looping through arrays.

System Platform - Part 1

4-34 Module 4 – Extending the Objects

WHILE Loop
A WHILE loop is used to perform a function (or set of functions) within a script several times during
a single execution of a script while a condition is true. The general format of the WHILE loop is as
follows:
WHILE <boolean_expression>
[statements]
[EXIT WHILE;]
[statements]
ENDWHILE;
Where:
z boolean_expression is an expression that can be evaluated as a Boolean as defined
above in the description of IF…THEN statements.
It is possible to exit the loop from within the body of the loop via the EXIT WHILE statement.
The WHILE loop is executed as follows:
1. The system tests to see if boolean_expression is true. If not, the loop exists.
2. The statements in the body of the loop are executed. Here the loop can potentially be exited
via the EXIT WHILE statement.
3. Steps 1 through 2 are repeated.

Note: WHILE loops may be nested. The number of levels of nesting possible depends on the
memory and resource availability.

Script Execution Error Handling

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

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-35

Alarm Type Errors

Timeout Error
To prevent the possibility that a script can cause an overrun of the ApplicationEngine scan cycle
(for example, by running in an infinite loop), a script is aborted after the timeout period for the script
has elapsed. The script execution infrastructure will clean up after the aborted script as best as
possible. For example, the script infrastructure must attempt to release external objects or data
base connections that were created by the script. However, it can never be guaranteed that an
aborted script has no negative side effects. For example, the script could have started to
manipulate data base entries and could leave some table entries in an inconsistent state.
All synchronous mode scripts will be subject to the same timeout period, which is exposed as an
attribute on the AppEngine.
The script developer will be required to configure the timeout period for each Asynchronous mode
script in order to provide flexibility in accommodating the potentially time consuming operations
that these scripts are intended for.

Overflow Error
A script experiences an overflow condition. Overflow conditions not only apply to analog data
types (integer float) but also other data types (for example, string length overflow).

Division by Zero
The division by zero error is raised only for integer operations. In the case of float values the
scripting is able to deal with + ∞ and - ∞ and also NaN (Not a Number).

Net Call Execution Errors

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

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

Importing Additional Libraries

Script Library Packages can be added to the system and made available to the user like pre-
installed script libraries.

Note: Script libraries developed with the InTouch 32-bit Extensibility toolkit can be imported and
converted to Script function Libraries.

System Platform - Part 1

4-36 Module 4 – Extending the Objects

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

Data Quality Handling

Two approaches to handling data quality during script execution are employed in the Application
Server script environment. The first approach, Data Quality Controlled Execution (DQCE), is used
by all script expressions and permits expression evaluation only when attributes being read by the
expression have acceptable qualities. The other approach, Data Quality Propagation (DQP), is
used by the script body and propagates the quality of attributes read by the script through the
script’s data as execution occurs.
Only referenced attributes expose quality. Local variables do not have a quality assigned. I.e.,
when assigning the value of an attribute to a local variable the quality information is lost.
Example: The following code snippet assumes that A and B are local variables of appropriate data
type.
A = Valve101.PV
{The value of A is now the value of Valve101.PV.Value. The actual name of the
Value property is spelled out for clarity purposes. The variable A just holds
the value, not the quality.}
B = Valve101.PV.Quality
{Another variable can be used to hold the quality information but no local
variable is able to hold the value and the quality information.}

Quality Handling in Script Expressions

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

Data Quality Propagation (DQP)

DQP seeks to streamline the script development task when writing scripts that robustly handle
data quality. One of the main differences between DQCE and DQP is that in the latter case the
execution of the script still happens even though some of the referenced attributes might expose
unacceptable quality. In typical cases portions of a given complex script are not affected by the
bad quality of a given attribute and therefore will be executed. As a result the script developer
needs the ability to evaluate the quality of attributes within the script and to react accordingly (for
example, by branching into a code segment that causes the system to go into a fail safe mode.)

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-37

When using the Application Server scripting language, the script developer should understand the
following rules and behavior: data time handling / propagation.

Script Functions do not Leverage Quality Information

For Script Functions the in and out parameters as well as a potential return value have no
associated quality information. For example, a Script Function for calculating the square root of a
float value might have a signature like this:
float Sqrt(float InValue)
If an attribute reference is passed in as the InValue then the quality information is stripped off and
only the value of the referenced property (typically the Value property) is passed in.

Note: A function is invoked independent of whether the quality of the referenced attribute is
acceptable or not. It is the responsibility of the script developer to ensure that the method is
invoked appropriately.

Quality Check From Within a Script

The script developer has the ability to control the execution of script blocks by evaluating the
quality of a set of leveraged attributes. It is possible to either test each attribute’s quality
individually
If (Valve101.PV.Quality == 192) Or
Valve101.PV.Quality == 0) Then …
Or to use the quality check functions as follows:
If IsGood(Valve101.PV) Or
IsBad(Valve101.PV)) Then …
Positive Script Logic
Script languages adhering to DQP encourage users to apply positive logic in the script. I.e., any
expression that is used in a control statement (examples are: IF, REPEAT, WHILE) to produce a
Boolean result will equate to a false value if the expression leverages at least one attribute that
has bad or initializing quality. I.e., condition statements are automatically evaluated as False if at
least one attribute with unacceptable quality is used in the condition statement.
Example:
If (Valve101.PV == “Closed”) And
(Valve102.PV == “Closed”) Then
Set Valve103.Cmd = “Open”
Else
Set Valve103.Cmd = “Close”
{This should be the fail safe mode}
Endif;
If the quality of Valve101.PV and Valve102.PV is acceptable then the ‘if’ and ‘else’ branches are
executed purely based on the value of those two attributes.
However, if at least one of the PV values has an unacceptable quality (bad or initializing) then
automatically the ‘else’ branch is executed. I.e., if statements should be written in a way that the
else branch always constitutes the fail safe mode.
Adhering to this standard allows script writers to take quality into account without ever explicitly
evaluating the quality of referenced attributes.

System Platform - Part 1

4-38 Module 4 – Extending the Objects

Condition statements are the only instance where a DQP enabled script language takes quality
implicitly into account. In all other cases the script execution system ignores the quality if the script
developer does not choose to test the quality explicitly. This also means that the assignment
PID1.SP = PID2.SP
is executed independent of whether the quality associated with PID2.SP is Bad or
Initializing. That might be surprising at first. However, it leads to a more consistent behavior of the
script environment. Consider the following very similar script lines:
PID1.SP = PID2.SP + 10
PID3.SP = Sqrt(Tank101.Level)
PID4.SP = PID2.SP + A
{A is a local variable}
As soon as the right side is not just a single attribute reference but involves additional statements,
the script execution system has to ignore the quality. From a user’s perspective it is easier if all the
listed cases are treated equally; i.e., the quality is ignored in all cases.

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

Execution Mode
Execute mode scripts can be configured to execute in one of two execution modes, synchronous
or asynchronous. All other script types are always synchronous and cannot be configured
otherwise.

Synchronous Execution
The synchronous mode is the default choice and represents serial script execution by the
ApplicationEngine in the course of calling the Execute method of all ApplicationObjects that are
on-scan in the ApplicationEngine. For satisfactory determinism, this mode requires that all scripts
execute deterministically and quickly enough to prevent an ApplicationEngine over-scan condition.

Asynchronous Execution
The asynchronous mode is used for the class of scripts that perform operations that don’t meet the
above speed and determinism criteria. These scripts will be executed on a worker pool of
separate, lower priority threads than the Application Engine’s primary thread. No support will be
provided to establish prioritization of execution among Asynchronous mode scripts; they will all
receive the same priority.
An asynchronous script running in a separate thread can access ArchestrA™ attributes via normal
get/set calls. The call is marshaled over to the main engine thread and processed. The calling
thread waits for call return until main thread can process get/set request. This is OK since
asynchronous thread is usually slower and background in nature.
Only script code written for the Execute type of an object can be declared asynchronous.
If an asynchronous script is currently executing, then the condition for next execution is not
evaluated and it is not executed again. Condition evaluation is always done in main thread of
engine. Therefore, only one copy of a given asynchronous script in an object can be executing at
one time.

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-39

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

Asynchronous Script Threads

Threads are used for processing asynchronous scripts simultaneously when they are due and
their trigger condition is true. Only one script can execute on one thread at a time. If an
asynchronous script comes due and no worker thread is available, it is immediately queued for
execution and awaits a free worker thread. As soon as the worker thread is free from its previous
script, it executes the newly queue script.
A default number of worker threads is to be provided. This is a configurable attribute of the Engine.

Asynchronous Scripts Diagnostics and Attributes

Asynchronous scripts require some additional attributes within the script to provide the following
behavior:
z Kill attribute - terminates the asynchronous script when written to.
z Shutdown attribute – simply a Boolean flag that requests the asynchronous script to shut
down on its own. A well-written script will check this command before and after time-
consuming operations.
z Running indicator attribute – indicates whether the asynchronous script is currently
executing.
z Elapsed time attribute – indicates the amount of time the asynchronous script has been
executing (if RunningFlag is true).
z Asynchronous scripts also have the following diagnostic attribute within the engine:
z Count of asynchronous scripts running – indicates the number of asynchronous scripts
currently executing.
z Count of asynchronous scripts waiting – indicates the number of asynchronous scripts
currently queued to execute.

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

System Platform - Part 1

4-40 Module 4 – Extending the Objects

Support for .NET Constructs

QuickScript .NET is built on top of .NET and supports the following .NET constructions in its
syntax:
z Declaring variables of .NET types.
z Calling public constructors (with and without parameters) of .NET types.
z Calling public instance methods (with and without parameters) of .NET types.
z Calling public static methods (with and without parameters) of .NET types.
z Calling public indexers (with one or more parameters) of .NET types.
z Using .NET enumerations.

OLE Automation Support

Over the last couple of years Microsoft used many different terms when talking about OLE
Automation. In order to reduce confusion the following part attempts to establish the terms used
throughout this document:
Support for COM Servers:
z Support for Get/Set Property
z Support for method invocation on COM server
Creating objects outside of the context of scripts does not work. In many cases an object can only
be created in a programmatic manner based on another already created object.
VBS example:
Dim xlApp
Dim xlBook
Dim xlSheet
' Assign object references to the variables. Use
' Add methods to create new workbook and worksheet
' objects. Note that xlBook and xlSheet can only be
' created after the objects xlApp and xlBook got
' created.
Set xlApp = WScript.CreateObject("Excel.Application")
Set xlBook = xlApp.Workbooks.Add
Set xlSheet = xlBook.Worksheets.Add
Once created, the methods exposed by a COM object can be accessed as if they would be script
functions.
There are at least two different approaches:

Allow Creation of COM Servers from within a Script

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

Wonderware Training
 Section 3 – Introduction to QuickScript .NET 4-41

2. CreateObject method – this method instructs the script to specifically create a named COM
object that is installed on the system upon which the script is to be deployed. These are late-
bound objects. Late-bound methods on app can be called after the object is created.
dim app as object;
app = CreateObject(“Excel.Application”);

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

Note: Many additional script examples may be located in the ArchestrA IDE Help files under
Enhancing an Object’s Functionality/QuickScript .NET Scripting Language/Sample Scripts.

Load an XML Document from Disk and Do Look-ups on It

dim doc as System.Xml.XmlDocument;
dim node as System.Xml.XmlNode;
doc = new System.Xml.XmlDocument;
doc.Load("c:\catalog.xml");
' find the title of the book whose isbn is 044023722X
node = doc.SelectSingleNode("/catalog/book[@isbn='044023722X']/title");
LogMessage(node.InnerText);
' find all titles written by Grisham
for each node in doc.SelectNodes("/catalog/book[author/lastName='Grisham']/
title")
LogMessage(node.InnerText);
next;

Query a SQL Server Database

dim connection as System.Data.SqlClient.SqlConnection;
dim command as System.Data.SqlClient.SqlCommand;
dim reader as System.Data.SqlClient.SqlDataReader;
connection = new
System.Data.SqlClient.SqlConnection("server=(local);uid=sa;database=northwin
d");
connection.Open();
command = new System.Data.SqlClient.SqlCommand("select * from customers",
connection);
reader = command.ExecuteReader();
while reader.Read()
LogMessage(reader("CompanyName"));
endwhile;
reader.Close();
connection.Close();

Create a Look-up Table, Then Do a Look-up on It

dim zipcodes as System.Collections.Hashtable;
zipcodes = new System.Collections.Hashtable;
zipcodes["Irvine"] = 92618;
zipcodes["Mission Viejo"] = 92692;
LogMessage(zipcodes["Irvine"]);

System Platform - Part 1

4-42 Module 4 – Extending the Objects

Use DDE to Access an Excel Spreadsheet

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

Wonderware Training
 Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient 4-43

Lab 13 – Adding Auto Reconnect to

DDESuiteLinkClient

Introduction
The $DDESuiteLinkClient object lacks the capability to automatically reconnect to the data source
if the connection is lost, therefore in this lab you will extend the object with UDAs and scripts to add
reconnection functionality.
You will also add additional diagnostic information to the $DDESuiteLinkClient object through a
UDA/script combination that will indicate the number of disconnects the object has experienced
since it last went on scan.

Note: Your instructor will demonstrate the script’s resulting functionality.

Objectives
Upon completion of this lab you will be able to:
Use the QuickScript.NET scripting engine to extend your objects with extra functionality
z Use attributes, including UDAs, within scripts
z Create scripts with different execution types
z Reconnect whenever the InControl object gets disconnected

System Platform - Part 1

4-44 Module 4 – Extending the Objects

Summary Lab Instructions

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

Add the Auto-reconnect Functionality (page 4-45)

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

Expression: Me.ConnectionStatus <> 2

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

b. Add a Calculated Integer UDA named DisconnectCnt.

c. Add a script called DisconnectMonitor (locked) with an Execute execution type configured
as follows:
Expression: Me.ConnectionStatus <> 2
Trigger type: OnTrue
Script body:
Me.DisconnectCnt = Me.DisconnectCnt + 1;
and an OnScan execution type configured as follows:
Script body:
Me.DisconnectCnt = 0;
d. Deploy the InControl object

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient 4-45

Detailed Lab Instructions

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

Add the Auto-reconnect Functionality

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

System Platform - Part 1

4-46 Module 4 – Extending the Objects

2. Select the Scripts tab.

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

Aliases section: (locked)

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

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

Wonderware Training
 Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient 4-47

4. Select the UDAs tab.

5. Click the button to add a UDA to the object. Name the UDA DisconnectCnt and
configure it as follows:
Data type: Integer
Category: Calculated

The DisconnectCnt attribute is a counter that will keep track of how many times the object
disconnects. The attribute value will be updated via a script, defined next.
6. Select the Scripts tab.

System Platform - Part 1

4-48 Module 4 – Extending the Objects

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

Aliases section: (locked)

Declarations section: (locked)
Scripts section:
Execution type: Execute (locked)
Basics section: (locked)
Expression: Me.ConnectionStatus <> 2
Trigger type: OnTrue
Script body section: Me.DisconnectCnt = Me.DisconnectCnt + 1;

This script monitors the connection status of the object. Every time it changes from a 'Connected'
status to a non-connected status ('Disconnected' or 'Mixed'), it increments the count
(DisconnectCnt attribute).

Wonderware Training
 Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient 4-49

8. Select the DisconnectMonitor script

9. Select an Execution type of OnScan to add a second section to the script.

10. Configure the script as follows:

Script body section:
Me.DisconnectCnt = 0;

This script will initialize the DisconnectCnt attribute to zero when the object goes on scan.
11. Click the Save and Close button and check in the object.
12. Deploy the InControl instance, accepting the defaults in the Deploy dialog box.

Note: Your instructor will demonstrate how the completed lab steps have changed the
behavior of the deployed object.

System Platform - Part 1

4-50 Module 4 – Extending the Objects

– Intentionally left blank –

Wonderware Training
 Lab 14 – Configuring Automatic Reference 4-51

Lab 14 – Configuring Automatic Reference

Introduction
This lab illustrates how to add to the mixer objects the capability of automatically configuring the
input and output references within the objects based on the naming conventions established for
your galaxy.
To successfully provide this functionality, a compromise regarding the naming of the objects has to
be arranged. In this example, it is required that every instance derived from the $Mixer template is
named with the valid three-digit mixer identification number at the end as identified in Lab 2.

Objectives
Upon completion of this lab you will be able to:
z Use the QuickScript.NET scripting engine to automatically configure on runtime the input
and output references of instances

System Platform - Part 1

4-52 Module 4 – Extending the Objects

Summary Lab Instructions

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

Add the Auto-configuration Functionality (page 4-53)

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

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

Object List Attribute List

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 14 – Configuring Automatic Reference 4-53

Detailed Lab Instructions

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

Add the Auto-configuration Functionality

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

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

Aliases section: (locked)

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

'Get the common part for the references.

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

'Configure inlet valve 1.

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

'Configure inlet valve 2.

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

'Configure outlet valve.

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

'Configure transfer pump 1.

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

'Configure transfer pump 2.

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

'Configure level meter.

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

'Configure temperature transmitter.

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

'Configure agitator.
Me.Agitator.AuxContact.InputSource = dataSource + "_AG_AuxContact";
Me.Agitator.CmdStart.OutputDest = dataSource + "_AG_CmdStart";
Me.Agitator.Speed.InputSource = dataSource + "_AG_Speed";
Me.Agitator.SpeedSP.InputSource = dataSource + "_AG_SpeedSP";

System Platform - Part 1

4-54 Module 4 – Extending the Objects

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

Modify the Mixer instance, create and deploy a Mixer instance

4. Right-click Mixer_001 and select Undeploy.

5. Click OK to confirm the Undeploy, retaining the default selections in the Undeploy dialog
box.

Wonderware Training
 Lab 14 – Configuring Automatic Reference 4-55

6. Click Close when the Undeploy is complete.

7. Right-click Mixer_001 and select Rename.
8. Rename Mixer_001 to Mixer_1XX, where XX is your student number.

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

9. Click the Yes button.

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

System Platform - Part 1

4-56 Module 4 – Extending the Objects

13. Assign Mixer_2XX to the Line2 area.

14. Click the button to expand the Mixer_2XX instance.
The new instance of the Mixer_2XX displays a warning icon on all contained objects. Your
instructor will address this after the lab.

Note: Warnings can be cleared by setting the default references from ---.--- to ---, or by using the
Upload Runtime Changes in the context menu after deployment.

Important! If there is a warning icon on the Mixer_2XX instance itself, notify your instructor.

Warning
icons
are OK!

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

16. Click Close when deployment is complete.

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

Wonderware Training
 Lab 14 – Configuring Automatic Reference 4-57

18. Click Close when deployment is complete.

Verify configuration of Mixers and their contained Objects

19. Right-click on Mixer_1XX and select View in Object Viewer. If you closed Object Viewer
before, you can use File / Load Watch List to open the file you saved earlier.
20. Click the Mixer Watch List to verify that the contained objects data values are updating.
21. Right-click the Mixer Watch List and select Rename Tab to rename it to Mixer 1.
22. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
Window to add a new tab to the watch list.
23. Right-click in the new Watch List (bottom section of Object Viewer) and select Rename Tab
to rename the watch list to Mixer 2.

System Platform - Part 1

4-58 Module 4 – Extending the Objects

24. Using the Object List (left section of Object Viewer) and the Attribute List (right section of
Object Viewer), locate and add the following attributes for the Mixer_2XX instance to the
selected Mixer 2 watch list by right-clicking on each attribute and selecting Add to Watch:

Object List Attribute List

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

25. Save the watch list.

Wonderware Training
 Module 5

Alarms and History

Section 1 – Alarms 5-3
Lab 15 – Configuring Alarms 5-13
Section 2 – Historization 5-31
Lab 16 – Configuring History 5-37
5-2 Module 5 – Alarms and History

Module Objective
z Obtain an overview and understanding of the concepts of Alarms, Events and
Historization and how ArchestrA handles each.

Wonderware Training
 Section 1 – Alarms 5-3

Section 1 – Alarms

Section Objectives
z Familiarize you with the concept of alarms and events, and
z Enable you to understand how ArchestrA handles alarms and events.

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

What is an Alarm/Event
The alarm and event capabilities in the system provide for users to automate the detection,
notification, historization and viewing of either application (process) alarms and events or system/
software alarms events. Alarms and events are things that occur in the runtime system. Events
and alarms are different and the system distinguishes between the two. An event is simply an
occurrence of a condition at a certain point in time. The system can detect events, store them
historically and report them to various clients. Alarms, on the other hand, represent the
occurrence of a condition that is considered abnormal (generally bad) in nature and requiring
immediate attention from a user. Alarms are a special type of event that indicate something
abnormal has happened. The system handles the real-time reporting of alarms in a special
manner and provides special clients for their viewing.
Examples of alarms include:
z A process measurement has exceeded a predefined limit, such as a high temperature
alarm.
z A process device is not in the desired state, such as a pump that should be running has
stopped.
z The system hardware is not operating within desired limits, for example the CPU utilization
on a Platform exceeds a certain percentage for an extended time.
Examples of events include:
z A plant process has started; for example, a new batch or campaign starts.
z The operator has changed a plant operator parameter; for example, a setpoint on a
temperature controller.
z The system engineer has changed the runtime system configuration; for example,
deployment of a new AutomationObject.
z The system engineer has started or stopped a system component; for example, stopping
an engine.
z A platform has come back online after it had a failure or shutdown.
z A user has logged into the system.
z Detection of a severe software problem; such as a failed Application Object component.
The following items are not considered alarms or events:
z Configuration actions within the Galaxy Repository; for example import or check-out.
z Installation of Bootstrap on a PC.
z A message sent to the system logger (SMCLogger). Note, sometimes certain software
events may log a message in addition to generating an event, but this is ancillary. Logger
messages are not events.
z Viewing a window in the View Engine.

System Platform - Part 1

5-4 Module 5 – Alarms and History

How does ArchestrA handle alarms?

The Platform as an Alarm Provider

A Platform can act as a single Alarm Provider that provides alarms to the InTouch Distributed
Alarm subsystem. A boolean checkbox is provided in the Platform AutomationObject indicating
whether it subscribed to Areas or not for alarm and event reporting. The Platform, when deployed,
only initiates subscription to those Areas that are only deployed to that Platform.
The platform is responsible for routing all alarms and events for all Areas subscribed to by that
Platform to InTouch’s distributed alarming infrastructure. The Platform acts as a router between all
Alarm/Event Notification Distributors that are running in the subscribed Areas throughout the
Galaxy (inside every Area, Platform, Engine, DI Device, etc.) and the distributed alarming
infrastructure. The Platform also routes alarm acknowledgements, enables and disables received
from distributed alarming back to the appropriate AutomationObject. Alarm acknowledgements,
enables, and disables carry along the User information for security purposes. An alarm generated
by Application Server contains fields that are generated by the alarm functions inside the
AutomationObject. Those fields are mapped to fields in InTouch as follows:

Alarms:
ArchestrA field InTouch Dist Alarms Mapping
Type = alarm state change N/a
Timestamp of alarm event Time
Tagname Name
Common message text string. Comment
Area Alarm group
Common name for alarm primitive Alarm Type (string)
(for example “PV.HiAlarm”)
New alarm state (ack, rtn, etc.) State
Priority = 1-999 Priority
Value (mxValue) Value
Limit (mxValue) Limit
Value MxReference N/a
Limit MxReference N/a
Units MxReference N/a
Category Class
Category SubClass

InTouch as an Alarm Consumer

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

Alarm Acknowledgement from Distributed Alarming

The InTouch Alarm Client can acknowledge unacknowledged alarms that are reported by the
Platform. The Platform receives the acknowledge request and forwards it to the target

Wonderware Training
 Section 1 – Alarms 5-5

AutomationObject’s acknowledge attribute for the alarm. Security is used as part of this set (it is a
UserSetAttribute). An optional comment can be entered when the acknowledge is requested.
An acknowledge of an alarm is reported as an alarm state change back to the distributed alarming.
The optional operator comment is included in the event message sent back.
Distributed Alarming has no support for passing a rejected acknowledge failure feedback.
Therefore, if an acknowledge is requested from a client but does not succeed, the only feedback
on the InTouch client will be no change in acknowledge status on the client.

Alarm Enable/Disable
The InTouch Alarm Client can enable/disable alarming on any AutomationObject. The platform
receives the enable request and forwards it to the target AutomationObject’s AlarmMode attribute.
Security is used as part of this set (it is a UserSetAttribute).

How does ArchestrA handle Events?

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

System Events:
Distributed Alarm subsystem
ArchestrA field
Mapping
Type (or Category) = System Type = SYS
Timestamp Time
Tagname Name
Tag description Comment
Area Alarm group
System event description Event Type – if string, or use
(“started”, “stopped”) Comment field
N/a State = none (preferred) or
“UNACK_RTN”
N/a Priority = 1
N/A Provider = Galaxy
N/A Event Class = EVENT

Security Audit (includes User Data Change) Events:

Distributed Alarm subsystem
ArchestrA field
Mapping
Type = Operator Change Type = OPR
Timestamp Time
Tag.primitive.attribute Name
Tag description Comment
Area Alarm group
View engine name

System Platform - Part 1

5-6 Module 5 – Alarms and History

Security Audit (includes User Data Change) Events: (continued)

Distributed Alarm subsystem
ArchestrA field
Mapping
Operator 1 name RequestingEngineName +
Operator name
Operator 2 name N/a
Old value Limit
New value value
N/a State = none (preferred) or
“UNACK_RTN”
N/a Priority = 999
N/A Provider = Galaxy
N/A Event Class = EVENT

Application Data Change Events:

Distributed Alarm subsystem
ArchestrA field
Mapping
Type = Data Change Type = LGC
Timestamp Time
Tag.primitive.attribute Name? Or name+comment?
Tag description Comment
Area Alarm group
View engine name Platform (the PC’s node name)
Old value Limit
New value Value
N/a State = none (preferred) or
“UNACK_RTN”
N/a Priority = 999
N/A Provider = Galaxy

Wonderware Training
 Section 1 – Alarms 5-7

Alarm Queries
Alarm queries are used within alarm clients to retrieve real-time alarm information and event
reports from the Galaxy.
The fully-qualified syntax of an alarm query to retrieve a single alarm within an object as reported
by a specific WinPlatform object is:
\\nodename\Galaxy!area!object.attribute
If the WinPlatform object that serves as an alarm provider is located in the local computer, the
following syntax of the alarm query is allowed:
\Galaxy!area!object.attribute
The following table lists different variants of the alarm query and their return data:

Alarm Query Results

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

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

Alarm Query Results

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

Only one wildcard character is allowed per alarm query.

Using Multiple Queries
Multiple queries can be submitted by an alarm client. For example, if Area1 an Area2 are two
mutually exclusive areas, the following two queries can be submitted at once:
\Galaxy!Area1 \Galaxy!Area2
By using multiple queries it is possible to retrieve alarms from different nodes (WinPlatform
objects) at the same time, for example:
\\NodeNameA\Galaxy!Area1 \\NodeNameB\Galaxy!Area2

System Platform - Part 1

5-8 Module 5 – Alarms and History

General Attributes
Alarm Attributes
You can set individual alarms within an object for each type of alarm. For example, you can set
alarms for each of the limits of a level alarm. The calculated AlarmMode attribute value of an
individual alarm uses the same inputs an object alarm. The parent AlarmMode attribute is from the
object itself. As with object alarms, the individual alarm mode is set to the most restrictive input
state. For example, if the object’s AlarmMode state is disabled and the individual alarm’s
AlarmInhibit is FALSE, the individual alarm is disabled.
Each individual alarm is autonomous from other individual alarms in an object. The AlarmMode of
an individual alarm is not propagated to other alarms. Unlike inhibit for the entire object, inhibit of
an individual alarm does not affect the alarms of any contained objects. You can selectively
enable, silence, or disable an individual alarm and not set other alarms to the same value within
the object hierarchy.

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

Alarm Attributes

Attribute Description
<Attribute>.Acked Used to specify whether an alarm has been acknowledged. This
attribute is updated when the AckMsg attribute is set. This attribute is
always set to FALSE when a new alarm condition is detected (when the
InAlarm attribute changes from FALSE to TRUE).
<Attribute>.AckMsg The operator comment at the time the alarm is acknowledged. Any
received text is stored, and the Acked attribute is set to TRUE. Also, the
TimeAlarmAcked attribute is set to the current time. The maximum
length is 256 characters.
<Attribute>.AlarmMode The current alarm mode setting. Valid values are: Enable, Disable,
Silence.

<Attribute>.AlarmModeCmd The command to set the alarm mode. Valid values are: Enable, Disable,
Silence.

<Attribute>.Category The category of the alarm. The label of each alarm category is fixed.

Wonderware Training
 Section 1 – Alarms 5-9

Attribute Description
<Attribute>.DescAttrName The description of the alarm. The description must be of type String or
InternationalizedString, with a maximum length of 329 characters. The
DescAttrName attribute can contain a static alarm description or a
reference to another string attribute within the same object containing
the alarm description. The reference must be in the form:
"me.AttrName". If the reference is invalid, the actual reference string is
used for the description. If nothing is supplied for the DescAttrName
attribute, the object’s ShortDesc attribute is used at run time.
<Attribute>.InAlarm The alarm state. This is exactly the same as the attribute in the host
primitive that represents the alarm condition, except when the alarm
state is disabled, in which case, InAlarm is set to Off, regardless of the
actual condition state.
The quality is set during execute to the quality of the attribute, except
when the alarm is disabled, in which case the quality is always GOOD.
<Attribute>.Inhibit If true, the alarm is disabled. This attribute is intended to be written to by
a script or user or input extension. Only the individual alarm is disabled.
No other alarms are disabled in the same object or in any objects that
are assigned to or contained by this object.

<Attribute>.Priority The value for the urgency of the alarm. Valid values are 1 through 999,
with 1 being the most urgent.

<Attribute>.TimeAlarmAcked The timestamp indicating the last time this alarm was acknowledged.
The date format reflects the current locale setting for the operating
system.

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

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

Enabling, Silencing, and Disabling Alarms

Alarms can be enabled, disabled, or silenced while an application is running. Setting an object’s
alarm state can be set at the Area level, at the container object level, or at the individual object. In
addition, individual alarms within a single object can be enabled, silenced, or disabled.
Enabled: All alarms for an object are reported to client applications and saved as historical data.
The enabled state is less restrictive than the silenced or disabled alarm states.
Silenced: All alarms for an object are detected, saved to history, and sent to alarm clients. But,
alarm clients do not show the alarms. The silenced alarm state is more restricted than the enabled
state, but less restrictive than the disabled state.
Disabled: No alarms for the object are detected. The alarm is return-to-normal until the alarm is
re-enabled. The disabled state is more restrictive than the silenced and enabled alarm states. A
disabled alarm does not require acknowledgement.

System Platform - Part 1

5-10 Module 5 – Alarms and History

LogDataChangeEvent()
The LogDataChangeEvent() script logs an application change event to the Galaxy Historian. The
LogDataChangeEvent() function works only in object scripts, not in symbol scripts.
Syntax: LogDataChangeEvent(AttributeName, Description, OldValue, NewValue, TimeStamp);
A symbol script still compiles if the LogDataChangeEvent() function is included. However, a
warning message is written to the log at run time that the function is inoperable.
This example logs an event when a pump starts or stops with a timestamp of the current time
when the event occurred.
LogDataChangeEvent(TC104.pumpstate, “Pump04”, OldState, NewState);

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

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

Select to use either the Object Description for Alarm Message or type another alarm message in
the Message box. An X appears in the A column of the selected attribute.

Wonderware Training
 Section 1 – Alarms 5-11

For Boolean Label Extension, specify text strings for the False state and the True state, if needed.
These text strings appear in the Active Alarm State list for you to select.
Lock the values, if needed. The lock symbol is available only when you are extending a template.
Otherwise, it indicates the lock condition of the value in the parent object.

Alarm DB Logger Manager Utility

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

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

Alarm DB Logger is an Alarm Consumer. You configure it with an alarm query that defines which
alarms are to be logged. You use the Alarm DB Logger to specify alarm queries and to log the
resultant alarm records. These alarm queries are sent via the Alarm Consumer interface of the
Distributed Alarm System.
The Alarm DB Logger also has the ability to auto-reconnect. When the connection to the database
is lost, the logger continually checks for the database connection at regular intervals. When the
connection is re-established, logging proceeds.
The Alarm DB Logger reports all errors whether running as a service or a normal application to the
Wonderware Logger.

Note: The Alarm DB Logger Manager only saves the setting values into the registry. The utility is
responsible for starting and stopping the Alarm DB Logger. It is also responsible for displaying the
status of Smart Cache. When Alarm DB Logger Manager (almlogwiz.exe) is closed while
wwalmlogger.exe is running (either by pressing the Esc key or by clicking the “X” button on the
upper right of the dialog box), the logging operation does not stop.

The progress control status indicates the percentage fill of the in-memory buffer with alarm
records. The alarms are buffered when the SQL Server connection is down, and/or when the
alarms are coming at a rate faster than the logging rate of Alarm DB Logger.

The Alarm DB Logger Configuration Utility provides you with the ability to:
z Run the application as a Windows Service or as a normal application
z Select the database connection type – SQL Server or MSDE
z Create the necessary SQL tables in the database
z Specify the alarm query that will be a part of the logging instance

System Platform - Part 1

5-12 Module 5 – Alarms and History

z Select the logging mode – Detailed or Consolidated

z Check/Uncheck logging of events
z Set performance tuning parameter – The auto reconnect rate is not the same as the
performance tuning parameter. It depends on the time out for a connection attempt
associated with SQL ServerServer.
z Store the setting in the registry
z Start and Stop the alarm logging process

Logging to SQL Database

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

To use the Alarm DB Logger Manager Utility

a. Start up the Alarm DB Logger Manager: Click Start / All Programs / Wonderware / InTouch
/ Alarm DB Logger Manager.

The Alarm DB Logger Manager dialog box appears.

When minimized, the Alarm DB Logger Manager appears as an icon in the system tray. When
you right-click the icon, a popup menu appears displaying the following commands:
Start – Begins the alarm logging process.
Stop – Ends the alarm logging process.
Settings – Opens the Alarm DB Logger Manager - Configuration dialog box.
Hide Window –Minimizes the Alarm DB Logger Manager dialog box to an icon in the system
tray.
Show Window – Opens and maximizes the Alarm DB Logger Manager dialog box.
Close – Exits the Alarm DB Logger Manager Utility.
b. The Smart Cache Status indicates the percentage fill of the in-memory buffer with alarm
records.
c. Click Settings to configure the Alarm DB Logger. The Alarm DB Logger Manager -
Configuration dialog box appears.
For more information on configuring the Alarm DB Logger, see “Alarm DB Logger
Configuration.”
d. Click Start to begin the alarm logging process.
e. Click Stop to end the alarm logging process.

Wonderware Training
 Lab 15 – Configuring Alarms 5-13

Lab 15 – Configuring Alarms

Introduction
This lab illustrates how to configure your galaxy to provide alarms to external alarm subscribers
such as an operator’s visualization interface or an alarm database logger. As an example of alarm
functionality, a typical high level alarm is added to the mixer, as well as a malfunction alarm from
the mixer’s agitator generated from a field device such as a PLC.
As part of the configuration necessary to accomplish this functionality, it is necessary to update the
auto-configuration script created in the previous lab to accommodate a new input signal
associated with the malfunction alarm.
The Wonderware Alarm DB Logger Manager is used to store real-time alarms in a centralized
database.

Objectives
Upon completion of this lab you will be able to:
z Configure the $WinPlatform object as an alarm provider for the galaxy
z Configure alarms within objects including using the Alarm Extension
z Configure and use the Alarm DB Logger Manager
z Use alarm queries to request real-time alarms from alarm providers

System Platform - Part 1

5-14 Module 5 – Alarms and History

Summary Lab Instructions

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

Configure the WinPlatform object as an Alarm Provider (page 5-18)

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

Configure the $Mixer.LIT template for alarms (page 5-19)

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

Configure the Alarm extension (page 5-20)

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

Update auto-configuration script on $Mixer (page 5-22)

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

View the alarm data on Runtime (page 5-23)

h. Deploy the GRPlatform object on cascade.
i. Using the watch list created in Lab 5, add a new watch window called Alarms and add the
following attribute references:
z LIT_001.PV
z LIT_001.InAlarm
z LIT_001.Hi.InAlarm
z LIT_001.Hi.Limit
z LIT_001.Hi.TimeAlarmOn
z LIT_001.Hi.TimeAlarmOff
z Agitator_001.InAlarm
z Agitator_001.Malfunction
z Agitator_001.Malfunction.InAlarm
z Agitator_001.Malfunction.TimeAlarmOn
z Agitator_001.Malfunction.TimeAlarmOff
z Line1.AlarmOnCnt
j. Save the watch list.

Wonderware Training
 Lab 15 – Configuring Alarms 5-15

Configure and Start the Alarm DB Logger Manager (page 5-25)

k. Use the Alarm DB Logger Manager to create a a database named WWALMDB on your local
computer. Use the following user information:

User Name: sa
Password: [Check with your instructor for the correct password]

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

View the Alarm History data (page 5-29)

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

See the next page for Detailed Lab Instructions

System Platform - Part 1

5-16 Module 5 – Alarms and History

Detailed Lab Instructions

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

Configure the WinPlatform Object as an Alarm Provider

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

The Alarm areas field

is used to specify a
space-separated list of
areas to subscribe to.
It is used to filter
alarms on the network.
For example, "Area1
Area2 Area3". If
blank, the platform will
subscribe to all areas
in the Galaxy and act
as an InTouch alarm
provider for the whole
Galaxy.

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

Wonderware Training
 Lab 15 – Configuring Alarms 5-17

Configure the $Mixer.LIT Template for Alarms

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

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

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

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

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

System Platform - Part 1

5-18 Module 5 – Alarms and History

Configure the Alarm Extension

7. Double-click the $Mixer.Agitator template to open its configuration editor.
8. Select the UDAs tab, add a UDA named Malfunction and configure it as follows:

Data type: Boolean

Category: Object writeable

9. Select the Extensions tab.

Wonderware Training
 Lab 15 – Configuring Alarms 5-19

10. Select the Malfunction attribute.

11. Configure the Malfunction extensions as follows:

Input extension: checked

Source: ---
Alarm extension: checked (locked)
Category: Process
Priority: 500
Alarm message: me.ShortDesc
Active alarm state: True

Ensure the Malfunction attribute is selected before

configuring Input extension.

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

System Platform - Part 1

5-20 Module 5 – Alarms and History

Update Auto-configuration Script on $Mixer

13. Double-click the $Mixer template to open its configuration editor.
14. Select the Scripts tab.
15. Select the AssignIO script and add the following line of code to the Configure agitator section
of the code:
Me.Agitator.Malfunction.InputSource = dataSource + “_AG_Malfunction”;

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

Wonderware Training
 Lab 15 – Configuring Alarms 5-21

The ArchestrA IDE should now look similar to the following:

View the Alarm Data in Runtime

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

18. Click Close when deployment is complete.

19. Right-click on the LIT_001 instance and select View in Object Viewer.

System Platform - Part 1

5-22 Module 5 – Alarms and History

Note: If Object Viewer was open during undeployment, you will see the following error
message. Click the OK button to close and then re-open Object Viewer from the ArchestrA
IDE.

20. Load your saved Watch List.

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

24. Save the watch list.

Wonderware Training
 Lab 15 – Configuring Alarms 5-23

Configure and Start the Alarm DB Logger Manager.

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

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

Server Name: localhost

Database: WWALMDB
User Info:
User Name: sa
Password: [Check with your instructor for the correct password]
Logging Mode: Detailed

28. Click the Create button

System Platform - Part 1

5-24 Module 5 – Alarms and History

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

29. Click the OK button to continue.

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

30. In the Alarm DB Logger Manager – Configuration dialog box click the Next button to
continue.
31. Configure the Alarm DB Logger Manager – Query Selection dialog box as follows:

From Priority: 1
To Priority: 999
Alarm Query: \Galaxy!ControlSystem
\Galaxy!Discharge
\Galaxy!Intake
\Galaxy!Production

Wonderware Training
 Lab 15 – Configuring Alarms 5-25

32. Click the Next button to continue:

System Platform - Part 1

5-26 Module 5 – Alarms and History

33. At the Alarm DB Logger Manager – Advanced Settings dialog box, leave the default
settings.

34. Click the Finish button.

35. In the Alarm DB Logger Manager window, click the Start button to start the Alarm Database
Logger.

Wonderware Training
 Lab 15 – Configuring Alarms 5-27

When the Alarm Database Logger is started, the Alarm DB Logger Manager window will look
similar to the following:

View the Alarm History Data

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

38. Click the Connect button to continue.

System Platform - Part 1

5-28 Module 5 – Alarms and History

39. In the Object Explorer (left pane) navigate to localhost / Databases / WWALMDB and select
Views to get a list of all the database’s Views in the Object Explorer Details (right pane).

Wonderware Training
 Lab 15 – Configuring Alarms 5-29

40. In the Views list (right pane), right-click on the v_AlarmHistory view and select Open View to
display the current list of alarms logged in the database.
Your data should look similar to the following:

System Platform - Part 1

5-30 Module 5 – Alarms and History

– Intentionally left blank –

Wonderware Training
 Section 2 – Historization 5-31

Section 2 – Historization

Section Objectives
z Familiarize you with the background concept of historization, and
z Enable you to understand details of historizable configuration.

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

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

History Configuration

Historizable Data Types for Attributes

For attribute data to be stored in the historian, a host AppEngine must be configured to send
history data to a Wonderware Historian node. For each object, you can configure attributes of the
following data types to be saved to the Wonderware Historian.
z Float (numerical)
z Double (numerical)
z Integer (numerical)
z Boolean (non-numerical)
z String – Unicode (non-numerical)
z CustomEnum (non-numerical) maps to Historian Integer

System Platform - Part 1

5-32 Module 5 – Alarms and History

z ElapsedTime (numerical) Maps to Historian Float, converted to seconds

z Arrays or portions of arrays are not supported.
z Enum type attributes are saved as Wonderware Historian integer ordinal values.
z 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.
z All numerical attributes sent to the Wonderware Historian are in the engineering units
specified for the attribute. The Wonderware Historian does not scale numerical values.

Configuration of a non-numerical Attribute for Historization

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

Configuration of a numerical Attribute for Historization

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

Dynamic, Automatic Configuration of Wonderware Historian at Object Deploy Time

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

Reconfiguration of Historian at Object Redeploy Time

When an AutomationObject that has been historized is redeployed, the object causes a
reconfiguration of any changes that were caused by the redeploy to be changed in the Historian
product automatically. For example, if the engineering units string for the tag changes from “Deg
F” to “Deg C” upon a redeploy, the Historian configuration database must reflect this change.

Wonderware Training
 Section 2 – Historization 5-33

Reconfiguration of Historian at Object Undeploy Time

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

Historian Installation and Deployment

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

Historian Value Mapping

The update packet to be sent to Historian contains a Value. This value may need to be converted
from the value received from Message Exchange if the received datatype is not one of the native
Historian datatypes as specified below:
Enum – historize as Integer ordinal value
Strings – Historian strings are limited to 512 characters, so truncation may occur. If so, Quality is
set to Uncertain.

NaN Handling
For Float and Double attributes, a potential value is the IEEE NaN encoding for the float or double
representation. NaN values can be generated for attributes that are to be historized. These NaNs
will be accompanied by a Bad OPC Data Quality. In any case, NaN is a valid value that can be
generated for floats and doubles. Unfortunately, Historian clients do not handle NaN properly.
Therefore, ArchestrA will convert the NaN value to a Null value representation just prior to sending
to Historian.

Historian Quality Mapping

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

Historian Timestamp mapping

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

System Platform - Part 1

5-34 Module 5 – Alarms and History

Application Server History Storage Performance

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

Historian extension

You can assign historical extensions to extended attributes that you select from the Extensions tab
of your objects.
After you select the History extension check box to save the data to history associated with the
attribute extension you selected, an X appears in the H column of the Extendable Attributes list to
indicate its data is saved to the historian.
The following are the common historical attributes that you can configure for your system and
application objects.
Force Storage Period: Interval in milliseconds in which an attribute value is saved to the
Historian, regardless of whether the value exceeds its value deadband setting or not. An attribute
value is saved to the Historian at every Force Storage interval. The default value of zero (0)
disables the Force Storage period.
Value Deadband: Threshold value in engineering units, which is the absolute difference between
the current and most recent saved historical values. The current value must exceed the absolute
deadband to be saved as historical data.
The Value Deadband filters out small, momentary value changes from being saved to the
Historian. A new value that is within the range of the deadband is not saved to the Historian. The

Wonderware Training
 Section 2 – Historization 5-35

default value of 0.0 disables the Value Deadband and any change to a value is saved as historical
data.
Interpolation Type: List of methods used by the Historian to interpolate analog historical data.
The interpolation type determines which analog value is selected during a Historian data retrieval
cycle. Interpolation types include System Default, Stairstep, or Linear. The default interpolation
type is System Default.
Stairstep: No interpolation occurs. The last known value is returned with the given cycle time. If no
valid value can be found, a NULL is returned to the Historian.
Linear: The Historian calculates a new value at the given cycle time by interpolating between the
last known value prior to the cycle time and the first value after the cycle time.
System Default: The Wonderware Historian system-wide interpolation setting. The system-wide
setting must be either stairstep or linear interpolated.
Rollover Value: Positive integer value that represents a tag’s reset limit when the Historian
operates in counter retrieval mode. In counter retrieval mode the Historian uses a tag's rollover
value to calculate and return the delta change between consecutive retrieval cycles. The default
value is 0.0.
The Rollover value applies only to numeric attributes. The Rollover value is disabled if the
historical attribute data type is Boolean or a string.
Trend Hi: Initial maximum trend value in engineering units for clients. The default is 100.
Trend Lo: Initial minimum trend value in engineering units for clients. The default is 0.0.
Sample Count: Integer that indicates the number of samples the Historian should store in the
active image for an attribute value. Acceptable range of values is from 0 to 9999. The Historian
enforces a sample count of 65 for the active image.
If the current sample count for the active image is 65, and you set the sample count to a value less
than or equal to 65, the new sample count setting is not saved to the Historian database, and the
active image count remains at 65.
If the current sample count for the active image is greater than 65, and you set the sample count to
a value less than or equal to 65, the new sample count is saved to the Historian database and 65
is used by the active image.
Regardless of the current sample count for the active image, if you set the sample count to a value
greater than 65, the new sample count is saved to the Historian database and used by the active
image.
Enable Swinging Door: A flag that indicates whether the swinging door rate deadband is enabled
or disabled. The default is disabled.
Enable Swinging Door is disabled if the historical attribute data type is Boolean or a string.
Rate Deadband: Percentage rate of change deadband based on the change in the slope of
incoming data values to the Historian. For example, specifying a swinging door rate deadband of
10 percent means that data is saved to the Historian if the percentage change in slope of
consecutive data values exceeds 10 percent.
The default is 0.0, which indicates a swinging door rate deadband is not applied. Any percentage
greater than 0.0 can be assigned to the rate deadband.

System Platform - Part 1

5-36 Module 5 – Alarms and History

– Intentionally left blank –

Wonderware Training
 Lab 16 – Configuring History 5-37

Lab 16 – Configuring History

Introduction
In this lab you are to configure your galaxy for historization to your local Wonderware Historian
server. As an example, the mixer’s level and state of the Inlet Valve 1 is configured, as well as the
speed of the mixer’s agitator.
Although ActiveFactory Trend is outside the scope of this class, you will use it this lab as a quick
and simple way to retrieve history data from the history database.

Objectives
Upon completion of this lab you will be able to:
z Configure the $AppEngine object to store history data to a Wonderware Historian
z Configure attributes within objects for historization including the History Extension

System Platform - Part 1

5-38 Module 5 – Alarms and History

Summary Lab Instructions

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

Configure the WinPlatform object (page 5-41)

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

Configure the AppEngine object for History (page 5-42)

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

Configure the $Mixer.LIT template for History (page 5-43)

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

Configure the $Mixer.Inlet1 template for History (page 5-43)

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

Configure the History extension for the $Mixer.Agitator template (page 5-44)
g. Extend the Speed attribute of the $Mixer.Agitator template for historization using RPM as the
engineering units.
h. Lock the history extension.

View the History data with ActiveFactory Trend (page 5-44)

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 16 – Configuring History 5-39

Detailed Lab Instructions

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

Configure the WinPlatform Object

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

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

System Platform - Part 1

5-40 Module 5 – Alarms and History

Configure the AppEngine Object for History

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

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

Wonderware Training
 Lab 16 – Configuring History 5-41

Configure the $Mixer.LIT Template for History

7. Double-click the $Mixer.LIT template to open its configuration editor.
8. Select the History tab and check the PV box to historize the PV attribute. Leave the default
values and lock all attributes by clicking the lock on Historize.

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

Configure the $Mixer.Inlet1 Template for History

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

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

System Platform - Part 1

5-42 Module 5 – Alarms and History

Configure the History extension for the $Mixer.Agitator template

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

Ensure the Speed Attribute is selected before

configuring History extension.

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

View the History Data with ActiveFactory Trend

18. Deploy the GRPlatform object using the default Cascade Deploy.
19. Start ActiveFactory Trend by selecting Start / All Programs / Wonderware / ActiveFactory /
Trend.

Wonderware Training
 Lab 16 – Configuring History 5-43

20. Configure the Server List Configuration as follows and click the Add button:
Server: LOCALHOST
Authentication information:
Use Integrated security: checked

21. After the server has being added to the Server list click the Close button.

System Platform - Part 1

5-44 Module 5 – Alarms and History

22. With LOCALHOST selected on the Servers pane (top-left pane), you will see the attribute
references configured for historization in the Tags pane (bottom-left pane).

Wonderware Training
 Lab 16 – Configuring History 5-45

23. In the Tags pane (bottom-left) double-click the following tags to add them to the trend:
z Agitator_001.Speed
z Inlet1_001.PV
z LIT_001.PV

24. Click on the Live Mode button to configure the Trend to update automatically.
ActiveFactory Trend displays a graphical representation of the history data recorded for the
selected tags. Notice in this example the first half of the graph is blank. The blank section reflects
the time period before deployment, when no data was available.

System Platform - Part 1

5-46 Module 5 – Alarms and History

– Intentionally left blank –

Wonderware Training
 Module 6

Security
Section 1 – Security Overview 6-3
Lab 17 – Security 6-13
6-2 Module 6 – Security

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

Wonderware Training
 Section 1 – Security Overview 6-3

Section 1 – Security Overview

Section Objective
Introduce Security with Wonderware Application Server.

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

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

The ArchestrA Security Model

See the image below for a visual hierarchical overview of the ArchestrA security model. This
shows the relationships of the objects in the Security Model to each other and to the rest of the
ArchestrA System.

System Platform - Part 1

6-4 Module 6 – Security

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

Wonderware Training
 Section 1 – Security Overview 6-5

Authentication Mode

System Platform - Part 1

6-6 Module 6 – Security

On the Authentication Mode page, choose the mode of Galaxy security:

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

Note: When you select Authentication Modes, note the messages relevant to your ArchestrA
installation that are displayed in the Note box.

Wonderware Training
 Section 1 – Security Overview 6-7

Authentication Mode selections provide the following general results:

z Open security gives all users the Defaultuser credentials. No login dialog boxes are
presented to users during configuration, administration or runtime operations. Login dialog
boxes are presented for all other Authentication Modes.
z 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.
z 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.
z When you switch to None from another Authentication Mode and click OK, the
ArchestrA IDE is shut down.
z 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.
z 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.
z 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.

z A user can have multiple accounts within the security system. For instance, a user may
have an account that provides permissions for working with instances but not templates.
The same person may have another supervisory account for working with templates and
managing users in the ArchestrA environment. To switch between levels of authority, the
person must login as the new user. To do this, click Change User on the Galaxy menu.
If the Security is not enabled then Authentication mode is disabled.

System Platform - Part 1

6-8 Module 6 – Security

OS Group Based Security

If you use OS Group Based Authentication Mode, you should first familiarize yourself indepth with
the functions of the Windows operating system, particularly its user permissions, groups and
security features. ArchestrA OS Group Based security leverages those Windows features.
Take note of the following behaviors that are unique to OS Group Based Authentication Mode:
z A newly-added user working on a computer that has no access to the Galaxy node cannot
write to an attribute on a remote node if that user has never logged on to the remote node.
This is true even if the user has been given sufficient runtime operational permissions to
do writes. To enable remote writing capabilities, log on to the remote node at least once.
z If you log in to ArchestrA on a workstation that belongs to Domain A and Domain
Controller A fails, locally cached login data is used on subsequent logins. When the
domain controller returns to operation, your login will fail during the time period that trusts
are being reestablished by the controller. If during the controller outage, your username/
password data was changed, you may be able to use the old login data if you intend to
work locally. If you want to perform remote operations, you should attempt to log in with
the new login data. If that fails, the trusts are being reestablished by the controller, and
you should retry at a later time.

Wonderware Training
 Section 1 – Security Overview 6-9

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

User Authentication
Client utilities like ArchestrA IDE, SMC, and InTouch for System Platform require their users to be
authenticated so that the appropriate permissions can be confirmed. An authenticated user is
granted the sum of all Permissions within their assumed Roles.

Supported Operating System User Configurations

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

Supported Operating System Security Configurations

The following list of OS security configurations will be supported:
z Machines and users participating in a domain.
z Users being drawn from multiple domains.
z Machines and users defined within a Workgroup. Note the users/groups have been
defined on each machine and imported into the Galaxy Repository (GR) and defined as
Local Host.

System Platform - Part 1

6-10 Module 6 – Security

Minimal Operating System Permissions Required for Starting OS User

The OS user account must not be required to have any special privileges to enable it to utilize the
client utilities. Specifically it must not require the user to be an Administrator on the host machine.
The user will be able to change their own OS password from within the ArchestrA utility.

Logon Dialog
If security is enabled within the Galaxy, a client utility Logon dialog will be displayed. Application
Server provides a standard login dialog.
The login appears:
z The user explicitly chooses a Log On option from within the user interface. It is not
necessary to explicitly Log Off before logging on using a different User Profile. The
previous user will be implicitly logged off.
Username and Password are entered onto this dialog.
If OS Authorization is being used then the user will also be required to select from a list of
accessible domain name for the user being logged in.

Wonderware Training
 Section 1 – Security Overview 6-11

Attribute Security Classifications

Attribute SecurityClassifications classify Attributes of AutomationObjects (like the previously
discussed Command attribute) from a security perspective. They are:
z FreeAccess – Any User can write to these attributes to perform safety or time critical
tasks that could be hampered by an untimely logon request (for example halting a failing
process). This does not require the user to have any privileges.
z Operate – Operators write to these attributes during normal day-to-day operations. These
include Attributes such as Setpoint, Output and Control Mode for a PID Object, Command
for a Discrete Device Object, etc. This requires the user to be assigned to the Security
Group of this AutomationObject, to allow the write.
z Secured Write – Operators write to these attributes for normal interaction with a highly
secured object forces re-authentication. This requires the user to be assigned to the
Security Group of this AutomationObject, to allow the write. The AutomationObject will
reject the write requested via the return status and the user must re-enter the login details.
z Verified Write – Operators write to these attributes for normal interaction with a very
highly secured object. This is similar to Secured Write, however it also requires a second
user authentication. The second user must also be assigned to the Security Group of this
AutomationObject, to allow the write.
z Tune – Writing to these attributes is considered a tuning activity. Examples are attributes
that adjust alarm setpoints, PID sensitivity, etc. This requires the user to be assigned to
the Security Group of this AutomationObject, to allow the write.
z Configure – Writing to these attributes is considered a significant configuration change.
For example, a PLC register that defines a Discrete Device input. This requires the user to
be assigned to the Security Group of this AutomationObject, to allow the write. It also
requires that the Object is currently OffScan.
z Read-Only – The attributes are never written to at runtime, regardless of the user's
permissions.
There are two other situations where an Attribute's Security Classifications are specified:
z When a User-Defined Attribute is configured.
z When an Engineer overrides the Attribute Security Classification within a Template editor.

Note: Overriding Security Classifications is not permitted within Instances.

System Platform - Part 1

6-12 Module 6 – Security

– Intentionally left blank –

Wonderware Training
 Lab 17 – Security 6-13

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

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

Objectives
Upon completion of this lab you will be able to:
z Configure the security classifications for individual attributes within automation objects
z Configure the security settings for a galaxy
z Record and view the security audit trail for a galaxy

System Platform - Part 1

6-14 Module 6 – Security

Summary Lab Instructions

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

Import the SecurityTest Object (page 6-17)

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

Configure the SecurityTest object (page 6-19)

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

Att1_FreeAccess: Free Access

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

Create and deploy an instance of SecurityTest (page 6-20)

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

Configure Security for the Galaxy (page 6-22)

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

Wonderware Training
 Lab 17 – Security 6-15

i. Add a new role named Operators with the following permissions:

No General permissions
No Operational permissions for the Default security group
Configure the Operational permissions section for the TestGroup security group as follows:

Can acknowledge Alarms: checked

Can modify “Configure” attributes: unchecked
Can modify “Operate” attributes: checked
Can modify “Tune” attributes: unchecked

j. Add a new role named Supervisors with the following permissions:

No General permissions.
No Operational permissions for the Default security group.
Configure the Operational permissions section for the TestGroup security group as follows:

Can acknowledge Alarms: unchecked

Can modify “Configure” attributes: unchecked
Can modify “Operate” attributes: unchecked
Can modify “Tune” attributes: checked

k. Add a new role named Engineers with the following permissions:

Configure the General permissions as follows:
IDE Permissions: checked (this will check every box within the node)
Framework Configuration: unchecked
SMC Permissions: checked (this will check every box within the node)
Configure the Operational permissions for the TestGroup security group as follows:

Can acknowledge Alarms: unchecked

Can modify “Configure” attributes: checked
Can modify “Operate” attributes: unchecked
Can modify “Tune” attributes: unchecked

l. Configure the Administrator role with all Operational permissions.

m. Add a new user named HOper with a full name of Homer Operator and make it part of the
Operators role. Assign ww as the password.
n. Add a new user named JSup with a full name of Joe Supervisor and make it part of the
Operators and Supervisors role. Assign ww as the password.
o. Add a new user named WEng with a full name of Will Engineer and make it part of the
Engineers role. Assign ww as the password.

System Platform - Part 1

6-16 Module 6 – Security

Test General permissions (page 6-36)

p. Verify that the WEng user cannot modify the security configuration through the ArchestrA IDE.

Test Operational permissions (page 6-38)

q. Login as Administrator and deploy the SecurityTest_001 object.
r. Using the watch list created in Lab 5, add a new watch window called Security and add the
following attribute references:

Object Name Attribute Name

SecurityTest_001 Att1_FreeAccess
SecurityTest_001 Att2_Operate
SecurityTest_001 Att3_SecuredWrite
SecurityTest_001 Att4_VerifiedWrite
SecurityTest_001 Att5_Tune
SecurityTest_001 Att6_Configure
SecurityTest_001 Att7_ReadOnly
SecurityTest_001 ScanState
SecurityTest_001 ScanStateCmd

s. Save the watch list.

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

View the Security Audit Trail (page 6-39)

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

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 17 – Security 6-17

Detailed Lab Instructions

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

Import the SecurityTest Object

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

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

3. Click the Open button.

System Platform - Part 1

6-18 Module 6 – Security

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

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

5. Click Close when the Import is complete.

Wonderware Training
 Lab 17 – Security 6-19

The imported object now appears in the Application template toolset:

6. Move the $SecurityTest to the Training template toolset.

Configure the SecurityTest object

7. Double-click the $SecurityTest template to open its configuration editor.
8. Select the UDAs tab.

9. Select the Att1_FreeAccess UDA and click the Shield icon to select the security
classification for the attribute.
10. Select the Free Access security classification from the popup menu.

System Platform - Part 1

6-20 Module 6 – Security

11. Repeat steps 9 and 10 to configure the security classifications for the following attributes:

Att2_Operate: Operate

Att3_SecuredWrite: Secured Write

Att4_VerifiedWrite: Verified Write

Att5_Tune: Tune

Att6_Configure: Configure

Att7_ReadOnly: Read Only

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

Create and deploy an instance of SecurityTest

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

15. Deploy the newly created instance.

Wonderware Training
 Lab 17 – Security 6-21

16. Click Close when deployment is complete.

System Platform - Part 1

6-22 Module 6 – Security

Configure Security for the Galaxy

17. From the Galaxy menu, select Configure / Security to enable and configure security for the
Galaxy.
18. Select Galaxy for the Authentication Mode.

Wonderware Training
 Lab 17 – Security 6-23

19. Select the Security Groups tab.

System Platform - Part 1

6-24 Module 6 – Security

20. Click the plus icon button to add a new security group. Name the new security group
TestGroup.

Wonderware Training
 Lab 17 – Security 6-25

21. Select the Default security group and locate the SecurityTest_001 instance in the objects list
(right pane).
22. Drag-and-drop the SecurityTest_001 instance to the TestGroup in the security group list (left
pane).

System Platform - Part 1

6-26 Module 6 – Security

23. Select the TestGroup security group to confirm SecurityTest_001 appears as an object in the
TestGroup security group.

Important! Make sure that you are moving the object’s instance (SecurityTest_001) and
NOT the object’s template ($SecurityTest).

Wonderware Training
 Lab 17 – Security 6-27

24. Select the Roles tab.

25. From the Roles available list, select the Default role and configure the permissions as
follows:

In the General permissions section:

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

Note: The Can Write to GObject Attribute using ObjectViewer permission will allow everyone
(the Default role applies to every user) to modify attribute values using Object Viewer.

System Platform - Part 1

6-28 Module 6 – Security

26. Click the plus icon button to add a new role and name it Operators.
27. Configure the Operational permissions for the TestGroup security group as follows:

Can acknowledge Alarms: checked

Can modify “Configure” attributes: unchecked
Can modify “Operate” attributes: checked
Can modify “Tune” attributes: unchecked

Wonderware Training
 Lab 17 – Security 6-29

28. Click the plus icon button to add a new role and name it Supervisors.
29. Configure the Operational permissions for the TestGroup security group as follows:

Can acknowledge Alarms: unchecked

Can modify “Configure” attributes: unchecked
Can modify “Operate” attributes: unchecked
Can modify “Tune” attributes: checked

System Platform - Part 1

6-30 Module 6 – Security

30. Click the plus icon button to add a new role and name it Engineers.
31. Configure the General permissions as follows:

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

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

Can Acknowledge Alarms: unchecked

Can Modify “Configure” Attributes: checked
Can Modify “Operate” Attributes: unchecked
Can modify “Tune” attributes: unchecked

Wonderware Training
 Lab 17 – Security 6-31

33. Select the Administrator role and configure the Operational permissions for the TestGroup
security group as follows:
TestGroup: checked (this will check every box within the group)

34. Select the Users tab.

System Platform - Part 1

6-32 Module 6 – Security

35. Click the plus icon button to add a new user and name it HOper.
36. Double-click on the Full name field and enter Homer Operator.
37. Check the checkbox in front of Operators to assign it to the Operators role.

Wonderware Training
 Lab 17 – Security 6-33

38. With HOper selected, click on the Change Password button, enter the following information
in the Change Password dialog box.

Old Password: [blank]

New Password: ww
Confirm New Password: ww

39. Click the OK button to continue.

40. Click the plus icon button to add a new user and name it JSup.
41. Double-click on the Full name field and enter Joe Supervisor.

System Platform - Part 1

6-34 Module 6 – Security

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

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

43. With JSup selected, click on the Change Password button, enter the following information in
the Change Password dialog box.

Old Password: [blank]

New Password: ww
Confirm New Password: ww

44. Click the OK button to continue.

45. Click the plus icon button to add a new user and name it WEng.
46. Double-click on the Full name field and enter Will Engineer.
47. Assign the user to the Engineers role.

Wonderware Training
Lab 17 – Security 6-35

System Platform - Part 1

6-36 Module 6 – Security

48. With WEng selected, click on the Change Password button, enter the following information in
the Change Password dialog box.

Old Password: [blank]

New Password: ww
Confirm New Password: ww

49. Click the OK button to continue.

50. In the Configure Security dialog box, click OK to accept the security configuration.
51. In the Change User dialog box, enter the following information.
User name: WEng
Password: ww

52. Click the OK button to log in.

Test General permissions

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

54. Click No to dismiss the dialog box.

Wonderware Training
 Lab 17 – Security 6-37

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

56. Enter Administrator for the User name.

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

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

System Platform - Part 1

6-38 Module 6 – Security

Test Operational permissions

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

58. Deploy the SecurityTest_001 object.

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

63. Save the watch list.

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

Wonderware Training
 Lab 17 – Security 6-39

66. Enter the user’s credentials in the Change User dialog box.

67. Click the OK button.

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

View the Security Audit Trail

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

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

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

70. Click the Connect button to continue.

System Platform - Part 1

6-40 Module 6 – Security

71. In the Object Explorer (left pane) navigate to localhost / Databases / WWALMDB / Views to
get a list of all the database’s Views in the Object Explorer Details (right pane).

Wonderware Training
 Lab 17 – Security 6-41

72. In the Views list (right pane), right-click on the v_EventHistory view and select Open View to
display the current list of events logged in the database.

System Platform - Part 1

6-42 Module 6 – Security

– Intentionally left blank –

Wonderware Training
 Module 7

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

Module Objectives
Obtain an overview and understanding of:
z Exporting and Importing Objects
z Configuring Instances Through a .csv File Using Galaxy Dump and Load
z Using the System Management Console to manage platforms
z Using the Network Account Utility

Wonderware Training
 Section 1 – Exporting and Importing Objects 7-3

Section 1 – Exporting and Importing Objects

Section Objective
z This section discusses some fundamental functions dealing with Galaxy Maintenance.
Specifically, it illustrates how to Export for future use and how to Import a galaxy created
previously.

This section provides an understanding of fundamental functions dealing with Galaxy

Maintenance. Specifically, it illustrates how to Export for future use and how to Import a galaxy
created previously.

Exporting Automation Objects

Use the ArchestrA IDE’s export function to share objects with other users or to recreate them in
other Galaxies. The resulting file (.aaPKG extension) contains the selected objects, their
associated templates and the configuration state of those objects. The export file can later be
imported into the same or another Galaxy.
Subsequent exports retain the default folder as last used for the duration of the ArchestrA IDE
session. If the designated file already exists, you are prompted to confirm overwrite.
If any of the selected objects are currently checked out, only the checked in versions are exported.
Exporting an entire Galaxy is similar to using the Galaxy Database Manager utility to back up the
database. However the change logs for the objects are not exported while they are saved during
backup. Also, the backup process retains security model settings for objects while exporting them
does not.
When exporting an object instance, it will also include the parents of that object all the way back to
and including the base template.

Note: When exporting an object that uses a script function, the script function is not transferred
with it. You must ensure that the script function libraries are transferred separately.

System Platform - Part 1

7-4 Module 7 – Galaxy Maintenance

To export an object
a. Select an object in the Template Toolbox or Application Views pane.
b. From the Galaxy menu, select Export/AutomationObject(s).

Note: You can export more than one object with this function by first multi-selecting objects
(Shift+Click or Ctrl+Click). If you want to export all of the objects in the Galaxy, point to
Export and then click All AutomationObjects.

Wonderware Training
 Section 1 – Exporting and Importing Objects 7-5

c. The Export Automation Object(s) dialog box appears.

In the Export Automation Object(s) dialog box, browse to the path and filename (.aaPKG
extension) of the export file and click Save. Click Cancel to terminate the export function. If
you click Save, a progress box is displayed.

System Platform - Part 1

7-6 Module 7 – Galaxy Maintenance

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

Note: Export maintains containment relationships that were previously specified. Also, if an
object is currently checked out, the last checked in version of the object's configuration is
exported.

Exporting All Automation Objects

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

Note: When exporting an object that uses a script function, the script function is not transferred
with it. You must ensure that the script function libraries are transferred separately.

Wonderware Training
 Section 1 – Exporting and Importing Objects 7-7

To export all automation objects

a. From the Galaxy menu, select Export/All Object(s).

System Platform - Part 1

7-8 Module 7 – Galaxy Maintenance

b. The Export All Automation Objects dialog box appears.

In the Export AutomationObject(s) dialog box, browse to the path and filename (.aaPKG
extension) of the export file and click Save. Click Cancel to terminate the export function. If
you click Save, a progress box is displayed.

Wonderware Training
 Section 1 – Exporting and Importing Objects 7-9

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

One key factor to mention is that the security model settings for objects does NOT get exported
when using the Export function. In order to export those you would have to use the Backup
process in the Galaxy Database Manager in the System Management Console (SMC)
discussed in the next Section of this manual.

Importing Automation Objects

Objects can be reused from another Galaxy in your Galaxy. This saves time if the objects are
already set up in another Galaxy.
Importing instances previously exported from a Galaxy retains previous associations, when
possible, such as assignment, containment, derivation, and area.
Objects can be imported from exported .aaPKG files or from an .aaPDF file. An .aaPDF file
contains the configuration data and implementation code for one or more base templates. It is
created by a developer using the ArchestrA Object Toolkit.
Before starting, you cannot have two objects with the same name or more than one copy of the
same version of an object in the same Galaxy. When you import an object, these conflicts are
identified and you can manage them.

System Platform - Part 1

7-10 Module 7 – Galaxy Maintenance

To import Automation objects

a. On the Galaxy menu, select Import/Object(s).

Wonderware Training
 Section 1 – Exporting and Importing Objects 7-11

b. The Import AutomationObject(s) dialog box appears.

Browse for the file with either a .aaPKG or a .aaPDF extension. You can select more than one
file. Click Open.

System Platform - Part 1

7-12 Module 7 – Galaxy Maintenance

c. The Import Preferences dialog box appears.

In the Objects from same toolkit and vendor area, select one of the following:
Skip objects with same conflict or newer codebase leaves the existing object
unchanged.
Overwrite objects with name conflicts if their configuration version is higher
replaces the existing object with the object being imported if the codebases are the same
and the imported object has been edited more often than the existing object.
Migrate objects with a newer codebase also overwrites existing objects if the
codebases (versions) are the same. In addition, this option will migrate the state of
existing objects to the newly imported version if the object supports it. For more
information about migrating, see the Application Server Installation Guide.
In the Objects from different toolkits and/or vendor but with same tagname area, select
one of the following:
Skip does not import the object when a name match exists in the Galaxy.
Rename Object in Galaxy renames the existing object by appending to its current name
the string (up to four characters) you type in the Append to Object Name box. The default
value is _old but you can change it to any four- character string.
Rename Importing Object renames the object being imported by appending to its current
name the string (up to four characters) you type in the Append to Object Name box. The
default value is _new, but you can change it to any four-character string.

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

Click OK to start the import process.

When the import process is complete, you can start using the objects you imported.

Wonderware Training
 Section 2 – Configuring Instances Through a .CSV File 7-13

Section 2 – Configuring Instances Through a .CSV File

Section Objective
z This section discusses some fundamental functions dealing with Galaxy Maintenance.
Specifically, it illustrates how to Export a galaxy for future use and how to Import a galaxy
created previously.

This section provides an understanding of fundamental functions dealing with Galaxy

Maintenance. Specifically, it illustrates how to Export for future use and how to Import a galaxy
created previously.

Galaxy Dump
Object instances and their configuration data can be exported to a comma-delimited format Galaxy
dump file (.csv extension).
The Galaxy Dump function only dumps instances. Templates cannot be dumped. The .csv file
contains the configuration for the checked in versions of the selected objects as well as the
checked-out objects of the user who initiates the Galaxy dump. The file contains only those
attributes that are unlocked and configuration time-writeable, one column per attribute. Attributes
that are locked, calculated or runtime writeable only are not saved to the file. Attributes that are not
text based (for example, type QualifiedStruct) are not dumped. Object Help files are not dumped.
To export objects to a Galaxy dump file:
a. Select an object in the Application Views pane. You can export more than one instance with
this function by first multi-selecting objects (Shift+Click). Also, you can dump all instances
derived from a template by selecting just the template.

System Platform - Part 1

7-14 Module 7 – Galaxy Maintenance

b. Select Export on the Galaxy menu and then click Galaxy Dump.

The Galaxy Dump dialog box is displayed.

c. Browse to the name and location of the .csv file to which you want to dump the selected
instances. Click Save to continue or Cancel to end the export function. The Galaxy Dump
progress box is displayed.

Wonderware Training
 Section 2 – Configuring Instances Through a .CSV File 7-15

d. After the Galaxy dump process is finished, click Close. A .csv file has been created containing
the selected objects and configuration data.

The actual .csv file has been created.

System Platform - Part 1

7-16 Module 7 – Galaxy Maintenance

Galaxy Dump File (.csv) Structure

Dumped objects are organized in the resulting .csv file based on the template from which each is
derived. A header row per template indicates the instance’s columns’ reference. Comments can
be added in the resulting .csv file by adding a line preceded by a semi-colon.

Note: Carriage returns in scripts associated with dumped objects are replaced with “\n” in the .csv
file. If you edit the dump file, do not delete the “\n” characters. If you edit scripts in the dump file,
use “\n” for a carriage return. This character set is interpreted as a carriage return when the dump
file is used in a Galaxy Load function. When editing a script in a dump file, use “\\n” if you want to
include the character “\” followed by the character “n” in a script. This character set is not
converted to a carriage return in a Galaxy Load function.

Wonderware Training
 Section 2 – Configuring Instances Through a .CSV File 7-17

Galaxy Load
Object instances and their configuration data in an existing Galaxy can be exported to a comma-
delimited format Galaxy dump file (.csv extension). A .csv file can be edited in most text editors
and spreadsheet programs. Using editing functions like copy and paste, you can create quantities
of already-configured objects ready to be imported into your Galaxy.

Note: The contents of the .csv file is determined by the original Galaxy dump. A load file contains
only instances. Templates cannot be dumped and loaded.

Important: The Dump contains only Object Instances. For the Load to succeed, the templates
from which those objects were derived must already exist in the Galaxy.

To import a .csv file

a. Select Import on the Galaxy menu and then click Galaxy Load.

The Galaxy Load dialog box is displayed.

System Platform - Part 1

7-18 Module 7 – Galaxy Maintenance

b. In the Galaxy Load dialog box, browse to locate the .csv file that contains the objects and
configuration data you want to import.
Select the file and click Open to continue or Cancel to end the import function.

Wonderware Training
 Section 2 – Configuring Instances Through a .CSV File 7-19

The Galaxy Load Conflict Resolution dialog box is displayed. Use it to resolve conflicts that
occur if objects you want to load already exist in the Galaxy. The options are:
z Replace entire instance if an instance of an object with the same name already
exists and you want to replace it entirely with the object in the import file.
z 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.
z Skip if an instance with the same name already exists and you want to keep the
version already in the Galaxy.
z Stop Galaxy Load if an instance with the same name already exists and you want to
cancel the Galaxy Load.

c. Choose the preferred conflict resolution and click OK. A progress box is displayed during the
Galaxy load process. Click Cancel to terminate the Galaxy load process.

A Galaxy Load dialog box appears indicating that the Load was successful.
All objects that were changed or created during the Galaxy Load process are checked out to
the logged in user.

Note: A comment line in a .csv file created in Microsoft® Excel may create an unintended
default-value object. To avoid this scenario, open the .csv file in Notepad to ensure the
comment line does not contain quote marks.

System Platform - Part 1

7-20 Module 7 – Galaxy Maintenance

– Intentionally left blank –

Wonderware Training
 Section 3 – System Management Console (SMC) 7-21

Section 3 – System Management Console (SMC)

Section Objectives
z Effectively utilize the System Management Console
z Configure the System Management Console

This section provides an understanding of role of the System Management Console and how it can
be configured.

About System Management Console

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

System Platform - Part 1

7-22 Module 7 – Galaxy Maintenance

To Start the System Management Console

Start Windows and click Start. Select All Programs/Wonderware/System Management
Console.

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:
z Galaxy Database Manager (GR Node only)
z DAServer Manager (DAServer or WinPlatform deployed)
z Log Viewer (all Wonderware nodes)
z Platform Manager (all Application Server nodes)
z Other snap-ins (for example IndustrialSQL Server) will be available when other
Wonderware software is installed

Wonderware Training
 Section 3 – System Management Console (SMC) 7-23

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

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

Galaxy Database Manager

Selecting the Galaxy Database Manager on the SMC Menu allows you to view all the galaxies in
the Galaxy Repository, as well as the nodes they reside on.
You must have Administrative privileges to use the Galaxy Database Manager.

Galaxy Backup / Restore

Be sure to back up your Galaxies so that if a Galaxy becomes corrupted, you can restore the
Galaxy. You can choose a backup file to overwrite an existing, corrupted Galaxy or to reproduce a
Galaxy in another Galaxy Repository.
The Galaxy Database Manager is automatically installed on every Galaxy Repository node.
Backup
When running a Galaxy backup, no other applications may write to the GR node. Be sure to
perform the backup operation when no database-write operations will occur.
a. Select the Galaxy to backup, and select Action / Backup.
b. Name the .cab file to be created, and click Save.

c. Click Close when the backup is complete.

System Platform - Part 1

7-24 Module 7 – Galaxy Maintenance

Create a new galaxy with a galaxy backup (.cab) file

You may also create a new galaxy using the .cab file created when a Galaxy backup is performed.
You must first copy the backup .cab file to:
C:\Program Files\ArchestrA\Framework\Bin\BackupGalaxies
In the New Galaxy window, create a new galaxy and select your backup Galaxy in the Galaxy
type field.

Restore
When you restore a database from backup, any information saved to the database since the
backup was performed is overwritten with the restored information. All changes to the database
since the backup are lost. Also, any transactions in progress when the backup was performed are
rolled back.

Wonderware Training
 Section 3 – System Management Console (SMC) 7-25

a. On the Action menu, click Restore.

System Platform - Part 1

7-26 Module 7 – Galaxy Maintenance

b. Click Yes to continue restoring and No to terminate the restore function.

c. Select the name(.cab extension) of the backup file you want to use and click Restore.
If you have an active client connected to the Galaxy Repository, a message appears. You are
required to quit those client programs before restore can continue.
A confirmation dialog box displays when the restore function is finished.

DAServer Manager
The DAServer Manager allows local or remote configuration of the DA Server and its device
groups and items, and can monitor and perform diagnostics on DAServer communication with
PLCs and other devices.
Like the LogViewer and Platform Manager, the DAServer Manager is a Microsoft Management
Console (MMC) snap-in. Many high-level functions and user-interface elements of the DAServer
Manager are universal to all DAServers; to understand the DAServer Manager, it is critical to read
the documentation for both the MMC and the DAServer Manager.
To read the documentation about the MMC and DAServer Manager, click the Help topics on the
SMC Help menu. Both the MMC Help and the DAServer Manager Help are displayed.

Log Viewer
The ArchestrA Logger is a utility that records information regarding the activity occurring on the
computer. For example, it records start-up data, error conditions, and DAServer information.
The Log Viewer can:
z Monitor messages on any machine in the system
z Send a portion of the log to notepad or E-mail
z Filter messages on a flag
When running an ArchestrA application, the Logger runs as a system service. The Log Viewer is a
Microsoft Management Console (MMC) snap-in that provides a user interface for viewing
messages reported to the Logger. The MMC is a host or container utility for the Log Viewer with its
own generic functions.

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

Wonderware Training
 Section 3 – System Management Console (SMC) 7-27

The following commands are available from the System Management Console Action menu when
a platform is selected within the LogViewer tree.

Command Description
Configure Allows configuration of the Log Viewer and Storage
Log Flags Opens the Log Flag editor
Open Log File Allows the opening of a Log File
Connect Allows either local or remote connections configuration
Messages Allows Messages to be exported, purged, or printed
Refresh Refreshed the database
Help Access to the System Management Console Help files

These commands are also available by right-clicking an item in either the console tree or the
details pane. The available commands are dependent on the current state of the object and your
security permissions. If you do not have permission to perform a particular command, then that
command is grayed out.

System Platform - Part 1

7-28 Module 7 – Galaxy Maintenance

The following commands are available from the System Management Console menu when you
select Log Viewer in either the console tree or the details pane.

Command Description
Monitor System messages provide information about the state of the
IndustrialSQL Server historian as it starts up, runs, or shuts down. For
more information about system messages, see System Messages.
Open Log File Use this dialog box to locate and open a log file of saved messages.
Connect Allows the opening of a Log File
About Log Viewer Displays copyright and version information
New Create a new log file.
Refresh Update the contents of the Log File window.
Export List You can export the currently shown log messages to a log file. Log files
have an .aaLGX extension. The default file name is LogExport with the
current date in the format (mmddyyyy) appended as a suffix. You can
edit the name of a log file but not its extension.
Help Access to the System Management Console Help files

Wonderware Training
 Section 3 – System Management Console (SMC) 7-29

The following commands are available from the System Management Console View menu when a
platform is selected within the LogViewer tree.

Command Description
Filter Allows filtering of Messages, Time Range, or Terminal Sessions
Find Search capability on Process ID, Thread ID, Log Flag, Component, or
Message
Go To Allows redirection to a Bookmarked location
Bookmarks Allows Adding or removing of a Bookmark
Mark Allows the entry of a Marker Message to the log
Choose Columns Select specific columns to show or hide
Customize Change the appearance of the view

The Logger and Log Viewer are automatically installed when an ArchestrA component is installed.
z Logger - This is the background process that stores messages and events in the system.
This process occurs without any prompting from or interaction necessary from the user.
The logging process can be customized with the LogFlag Editor Snap-In utility. The
Logger is installed as a system service, and can be configured to be an Auto Service or
Manual Service. As an Auto Service utility, the Logger is started when the PC is booted
up. As a Manual Service utility, the Logger requires a manual start through the System
Services utility in Windows’ Control Panel. In either case, the logging process is always
started when an ArchestrA component begins functioning.
z Log Viewer - This utility is used to view error and informational messages that are sent by
ArchestrA components. The look-and-feel and the format of the user interface can be
customized to suit individual needs.

System Platform - Part 1

7-30 Module 7 – Galaxy Maintenance

Typical Log Viewer Usage

The Log Viewer is primarily a troubleshooting tool. After initially installing an ArchestrA-enabled
program and on occasion, you might check logged messages to determine whether all processes
are functioning well. But typically, you would use the Log Viewer to work through problems you
encounter with a DAServer, the ArchestrA IDE or other ArchestrA component.

Note: The Log Viewer displays error messages in red-highlighted stripes. These indicate
malfunctioning processes and should be resolved quickly. Warning messages are displayed in
yellow stripes. These indicate major events in the system.

A good strategy for troubleshooting problems

a. Gather as much information first about the process that is malfunctioning. For instance, you
attempted to deploy an object in the ArchestrA IDE and a message was displayed stating the
deployment was not completed. Note the function you attempted and the message you
received.
b. Open the Log Viewer by clicking Start, pointing to Programs and then to Wonderware, and
then clicking System Management Console. In the SMC, select Log Viewer and then the
node the ArchestrA IDE is located on. Look for red and yellow messages. Also, use the
information you collected about the failed process to search for clues in the logged messages.
c. Use the Find command on the View menu to single out messages by message text or other
category of data, or use the Filter command on the View menu to reduce the number of
displayed messages based on message, time range or terminal session criteria.
The journey of a Log Message originates with the Application where Log Flags are generated.
These are passed to the Logger where they are then stored in the Log Message Storage. They
are then available for viewing by the LogFlag Viewer. The LogFlag Editor provides the capability
to edit the LogFlags. This is illustrated in the following diagram.

6
LogFlag Editor
LogFlag Viewer
5
2
3
4 1

Wonderware Training
 Section 3 – System Management Console (SMC) 7-31

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

To add a regular bookmark to a message

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

To set a fast bookmark on a message

a. Right-click the message and click Fast Bookmark on the Bookmark submenu. A default
naming sequence is applied to the message (Bookmarkx where x is a number in an ascending
sequence). Alternatively, you can set a fast bookmark by selecting the message and clicking
the Fast Bookmark icon on the toolbar.
b. Change the bookmark name to something more descriptive, if necessary, in the Bookmarks
dialog box at a later time. See "To manage bookmarks" below.

To go to a bookmarked message
a. On the View menu, click Go To.
b. In the Go To dialog box, enter the name of the message’s bookmark by typing it in the box or
selecting from the list.
c. Click Go To. The Go To dialog box remains open.
d. Use the Previous and Next buttons to go to the nearest bookmarked message above and
below, respectively.
e. When you are done searching, click Close.

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

System Platform - Part 1

7-32 Module 7 – Galaxy Maintenance

To manage bookmarks
a. On the View menu, click Bookmarks.
b. In the Bookmarks dialog box, you can manage current bookmarks and create new ones. The
bookmark list shows the current set of bookmark names and associated Message No. (the
same number as the No. column in the message window). The bookmark list provides several
functions.
c. For instance, to rename a bookmark, select it, press F2 and type the new name. Note that
each bookmark must have a unique name; so you cannot bookmark two messages with the
same name.
d. To go to a bookmarked message, double-click on it in the list or select it and click Go To.
e. To remove one or all bookmarks from your logged messages, select a message and click
Remove, or click Remove All.
f. To add a new bookmark, select the message you want to bookmark in the message window
and click Add. This function is comparable to a fast bookmark. Rename it by pressing F2.
g. When you are done, click Close.

Note: Bookmarks are not saved when you quit the Log Viewer application. To mark your
message log more permanently, use the Mark command on the View menu.

Platform Manager
Platform Manager is a common component of an Application Server application and it is available
from any PC node in the application that has a deployed platform; therefore, you do not need to
install it onto each node. This ensures that all nodes used within a galaxy have access to Platform
Manager.
When you use Platform Manager, you can access the platforms and engines deployed to the local
PC node and to any other PC node in the Galaxy. Platform Manager does not require the
GalaxyRepository to be installed on the PC node.
After highlighting a Galaxy or an Engine, you can use the Action menu to start or stop the object,
or set it OnScan/OffScan. If the galaxy has security implemented, you must log on as a user
configured with the proper SMC permissions to start SMC, Start/Stop engines and platforms, or
write from the Object Viewer.
Some of the key features of the Platform Manager are that it:
z Runs with minimal ArchestrA and operating system requirements, equivalent to "Safe
mode"
z Uses the local platform as the gateway to the ArchestrA application
z Does not rely on the Galaxy Repository to exist
z Allows viewing of the layout of the Galaxy Repository, Platforms, and Engines
z Provides the ability to set Platforms and Engines OnScan or OffScan
z Provides the ability to start and stop Platforms and Engines

Wonderware Training
 Section 3 – System Management Console (SMC) 7-33

The Platform Manager appears under the ArchestrA System Management Console (SMC) root
node.

If the Galaxy has security enabled, the Platform Manager Login dialog box appears when the
user attempts to access the Platform Manager from the System Management Console (SMC).

System Platform - Part 1

7-34 Module 7 – Galaxy Maintenance

Console Menu Commands

The following commands are available from the Platform Manager Action menu when you select
a Platform in either the console tree or the details pane.

The following commands are available from the Platform Manager Action menu when you select
an Engine in either the console tree or the details pane.

These commands are also available by right-clicking an item in either the console tree or the
details pane. The available commands are dependant on the current state of the object and your
security permissions. If you do not have permission to perform a particular command, then that
command is grayed out.

Wonderware Training
 Section 4 – Network Account Utility 7-35

Section 4 – Network Account Utility

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

This section discusses the role of changing the network account and how to use the Change
Network Account and how to configure it.

Change Network Account Utility

The Change Network Account utility is a tool you can use to manage credentials for node-to-
node communications between ArchestrA components.
During the initial installation of an ArchestrA component, you are prompted either to create a new
user account or to use an already existing account, and provide a user name and password for
that account. The same account must be used on each computer that requires communication
with others in the ArchestrA environment. Use the Change Network Account utility to change this
data, if necessary, on any computer after installation of an ArchestrA component.
WARNING! If you change user account data with this utility, you could adversely affect
communications between the computer and others with installed ArchestrA components (including
existing Wonderware products that are ArchestrA enabled). All ArchestrA nodes that require
communication with others must use the same account, user name, and password. Use this utility
only to standardize user account data on all computers requiring communication. Do not delete
this account with operating system account management tools. If you do, the ArchestrA IDE will
stop functioning properly. If you delete the ArchestrA user account on an ArchestrA IDE node, you
must recreate it with the Change Network Account utility.

Node-to-Node Communications
All computers that have installed ArchestrA-enabled software must be able to communicate with
each other. This communication is enabled through an ArchestrA-specific user account set up
during the initial installation of an ArchestrA component on each computer.
Subsequent installations of ArchestrA components do not prompt for user account
information. They automatically use the account set up during the installation of the initial
component.
The user account described in this document only enables node-to-node communications
between ArchestrA components. It is not associated with ArchestrA security, which provides user
authentication for individual access points to the infrastructure.

Note: You must have Administrator privileges on the computer to make changes with the Change
Network Account utility.

System Platform - Part 1

7-36 Module 7 – Galaxy Maintenance

To recreate an ArchestrA user account

a. Start the Change Network Account utility by selecting Start/All Programs/Wonderware/
Common/Change Network Account.

The Change Network Account dialog box appears.

Wonderware Training
 Section 4 – Network Account Utility 7-37

The data shown in this dialog box are those settings entered during the initial installation of an
ArchestrA component on the computer. The password options are shown blank for security
reasons.
The Change Network Account utility allows you to change the current data shown in the
dialog box, including:
z Changing the password of the current account.
z Creating a new local user account.
z Using an existing local machine or network domain account.
b. In a single-node ArchestrA system, create any account.
c. In a multi-node ArchestrA system, recreate the same user account with the same user name
and password that was created on all other computers that have installed ArchestrA-enabled
software.
d. Once you have configured the account, click OK.

Note: After you recreate the user account in the Change Network Account dialog box, the
Microsoft Windows security component on your computer may take several minutes to update
this information on the ArchestrA Galaxy node. Until that occurs, your ArchestrA IDE may not
function properly. Rebooting the Galaxy node causes this update to occur immediately.

When you use the Change Network Account utility to create or use an account that is different
from the one originally set up during installation, the old account is maintained (not deleted).
WARNING! After you change any data shown in the Change Network Account dialog box,
ensure that all other computers that have installed ArchestrA-enabled software use the same type
of user account with the same user name and password.

System Platform - Part 1

7-38 Module 7 – Galaxy Maintenance

Error Messages
When using the Change Network Account utility, you may encounter the following error messages.

Error Message Action Required

Administrative privileges are You must have Administrator privileges on the computer to run this
required to run this utility. utility. Click OK, login as a user with Administrator rights, and start the
Change Network Account utility again.
The Password was not correctly You mistyped either the password or confirmation password in the
confirmed. Please ensure that the dialog box. These two passwords must match to ensure the accuracy
Password and Confirmation of user account data. Click OK, retype both password and confirmation
match exactly. password text, and then click OK again.
Password cannot be empty. You must type a password in the Change Network Account utility. Click
Please enter a valid password OK, type a password in the dialog box, type the same password in the
Confirm Password box, and then click OK again.
User account 'a' already exists. You chose to create a local account by selecting Create Local
Please enter another user name. Account in the Change Network Account utility. This account already
exists. Click OK, type a new user name in the Change Network
Account utility, and click OK.
Domain/Local Machine name You must enter an existing local machine or network domain account.
cannot be empty. Click OK, either type a valid network domain name or select the local
machine name from the list, and click OK. If you don’t know the valid
network domain name, ask your network administrator.
User account 'a' does not exist. You chose to use a local machine or network domain account that
Please enter another user name. does not exist. Click OK. Ensure the user account you entered in the
Domain/Local Machine Name box is valid and the user name and
password you typed are valid for that user account, and then click OK.
If this message is displayed again, check with your network
administrator about the existence of the account.
The password policy for this You chose to use a local machine or network domain user account
account allows the password to whose password policy allows the password to be changed or to
expire and to be changed. expire. Click OK if you want to use this account or Cancel to return to
However the password must not the Change Network Account utility. Then, you can choose to use or
expire or should not be changed create another user account.
for the ArchestrA products to
function properly. Do you want to Caution! It is recommend that you do not use a domain account whose
use this account? password expires periodically or can be changed. Using such an
account is allowed, but after the expiration date or the password is
changed, node-to-node communications end. You then must use the
Change Network Account utility on each computer to update the
account data to re-establish communications.
Do you want to update user You chose to use a local machine user account, but the password you
account 'a' to use this new typed does not match the account's password. Click OK if you want to
password? change the password for this user account or Cancel to revert to the
original settings. If you click OK, the password for the account is
changed. If you click Cancel, the Change Network Account utility is
displayed, allowing you to correct the password or type another user
name and password.
Invalid Domain name 'dom'. You typed an invalid network domain name in the Domain/Local
Please enter a valid domain Machine Name box. Click OK, retype the domain name, and click OK.
name.
Invalid Password for user account You chose to use a network domain user account, but the password
'a'. Please enter the correct you typed does not match the account's password. Click OK, correct
password. the password, confirm the password, and click OK.

Wonderware Training
 Section 4 – Network Account Utility 7-39

Error Message Action Required

The system will now reboot. You changed account information in the Change Network Account
Please close all your open utility. The computer must be restarted to implement those changes.
applications and press "OK" when Close open applications, and click OK.
you are done.
User name cannot contain these You used one or more invalid characters in the User Name box. Click
characters: " / \\ [ ] : ; | , + * ? < > OK, type a valid user name and click OK.
Please enter a valid user name.
A user name cannot consist solely You must type a user name in the Change Network Account utility.
of periods [.] or spaces. Click OK, type a user name in the dialog box, and then click OK again.

Multiple NIC Computers

Any node in your Galaxy that contains more than one network card must be configured according
to the following instructions to ensure communications with other ArchestrA nodes.

Note: If a multiple NIC computer in your Galaxy uses only one NIC, you should disable all cards
except the supervisory network.

For any multiple NIC ArchestrA node to communicate successfully with all other Galaxy nodes,
you must define the correct order of network connections in the network services of the computer.
In the Network Connections dialog box (see image below) you may choose to rename each card
with a clearly identifiable function (for instance, “Supervisory Net” and “PLC net”). Different
operating systems provide unique access to the Network Connections dialog box.

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

System Platform - Part 1

7-40 Module 7 – Galaxy Maintenance

Several other parameters must be configured to ensure successful node-to-node communications

in the ArchestrA environment. You must configure the IP address and DNS settings according to
your network setup.

Wonderware Training
 Module 8

Device Integration Products

Section 1 – Wonderware I/O Servers 8-3
Section 2 – Wonderware Data Access Servers 8-9
Section 3 – Device Integration Objects 8-13
8-2 Module 8 – Device Integration Products

Module Objectives
Obtain an overview and understanding of:
z DAServers and DI Objects and how they relate to the connectivity of your application to
external data.
z FactorySuite Gateway and how it can enhance the connectivity of your application.

Wonderware Training
 Section 1 – Wonderware I/O Servers 8-3

Section 1 – Wonderware I/O Servers

Section Objective
z Configure a Wonderware I/O Server (Modbus)

This section will describe the configuration of a Wonderware I/O Server (Modbus).

Introduction
Wonderware I/O Servers are Microsoft Windows application programs that enable other DDE-
aware Windows applications (such as InTouch or Excel) access to data in the real world (such as
PLCs or RTUs).
Wonderware servers are primarily intended for use with Wonderware's InTouch program;
however, they can be used by any Microsoft Windows program capable of acting as a DDE client.
In this section, we will examine the start-up, configuration and use of a Wonderware I/O Server.
Because Wonderware's I/O servers are Windows applications, they will all have the same basic
appearance and capabilities. Keep in mind that depending on server requirements, additional
hardware (network, and so on) may be necessary and the configuration screens may require
additional information.
The following information references the Modbus I/O Server as a point-to-point server using the
RS-232 serial port to PLCs provided at the Wonderware facility training environment. Your
instructor may have you configure the following screens differently.

Note: All I/O Server setup which follows is specific to the Wonderware facility training
environment. Your instructor will provide the proper configuration information. It accesses one
Koyo DirectLogic O5 PLC via its programming port.

Configuring I/O Servers

Once the I/O Server has been installed, some configuration is required. Configuring the server
automatically creates a configuration file named MODBUSDV.CFG. This file stores the
configuration information about communication ports and all of the topic definitions (described in
detail later).
The configuration file is automatically saved to the directory in which the I/O Server is installed
unless a different directory is specified via the Configure / I/O Server Settings command.
a. Select Start / All Programs / Wonderware / IOServers / Modicon MODBUS.
The MODBUS dialog box appears:

b. Click Configure / Com Port Settings.

System Platform - Part 1

8-4 Module 8 – Device Integration Products

The Communication Port Settings dialog box appears. This dialog is used to configure the
communication port that will be used to communicate with the PLC equipment.

Com Port: Select the communication port that is connected to the PLC equipment.
Reply Timeout: Enter the amount of time (in seconds) that all PLCs connected via this serial
communications port will be given to reply to commands from the I/O Server.

Note: This timeout is sustained only when the PLC fails to respond. When the PLC is
responding normally, there is no penalty. The default value of 3 seconds should be sufficient
for most configurations.

Protocol area: Select the protocol configured for the equipment attached to this
communication port. RTU is recommended.
Baud Rate area: Select the baud rate (serial bit rate) setting that matches the equipment
connected to this communication port.
Data Bits area: Select the option for the number of data bits that corresponds to the
configuration of the equipment on this communication port.
If ASCII is selected for the protocol, use 7. If RTU is selected, use 8.
Stop Bits area: Select the appropriate number of stop bits for the communication port. If the
baud rate is greater than 300, the stop bits should be set to 1.
Parity area: Select the setting that corresponds to the configuration of the equipment on this
communication port.

Note: All devices on a single communication port must be configured with the same Protocol,
Parity, Stop Bits, Data Bits and Baud Rate.

Wonderware Training
 Section 1 – Wonderware I/O Servers 8-5

For this training class, the following settings must be configured as shown.
c. Save your changes in the suggested directory and click Done to exit.

Note: Click Save to save the current settings entered for the selected communication port.
The Communication Port Settings dialog box remains displayed and another communication
port can be configured.

System Platform - Part 1

8-6 Module 8 – Device Integration Products

Creating Topic Definitions

The Configure / Topic Definition command is used to create, modify, or delete topic definitions.
One or more topic definitions must exist for each PLC that the I/O Server will communicate with.
Each topic definition must contain a unique name for the PLC associated with it. This unique name
is then used as the topic name portion of the DDE Address for all DDE conversations to that PLC.
a. Click Configure / Topic Definition.
The Topic Definition dialog box appears:

Note: Once topics have been defined, their names will be listed in the Topics pane of this
dialog box.

b. Click New to add a new topic definition.

The MODBUS Topic Definition dialog box appears:

c. Topic Name: Enter a unique name (up to 32-characters long) for the PLC in the field.

Note: When communicating with InTouch, this exact name is used as the topic name in the
Access Name definition.

d. ComPort: Select the communications port to be associated with this topic.

Wonderware Training
 Section 1 – Wonderware I/O Servers 8-7

e. Slave ID: Enter the Slave ID of the PLC in the box.

f. Slave Device Type: Drop-down list contains slave device types other than the default.
g. String Variable Style: The PLC will use this style to store ASCII strings in its registers.
h. Register Type: Select BINARY or BCD, based on hardware used.
i. Block I/O Sizes: Coil Read: Enter the maximum number of consecutive coils to be read at
one time. In this example, the valid coil read values can be between 8 and 2000 and must be
an even multiple of 8.
j. Coil Write: Enter the maximum number of consecutive coils that can be written to at one time.
In this example, the valid coil write values can be between 8 and 800 and must be an even
multiple of 8.
k. Register Read: Enter the maximum number of consecutive registers to be read at one time.
In this example, the valid register read values can be between 1 and 125.
l. Register Write: Enter the maximum number of consecutive registers that can be written to at
one time. In this example, the valid register write values can be between 1 and 100.
m. Update Interval: Enter the frequency (in milliseconds) that the I/O Server will read (poll) the
items/points associated with this topic. Different items/points can be polled at different rates by
defining multiple topic names for the same PLC and setting different update rates for each
topic.
n. Click OK to accept the entries and close the dialog box.
The Topic Definition dialog box will open with the new topic listed:

o. Click the Done button to close this dialog box and return to the server's program window.
p. Click Modify to change an existing topic definition.
q. Click Delete to delete an existing topic definition.

Note: The previous information is provided for example only. Configuration steps for this
class are provided in the following lab.

System Platform - Part 1

8-8 Module 8 – Device Integration Products

– Intentionally left blank –

Wonderware Training
 Section 2 – Wonderware Data Access Servers 8-9

Section 2 – Wonderware Data Access Servers

Section Objective
z Become familiar with Wonderware Data Access Server and its use with Wonderware
Application Server.

This section provides familiarization with Wonderware Data Access Server and its use with
Application Server.

Introduction
Wonderware Data Access (DA) Server is designed to provide simultaneous connectivity between
client applications based on Wonderware SuiteLink, OPC and DDE protocols that run on the
Microsoft Windows operating system and the data devices supported by the specific protocol
being translated.
The Wonderware DAServers also come with an exclusive new user interface called the DAServer
Manager, which is installed as a Microsoft Management Console snap-in. Its end-user benefits
include simple remote server activation, configuration and operation, and extensive protocol
diagnostic troubleshooting.
Several standard features are available with each DAServer, including:
z Compliance with OPC version 3.0
z Stand-alone operation mode
z Support for hot configuration, device additions and device- and server-specific parameter
modifications
A wide range of DAServers support connectivity to numerous protocols and products. A few of the
current DAServers Wonderware includes support for are:
z Allen-Bradley CIP protocol for ControlLogix
z Allen-Bradley TCP protocol
z Allen-Bradley DH Plus protocol
z Siemens Simatic Net S7
z Modbus Serial protocol

Component Architecture
A DAServer is comprised of three physical parts:
z Plug-in Component(s): responsible for communicating with clients, used by all DAServers.
Plug-ins provide protocol translation functionality for device integration clients.
Typical Plug-ins use DDE, SuiteLink or OPC protocol, and serve as interfaces between
their clients and the DAS Engine. A protocol can be disabled when customizing the
installation for your DAServer.
z DAS Engine: common component used by all DAServers.
The DAS Engine is a middleware component that exposes two sets of unique interfaces,
one for communicating with Plug-ins and one for communicating with Device Protocol
Layer components. It encapsulates common tasks for the DAServer, like handling the item
database, distributing data to clients, propagating clients' requests to the protocol, and
providing diagnostics.

System Platform - Part 1

8-10 Module 8 – Device Integration Products

z Device Protocol Layer: Server specific, responsible for communicating with hardware and
specific to the DAServer. The Device Protocol Layer provides translation between the
hardware- specific protocol such as ModBus and CIP and the DAS Engine interface:

Each physical part of a DAServer is comprised of a set of .EXE and/or .DLL modules. ArchestrA
provides the Plug-in and DAS Engine modules.
You must create the Device Protocol Layer (server specific) modules with the DAServer Toolkit,
and all three sets of modules are required for a fully functioning DAServer.

DAServer Characteristics

Configuration
The DAServer Manager is capable of displaying specific configuration pages for all servers. This
utility allows browsing and editing of servers on different nodes.
Recall that DAServers are hot-configurable. In other words, they are configurable while the server
is running or even acquiring data. Certain restrictions imposed by the underlying network/protocol/
hardware might apply.
For instance, if you uncheck System Items on the global parameters configuration dialog of the
DAServer Manager and select Apply, and then re-check System Items and Apply, System Items
data is valid only to newly connected clients.
The configuration data format for DAServers is XML. Any XML-enabled program (for example, IE
and XML Notepad) can read this format.

Runtime
The DAS Engine is loaded by the DAServer as an in-process COM object.
It is not statically linked. In other words, a new DAS Engine (feature enhancement or bug fix)
would not require re-linking to the other components nor re-QA of those other components. It is
deployed to the system and attaches to all existing server components.

Wonderware Training
 Section 2 – Wonderware Data Access Servers 8-11

This is an important added value for the customer to be independent of ArchestrA release cycles,
especially for OEM customers with their own release schedule.
Newly deployed Plug-ins do not require re-linking nor re-QA of associated components. Even new
Plug-ins would not require any development effort for the other components. In fact, it is feasible to
implement new functionality (like Store-and-Forward) in a Plug-in to enhance the server without
involvement of the code of the other components.

Diagnostics
The DAServer Manager diagnostic tool displays generic diagnostic objects common to all servers
as well as server-specific/server developer defined diagnostic data.

Hot Configuration
One of the big advantages provided by the DAServer is the ability to make your DAServer
configurable while the server is running - hot configuration.
The extent to which a specific DAServer is hot configurable varies from server to server. You can
choose from a variety of hot configuration responses, from not being hot configurable at all to
being configurable of each individual parameter while the server is running.
The DAServer handles most of the hot configuration work. In general, a user will run the DAServer
Manager and configure each hierarchy. Any changes she makes that add/delete/update a
hierarchy are sent immediately to the running DAServer.
Server-specific code may elect to react to the change. Some parameters cannot be changed while
the DAServer is running due to protocol-specific issues, and these can be ignored by the server-
specific code.
Here is a complete list of notifications to the server about changes in the configuration:
z Add configuration hierarchy.
z Delete configuration hierarchy.
z Rename configuration hierarchy.
z Update parameters of configuration hierarchy.
z Add device group.
z Delete device group.
z Rename device group.
z Update parameters of device group.
z Clear the current configuration set.
z Switch to a new configuration set.

System Platform - Part 1

8-12 Module 8 – Device Integration Products

Integration to Third Party Applications

FactorySuite Gateway (FS Gateway) is a universal translator, capable of translating all major
protocols (MX, OPC, DDE, SuiteLink) to any protocol required by a network component.

Note: There is an Online Seminar available for the FactorySuite Gateway. To register, visit
www.wonderware.com/training or call 1-866-WW-TRAIN (1-866-998-7246) or email
Wonderware Training at [email protected].

One of the functions of the FS Gateway is to translate between ArchestrA MX protocol and other
protocols. For instance, a Wonderware Application Server, which uses MX, previously could not
be accessed by third-party clients except through InTouch. Excel, Visual Basic, and other third-
party applications were unable to receive data from Wonderware products without using InTouch
tags. Using FS Gateway as a protocol translator allows direct connection to a Wonderware
Application Server. FS Gateway can replace OPCLink, which translates OPC to DDE or SuiteLink.

FS Gateway is also useful for legacy servers, controllers, and operating systems. Gateway can
translate older DDE to the newer SuiteLink protocol, enabling legacy products to connect to newer
systems.

Wonderware Training
 Section 3 – Device Integration Objects 8-13

Section 3 – Device Integration Objects

Section Objective
z Become more familiar with DI Objects and their use with Wonderware Application
Server.

This section provides familiarization with DI Objects and their use with Wonderware Application
Server.

Introduction
Device Integration (DI) Objects represent the application's network and devices, and mirror the
actual device hierarchy. In Application Server, Device Integration (DI) Objects are a subset of
Automation Objects available in the Template Toolset of the ArchestrA IDE. As a subset of these
Automation Objects, Device Integration Objects consist of two parts:
z DI Network Object, which represents the communications port and are thus associated
with DA Servers.
z DI Device Object, which represents the physical devices that make up a network.
Examples of DI Device Objects are network bridge devices or PLCs. When the objects are
deployed, they represent the network hierarchy. Each level of this hierarchy can be
monitored for its individual status.
Device Integration objects are used to represent communications channels and field controllers.
As such, they are most often arranged in a hierarchy that models the physical hierarchy of the
network and devices on that network.
Device Integration objects are designed to make it very easy to integrate DAServers into the
ArchestrA environment.
Therefore, deploying a DI Network actually deploys the DAServer and its associated components
within the ArchestrA IDE/Galaxy. This facilitates the DAServer installation process for end-users.
Several DI Objects are delivered and installed by default with your Application Server software.
There are also several DI objects available that are for specific DA Servers. These are available
on the Wonderware Device Integration DVD.

DI Object Advantages
Device Integration Objects (DI Objects) represent communication with external devices. DI
Objects may be DINetwork Objects (for example, the Redundant DI Object) or DI Device Objects.
DI Objects (and their associated AppEngine) can reside on any I/O, DA, or Automation Object
Server node in the Galaxy. DI Objects allow connectivity to data sources such as DDE servers,
SuiteLink servers, OPC servers, and existing InTouch applications.
The advantages of using DI Objects are as follows:
z DI objects allow you to configure, deploy, and monitor DAServers from one centralized
location.
z DI Objects can be used to represent all devices and PLCs in a network, enabling
representation of an entire plant, including a hierarchical view of network connectivity.
z DI objects are so closely tied to the DAServer that when an object is deployed across the
network, it remotely installs the DAServer (This means that you can install the DAServer
without going to the actual machine, and that the DAServer connects immediately.).

System Platform - Part 1

8-14 Module 8 – Device Integration Products

z DI objects are very closely tied to the DAServer they are assigned to, so that when an
object is deployed, it brings with it all code, including registry, scripting, attributes, and
parent.
Note that in a large project, this process may take some time. However, tremendous savings are
achieved when comparing centralized deployment with individual tasks should the Servers be
separately installed and configured on each node.

DI Objects in the ArchestrA IDE

DI objects are located in the Template Toolbox and can also be imported into the Galaxy in the
same way as Application Objects. They are imported directly into the Device Integration area of
the Template Toolbox:

Scan On Demand
Advanced Communication Management minimizes network traffic and CPU usage of a DIObject
or DAServer. While the client application is running, scanning for an attribute value is suspended
when the owning object no longer appears in the running application. For example, Advanced
Communication Management suspends scanning for an object's attribute value when the operator
minimizes the application window containing the object. When the operator shows the window
containing the object again, Advanced Communication Management resumes scanning and the
object's attribute value is updated in the application.
Scanning can be configured using the following options:
Active
z Items are deleted and added to the scan group as requested (referenced) by the clients.
z Items that exist when a scan mode change occurs are not deleted unless the previous
mode was ActiveAll and the items are no longer referenced.
z The Active scan mode polls all points that are referenced, whether active or inactive.
z In Active scan mode an attribute is always in the active state. When the last reference to
the attribute is unregistered/unadvised, the attribute is deleted.
ActiveAll
z Scanning is continuous and dynamic attributes are never removed when unsubscribed.
z Items are activated by client requests, but continue to exist even after the client are not
interested in them anymore.
z Items are not removed when the scan mode changes.
z The scan group polls the field device for all points irrespective of whether they are
currently active, inactive, or even subscribed to by items.
ActiveOnDemand
z When the scan mode is configured as ActiveOnDemand, attributes that are not actively
being referenced by any client or object are made Inactive and are not scanned.
z New Items are deleted and added to the scan group as requested (referenced) by clients.

Wonderware Training
 Section 3 – Device Integration Objects 8-15

z Items that exist when a scan mode change occurs are not deleted unless the previous
mode was ActiveAll and the items are no longer referenced.
z ActiveOnDemand scan mode polls the field device for currently active items only. Inactive
items are not scanned.

System Platform - Part 1

8-16 Module 8 – Device Integration Products

– Intentionally left blank –

Wonderware Training
 Module 9

Multi-Node Applications
Section 1 – Application Redundancy 9-3
Lab 18 – Configuring Application Redundancy 9-17
Section 2 – DI Redundancy 9-31
Lab 19 – Configuring the Redundant DI Object 9-35
Section 3 – Multi Node Application 9-47
Lab 20 – Convert to Network Environment 9-51
9-2 Module 9 – Multi-Node Applications

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

Wonderware Training
 Section 1 – Application Redundancy 9-3

Section 1 – Application Redundancy

Section Objective
z This section covers the concept of redundancy, how it can be configured and key points
to more effectively implement this feature.
z Understand the concept and functionality of Redundant DI Objects

This section provides an understanding of the concept of redundancy, how it can be configured
and key points to more effectively implement this feature. It also provides an understanding of the
concept and functionality of Redundant DI Objects

Redundant Configuration
Redundancy is important in processes that rely on continuous availability of information. There are
two basic types or topologies of redundant configuration:
z Redundant Application Engines
z Redundant DI Objects

System Platform - Part 1

9-4 Module 9 – Multi-Node Applications

Redundant Application Engines

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

Wonderware Training
 Section 1 – Application Redundancy 9-5

The Application Engine that is enabled is considered the Primary engine of the redundant pair;
when you enable this engine, an additional (Backup) engine is automatically created.
Since an engine is required to run under a platform, the platform objects that sponsor the Primary
and Backup application engines need to be configured to use the dedicated NIC. This NIC
provides a high speed inter-connection link or Redundant Message Channel between the
platforms. The Message Channel is vital to keep both engines synchronized with alarms, history,
and checkpoint items from the engine that is in the Active Role. Each engine also uses this
Message Channel to provide its health, along with status information, to the other.
The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of
Application engines determines which of these in the pair will take the Active Role. The first engine
deployed takes the Active role while the other one takes the Standby role. The engines maintain
their current roles until a failure occurs. (A failure might consist of computer hardware lost or failed,
or a network card failure.) If a failure occurs, the engine with the Standby role assumes the Active
role and the engine that was in the Active role is given the role of Standby - Not Ready. When the
cause of the failure has been remedied, this engine assumes the Standby - Ready role.

System Platform - Part 1

9-6 Module 9 – Multi-Node Applications

Terminology
Two sets of terms are critical to understanding the functions of redundant objects. These are
described below.

During Configuration
Primary object: The object intended as the main or central provider of the functionality in the
run-time. For AppEngines, it is the object you enable for redundancy. For data acquisition, it is
the DIObject you intend to use first as your data source in the run-time.
Backup object: The object that provides the functionality of the Primary object when it fails.
For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary
object has been enabled for redundancy. For data acquisition, it is the DIObject you do not
intend to use first as your data source in the run-time.

During Run-Time
Active object: The object that is currently executing desired functions. For AppEngines, it is
the object that is hosting and executing ApplicationObjects. For data acquisition, it is the object
that is providing field device data through the RedundantDIObject.
Standby object: The passive object; that is, it is waiting for a failure in the Active object's
condition or for a force-failover. For AppEngines, it is the object that monitors the status of the
Active AppEngine. For data acquisition, it is the object that is not providing field device data
through the RedundantDIObject.
The Primary/Backup and Active/Standby objects form a redundancy pair. For AppEngine pairs,
only the Primary and its hierarchy of assigned ApplicationObjects must be created, configured and
deployed. The Backup is handled completely by the ArchestrA infrastructure (for instance, it is
deployed separately from the Primary). For data acquisition, the Primary/Backup DIObjects (the
data sources) must be separately created, configured and deployed. Also, you must create,
configure and deploy a RedundantDIObject to control failovers between the two data source
objects.
In the AppEngine redundancy environment, the Active and Standby objects monitor each other's
status and switch when failure conditions occur. In the data acquisition environment, the
RedundantDIObject monitors the status of the two DIObject data sources, and handles the
switching from Active to Standby objects.
The relationship between the configuration time (Primary/Backup) and run-time (Active/Standby)
object pairs is not static. In the run-time, either the Primary or Backup object can be the Active
object at any particular time. Whenever one becomes the Active object, the other automatically
becomes the Standby.
Configuration values for Primary and Backup also can be changed after deployment of the objects.

Note: In the case of AppEngine redundancy, ArchestrA supports a one-to-one topology in which
the computers hosting the Primary and Backup object sets must be connected by crossover cable
and have fixed IP addresses.

Key Points

a. Before placing an engine with redundancy enabled under a platform in the Deployment view,
configure the platform Redundant Message Channel; otherwise the engine will show an error.

Wonderware Training
 Section 1 – Application Redundancy 9-7

b. In the Application Views panes of the ArchestrA IDE, only in the Deployment view will the
Backup engine be visible.
c. The Backup Engine cannot be edited.
d. After editing an engine with redundancy enabled while it is deployed, when it is redeployed the
engine which has the Active role will perform this function. It will then update the engine that is
in the Standby role.
e. A Backup engine's deployment status can be different from that of the Primary Engine, but
operations such as renaming, importing and exporting, GRdump and GR load that are
performed on the Primary Engine are automatically performed on the Backup. These
operations cannot be performed on the Backup Engine alone.
f. Platforms hosting primary and backup AppEngines should have identical configuration. For
instance, it is possible to configure the platform with the Primary to be the InTouch Alarm
provider and filter the areas you want to query in the Platform editor. For the Alarm
Management system to behave correctly, this same configuration should be implemented in
the platform with the Backup. It is recommended that you make the following parameters
common to both platforms:
z IT Alarm provider-Areas
z Store Forward directories
z Common user-defined attributes (UDAs)
z Common scripting

System Platform - Part 1

9-8 Module 9 – Multi-Node Applications

Dedicated and Shared Loads

There are two types of redundant engine configuration: Dedicated and Shared load.

Note: Depending on the order of deployment, the Primary or Backup engine may take the role of
Active Engine. If either engine is deployed by itself, it assumes the Active Engine role.

In a Dedicated redundant configuration, if the Active Engine fails or is shut down, or if a

communication failure occurs, the engine in the Standby Ready role assumes the Active role. In
this scenario, the platform with the engine in the Standby Ready role is essentially idling. See the
following illustration.

Visualization Nodes

Supervisory Network
AutomationObject Server AutomationObject Server

Redundancy Message Channel

AE_1 AE_1
(Active) Primary Backup (Standby)
Platform 1 Platform 2

Control Network

In a Shared redundant configuration, two or more Redundant Engines reside on each of two
platforms. Each platform hosts a Primary and a Backup engine. See the illustration below. This
scenario operates similarly to the Dedicated configuration, but allows the application load to be
shared on two computers until a failure occurs. When a failure occurs, one platform hosts the load
of both application engines. The benefits of using this approach is that the time of failover is
shortened and that only part of an application process is affected during a failure.

Note: It is important to understand both the CPU and memory load requirements of each engine.
Each computer must be capable of supporting these needs when a failure occurs; otherwise,
throughput for the application can be compromised

Wonderware Training
 Section 1 – Application Redundancy 9-9

Visualization Nodes

Supervisory Network
AutomationObject Server AutomationObject Server

Redundancy Message Channel

AE2 AE1
Primary AE1 Bck Backup Backup Bck AE2 Primary
Platform 1 Platform 2

Control Network

System Platform - Part 1

9-10 Module 9 – Multi-Node Applications

What Happens in Run-time

During initial deployment to its assigned WinPlatform, first code modules and other files for the
Primary AppEngine are deployed, followed by those files for its assigned ApplicationObjects. All of
these files are then deployed to the Standby AppEngine by the Active engine’s WinPlatform using
the redundancy message channel (RMC).

Note: If some or all of these files already exist on the Standby AppEngine’s WinPlatform (perhaps,
assigned to another AppEngine on that platform), only the delta files are deployed to the Standby
AppEngine.

AutomationObjects are always assigned to the Primary AppEngine in the configuration

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

AppEngine Redundancy States

Redundant pairs of AppEngines can have one of the following states at a time:
z Active: The state of an AppEngine when it has communication with its partner object, its
partner is in Standby-Not Ready, Standby-Sync’ing with Active, or Standby-Ready state. A
Standby AppEngine transitions into this state when a failover condition has been detected.
In this state, an AppEngine schedules and executes deployed objects, sends checkpoint
data and sends subscriber list updates to the Standby AppEngine.
z Active - Standby not Available: The state of an Active AppEngine when it determines it
cannot achieve communications with its partner object. This could mean that checkpoint,
subscription and alarm state changes have not been successfully transmitted to the
Standby object, a heartbeat ping has not been received from the Standby object, or
notification is received that the Standby AppEngine has shutdown or is not running. If an
AppEngine is in this state, it 1) continues normal execution of hosted objects, 2) cannot be
manually switched to Standby state, and 3) while continuing to attempt communicate with
the Standby, does not attempt to send data to the Standby object.
z Determining Failover Status: The initial state of a redundancy-enabled AppEngine when
it is first started. It has not determined yet whether it is the Active or Standby AppEngine.
Communication between the two AppEngines is attempted first over the RMC and then
over the primary network to make this determination. If communication cannot be made
after a certain timeout period, an AppEngine assumes the Active role if it has all of the
code modules and checkpoint file data to do so. Continued attempts are made at
communicating with its partner.

Wonderware Training
 Section 1 – Application Redundancy 9-11

z Standby - Missed Heartbeats: The state of an AppEngine when 1) a heartbeat ping has
not been received from its Active partner within a configured timeout period, 2) the Active
AppEngine fails or hangs up, or 3) the Active AppEngine is shutdown on purpose. When in
this state, the Standby object attempts to determine whether or not the Active object has
failed. If a manual failover is initiated (by using the ForceFailoverCmd attribute), it will be
processed only if the heartbeats were missed over the primary network and not missed
over the RMC.
z Standby - Not Ready: The state of an AppEngine when one of several conditions occurs:
1) its has lost communications with its partner object or it maintains communications with
its partner but has missed checkpoint updates or alarm state changes from the Active
AppEngine, 2) new objects are deployed to the Active AppEngine and necessary files
have not been installed on the Standby AppEngine yet, or 3) the Standby AppEngine has
lost communications over the RMC before it could complete synchronizing data. Typically,
the AppEngine’s partner is in one of the following states: Active-Standby not Available,
Active, or Standby- Missed Heartbeats.
z Standby - Ready: The state of an AppEngine when is has completed synchronizing code
modules and checkpoint data with the Active AppEngine. In this state, the AppEngine
monitors for Active AppEngine failure by verifying heartbeat pings received from the
Active engine, checks that all files required for execution are in sync with the Active
engine, and receives the following from the Active AppEngine: checkpoint change data,
subscription-related notifications, alarm state changes, and history blocks.
z Standby - Sync'ng with Active: The state of an AppEngine when it is synchronizing code
modules with the Active object. If code modules exist on the Standby computer that do not
exist on the Active node, they are uninstalled, and likewise, any code modules that exist
on the Active node but not on the Standby node are installed. Once all code modules are
synchronized, the AppEngine transitions to Standby-Sync’d Code state.
z Standby - Sync'd Code: The state of a Standby AppEngine that has successfully
synchronized all code modules with the Active object.
z Standby - Sync'd Data: The state of a Standby AppEngine when all object-related data,
including checkpoint and subscriber information, are synchronized with the Active object.
An object in this state typically transitions to Standby-Ready state.
z Switching to Active: A temporary, transitional state when a Standby AppEngine is
commanded to become Active.
z Switching to Standby: A temporary, transitional state when an Active AppEngine is
commanded to become Standby.
z Unknown: The state of a redundant partner when a communication loss occurs between
AppEngines or when the partner AppEngine is not running.

System Platform - Part 1

9-12 Module 9 – Multi-Node Applications

Alarm Generation
When failover conditions occur, the ArchestrA system reports alarms to the Logger. These alarms
contain the following information:
z The name of the AppEngine reporting the alarm.
z The node name of the AppEngine reporting the alarm.
z The state of the AppEngine.
z The node name of the AppEngine’s partner object.

Note: Depending on the scenario that causes a failover, the Standby AppEngine may become the
Active in an offscan state and alarms may not be generated. If the Active AppEngine is shutdown
offscan, the checkpointer may transfer that state to the Standby, and when the latter becomes the
Active, it will startup offscan. When the AppEngine is put onscan, alarms then are generated.

Alarms reported are the following:

Alarm
Previous Current Alarm Raised
Alarm Alarm Cleared When Reported
State State When
By
Standby - Not Active Standby - Not Standby - Not Entering Standby - ACtive
Ready 1 Ready Ready Ready Engine
Standby - Not Active Active - Active - Standby Not Entering Active Active
Available Standby Not Available Engine
Available
Failover Standby Becomes During the next scan Active
Occurred Active of the Active Engine Engine

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

Finally, the following information is preserved for alarms:

z An alarm was acknowledged
z The message input by the operator when the alarm was acknowledged

Wonderware Training
 Section 1 – Application Redundancy 9-13

Note: All alarm state information is collected and sent to the Standby AppEngine at the end of a
scan cycle and before being sent to alarm clients. Any alarms that occur between scan cycles,
therefore, may not be reported to the Standby object if the Active object fails. The sequence of
reporting alarms ensures that alarm clients do not report alarms in states that are different from
those reported by the Standby AppEngine if the Active one fails.

History Generation
All active objects (AppEngine and hosted objects) report history data as they normally do in the
run-time environment.
Historical data is reported to the historian only from the Active AppEngine.
Loss of connectivity with the historian does not cause a failover. The Active AppEngine then goes
into store-forward mode and caches data every 30 seconds. Store-forward data (when the
historian is unavailable) is synchronized with the Standby AppEngine.
When failover conditions occur, no more than 30 seconds of history data should be lost in the
transition from Standby to Active status. This is done through a combination of store-forward
operations when the historian is unavailable and normal reporting operations when it is available.

Forced Failover
Failover can be forced to occur. Do this through the ForceFailoverCmd attribute of the AppEngine.
For instance, you can link multiple conditions in a script or use the Object Viewer utility to trigger a
forced failover.

Deployment
Primary and Backup AppEngines can be deployed together or individually. When they are
deployed together (no matter which object is actually selected for deployment), the Primary always
becomes the Active and the Backup becomes the Standby. When they are deployed individually,
the first one deployed becomes the Active.
Hosted ApplicationObjects are always deployed to the Active AppEngine. When deploying the first
of a redundant pair of AppEngines, you can cascade deploy all objects it hosts. This operation can
be paired with deploying both the Primary and Backup AppEngines at the same time.

Note: If you deploy the Backup AppEngine first and then deploy hosted objects to that
AppEngine, ensure that network communications to both target computers is good before
deploying the Primary AppEngine. Otherwise, errors may occur.

In the run-time environment, either the Primary or Backup AppEngine can become the Active or
Standby depending upon failure conditions on either computer.

System Platform - Part 1

9-14 Module 9 – Multi-Node Applications

Before deploying the Primary and Backup AppEngines, all configuration requirements must be
met. Each AppEngine must be assigned to a separate WinPlatform. A valid redundancy message
channel (RMC) must be configured for each WinPlatform. To deploy the Primary and Backup
together, select Include Redundant Partner in the Deploy dialog box. This option is not available
when doing the following operations:
z Cascade deploy from the Galaxy
z Multiple object selection deploy
z Deployment of the WinPlatform that hosts the Primary or Backup AppEngine
See the following table for a matrix of allowed operations based on specific conditions.

Deploy Both Primary Cascade Deploy

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

Undeploying redundancy pairs of AppEngines is similar to any regular object undeployment. The
Active and Backup AppEngines can be undeployed separately. Also, they can be undeployed as a
pair by selecting one of the objects in an Application View, selecting the Undeploy command, and
selecting Include Redundant Partner in the Undeploy dialog box.

Note: Undeployment of any AutomationObjects, including redundant AppEngine pairs, does not
uninstall code modules for that object from the hosting computer. Code modules are uninstalled
only when the WinPlatform is undeployed.

Wonderware Training
 Section 1 – Application Redundancy 9-15

Errors and Warnings

Certain requirements (for instance, the order you configure an object pair for redundancy) are
validated by the system infrastructure. If a requirement is not met, you may see error messages
that describe the following:
z You can configure an AppEngine for redundancy before its associated WinPlatform, but if
you do, you will get an error message that the Platform (specifically, the RMC) is not
configured yet.
z If the RMC IP Address parameter is not configured in both hosting WinPlatforms, then the
configuration state of both Primary and Backup AppEngines changes to Error, with a
message indicating that the host WinPlatform is not configured with the network adapter
required for redundant communications. When the RMC IP Address is configured and the
WinPlatforms are checked in, the hosted AppEngines are automatically revalidated and
the Error state is resolved. If hosted AppEngines are checked out, they are not
revalidated.
z If both Primary and Backup AppEngines are assigned to the same WinPlatform and an
attempt is made to deploy both engines, both the Primary and Backup will fail to deploy
with a message noting that the Primary and Backup objects must be hosted by different
WinPlatforms. Reassign the Backup object to another WinPlatform and deploy it
separately.
z If both the Network Address and RMC IP Address parameters in the WinPlatform's
editor address the same network card, you will get a warning message when you save the
configuration. These two parameters must address different network cards.

System Platform - Part 1

9-16 Module 9 – Multi-Node Applications

– Intentionally left blank –

Wonderware Training
 Lab 18 – Configuring Application Redundancy 9-17

Lab 18 – Configuring Application

Redundancy
Introduction
This lab describes how to configure your galaxy for redundancy starting with the necessary
network configuration in Windows to properly handle a second network connection as the galaxy’s
redundant message channel.
Using the ArchestrA IDE, the galaxy is configured to become a two-node redundant system that
will failover between the two nodes when a failure occurs in the system.

Note: It is assumed that the required second network card is installed in both computers and the
crossover cable for the RMC is connected

Note: Because of the additional hardware and network requirements necessary, this lab is usually
executed as an Instructor demonstration only.

Objectives
Upon completion of this lab you will be able to:
z Configure a second network connection in Windows as the redundant message channel
z Configure the $WinPlatform and $AppEngine object for redundancy
z Create a deployment model for redundant engines
z Force a failover on a redundant system

System Platform - Part 1

9-18 Module 9 – Multi-Node Applications

Summary Lab Instructions

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

Configure Windows network connections (page 9-20)

Note: The following configuration needs to be done on BOTH computers.

a. Rename the network connections as follows:

Local Area Connection to ArchestrA
Local Area Connection 2 to RMC
b. Use the network connections Advanced Settings to make sure that the ArchestrA
connection is access before the RMC connection.
c. Assign an IP address to the RMC in a different subnet than the ArchestrA connection.

Important! The IP address for the RMC connection must be different on each computer but in
the same subnet, and on a different subnet than the ArchestrA node.

Important!

d. On the Advanced setting for TCP/IP, configure the RMC connection to not Register this
connection’s addresses in DNS.

Configure the Galaxy for Redundancy (page 9-25)

e. Undeploy the galaxy.
f. Configure the GRPlatform object’s Redundancy message channel IP address with its own
RMC IP address.
g. Create a new instance of the $tWinPlatform template named Platform_001 and assign it to
the ControlSystem area.
h. Configure the Platform_001 object with the name of the second computer and its own RMC IP
address for the Redundancy message channel IP address.
i. Configure the AppEngine object for Redundancy and assign its backup to the Platform_001
object.

Wonderware Training
 Lab 18 – Configuring Application Redundancy 9-19

Test Redundancy (page 9-28)

j. Deploy the galaxy.
k. Using the watch list created in Lab 5, add a new watch window called Redundancy and add
the following attribute references for the AppEngine:
z Host
z Redundancy.Identity
z Redundancy.Status
z Redundancy.PartnerPlatform
z Redundancy.PartnerStatus
z Redundancy.FailoverOcurred
z Redundancy.ForceFailoverCmd
l. Save the watch list.
m. Force a failover in the system and monitor the data using Object Viewer and the different
watch windows created during the class.

See the next page for Detailed Lab Instructions

System Platform - Part 1

9-20 Module 9 – Multi-Node Applications

Detailed Lab Instructions

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

Configure Windows network connections

Note: The following configuration (steps 1-14) needs to be done on BOTH computers.

1. Open Windows Network Connections by double-clicking on Start / Control Panel / Network

Connections.
The Network Connections window appears.
2. Rename network connections as follows:

Local Area Connection to ArchestrA

Local Area Connection 2 to RMC

This is an optional step that enables you to easily identify each connection in this class
environment.

Wonderware Training
 Lab 18 – Configuring Application Redundancy 9-21

3. From the Advanced menu, select Advanced Settings.

4. In the Advanced Settings dialog box, Adapters and Bindings tab, make sure that the
ArchestrA connection is listed before the RMC connection and then click the OK button to
close the dialog box.

Note: You can use the and buttons to arrange the access order.

System Platform - Part 1

9-22 Module 9 – Multi-Node Applications

5. Right-click on the RMC connection and select Properties.

6. In the RMC Properties dialog box, General tab, select the Internet Protocol (TCP/IP) item.
7. Click the Properties button.

Wonderware Training
 Lab 18 – Configuring Application Redundancy 9-23

8. At the Internet Protocol (TCP/IP) Properties dialog box select the Use the following IP
address option and assign an IP address in a different subnet than the ArchestrA connection.

Important! The IP address for the RMC connection must be different on each computer but in
the same subnet, and on a different subnet than the ArchestrA node.

Note: In this example the first computer will have an IP address of 192.168.1.1 and the
second computer will have an IP address of 192.168.1.2. Both will be have a subnet mask of
255.255.255.0.

9. Click the Advanced button to continue.

System Platform - Part 1

9-24 Module 9 – Multi-Node Applications

10. In the Advanced TCP/IP Settings dialog box, select the DNS tab.

11. Uncheck the Register this connection’s address in DNS box.

12. Click the OK button to close the Advanced TCP/IP Settings dialog box.
13. Click the OK button to close the Internet Protocol (TCP/IP) Properties dialog box.
14. Click the Close button to close the RMC Properties dialog box.

Wonderware Training
 Lab 18 – Configuring Application Redundancy 9-25

Configure the Galaxy for Redundancy

15. Undeploy the GRPlatform object.
16. Double-click the GRPlatform instance to open its configuration editor.
17. In the Redundancy panel, Redundancy message channel IP address field, enter the IP
address assigned to the RMC connection you used for the first computer in step 8.
In this example the first computer has an IP address of 192.168.1.1

18. Click the Save and Close button and check in the object.
19. Create a new instance of the $tWinPlatform template named Platform_001.

System Platform - Part 1

9-26 Module 9 – Multi-Node Applications

20. Assign the new Platform_001 instance to the ControlSystem area.

21. Double-click the Platform_001 instance to open its configuration editor.

22. In the Network address field, enter the name of second computer.
23. In the Redundancy panel, Redundancy message channel IP address field, enter the IP
address assigned to the RMC connection you used for the second computer in step 8.
In this example the second computer has an IP address of 192.168.1.2

Wonderware Training
 Lab 18 – Configuring Application Redundancy 9-27

24. Click the Save and Close button and check in the object.
25. Double-click the AppEngine instance to open its configuration editor.
26. Select the Redundancy tab and configure the object as follows:
Enable redundancy: checked

27. Click the Save and Close button and check in the object.
28. In Deployment view, assign the automatically created AppEngine (Backup) object to the
Platform_001 instance.

System Platform - Part 1

9-28 Module 9 – Multi-Node Applications

Test Redundancy
29. Deploy the galaxy by right-clicking the name of the galaxy and selecting Deploy.
30. Open Object Viewer by right-clicking the AppEngine instance and selecting View in Object
Viewer.
31. Load your saved Watch List.
32. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
Window to add a new tab to the watch list.
33. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the watch list to Redundancy.
34. Using the watch list created in Lab 5, add a new watch window named Redundancy with the
following attributes from the AppEngine instance:
z Host
z Redundancy.Identity
z Redundancy.Status
z Redundancy.PartnerPlatform
z Redundancy.PartnerStatus
z Redundancy.FailoverOccurred
z Redundancy.ForceFailoverCmd
Your data should look similar to the following:

35. Save the watch list.

Wonderware Training
 Lab 18 – Configuring Application Redundancy 9-29

36. Force a failover to the second computer by writing true to the ForceFailoverCmd attribute of
the AppEngine.

You can use the Mixer1 watch window to verify that the objects are running properly.

37. Failover the system doing any of the following on the second computer:
z Unplug the power cable
z Shut down Windows
z Disconnect both network cables at the same time.

You can use the Mixer1 watch window to verify that the objects are running properly.

System Platform - Part 1

9-30 Module 9 – Multi-Node Applications

– Intentionally left blank –

Wonderware Training
 Section 2 – DI Redundancy 9-31

Section 2 – DI Redundancy

Section Objective
z This section covers the concept of redundancy, how it can be configured and key points
to more effectively implement this feature.
z Understand the concept and functionality of Redundant DI Objects

This section provides an understanding of the concept of redundancy, how it can be configured
and key points to more effectively implement this feature. It also provides an understanding of the
concept and functionality of Redundant DI Objects

Redundant DI Objects
Application Engines can host Redundant Device Integration Objects (DI Objects). The
RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike redundant
AppEngines, individual DIObject data sources do not have redundancy-related states. For all
intents and purposes, they function as standalone objects.
Only one DIObject data source provides field device data through the RedundantDIObject at a
time. Both data sources must have commonly configured DAGroups which are reflected in and
channeled through the RedundantDIObject, which monitors the two DIObject data sources and
determines which one is Active at any given time. Both data sources must also have the same
item address space.
The Redundant DI Object is a DINetwork Object used to enable continuity of I/O information from
field devices. The Redundant DI Object provides the ability to configure a single object with
connections to two different data sources. If the primary data source fails, the Redundant DI
Object automatically switches to the backup data source for its information. There is a one-to-two
relationship between an instance of the Redundant DI Object and the running instances of the
source DI objects; that is, for each Redundant DI Object, a pair of source DI Objects is deployed.

System Platform - Part 1

9-32 Module 9 – Multi-Node Applications

:RUNVWDWLRQV

5HGXQGDQW
',2EMHFW

6XSHUYLVRU\1HWZRUN

',B ',B

'$6HUYHUB '$6HUYHUB
$(
3ODWIRUP $%7&3 '+

$SSOLFDWLRQ6HUYHU
&RQWURO1HWZRUN

3/&

Configuration RedundantDIObjects
Configure redundancy in data acquisition objects in the ArchestrA IDE through their editors. Data
acquisition redundancy objects (two DIObjects and the RedundantDIObject) do not have
redundancy-related deployment statuses.
In data acquisition redundancy, you must configure all three components: a Primary DIObject data
source, a Backup one, and a Redundant DIObject.
Because data acquisition redundant components are essentially standalone objects, all valid
operations that apply to any other ApplicationObjects apply to the three objects. All ArchestrA IDE
commands, Galaxy Dump and Load functions, and import and export operations are valid on the
two DIObject data sources and the RedundantDIObject.
The main focus of RedundantDIObject configuration is:
z Setting the Primary DI Source and Backup DI Source on the General tab of the object’s
editor.
z Setting up the common scan groups, and block read and block write groups on the
respective tabs of the object’s editor.

Note: You must configure at least one scan group before you can deploy the RedundantDIObject.
Also, only scan, block read, and block write groups shared by the Primary and Backup DIObjects
should be configured in the RedundantDIObject.

Wonderware Training
 Section 2 – DI Redundancy 9-33

Deployment
Deployment for data acquisition redundancy is the same as individually deploying unrelated
objects. No special conditions apply to each DIObject data source and the RedundantDIObject.

What Happens in Run-time

The three objects in the data acquisition redundancy scheme (RedundantDIObject and its two
DIObject data sources) function like any other ArchestrA object with respect to deployment,
alarming and historization. They have no special redundancy-related states or restrictions with
respect to deployment, undeployment and redeployment.
During run-time, the RedundantDIObject monitors the status of the DIObject data sources, and
handles the switching from Active to Standby object when failure conditions arise.

System Platform - Part 1

9-34 Module 9 – Multi-Node Applications

– Intentionally left blank –

Wonderware Training
 Lab 19 – Configuring the Redundant DI Object 9-35

Lab 19 – Configuring the Redundant DI

Object
Introduction
This lab describes the steps necessary to configure your galaxy for redundancy at the
communication level with the field by using two similar device integration objects connected to the
same field device, such as a PLC.

Note: Because of the additional hardware and network requirements necessary, this lab is usually
executed as an Instructor demonstration only.

Objectives
Upon completion of this lab you will be able to:
z Create a deployment model for redundant DI object
z Configure and use the $RedundantDIOObject
z Force a failover on a redundant DI system

System Platform - Part 1

9-36 Module 9 – Multi-Node Applications

Summary Lab Instructions

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

Configure DI Redundancy
a. Create two new instances of the $tAppEngine template, name them AppEngineDI1 and
AppEngineDI2 and assign them to the ControlSystem area.
b. Host AppEngineDI1 on GRPlatform platform and AppEngineDI2 on Platform_001 platform.
c. Rename the InControl instance as DIO1 and host it on the AppEngineDI1 engine.
d. Create a copy of the DIO1 object by repeating Lab 6 but naming the object DIO2. Assign the
new object to the ControlSystem area and host it on the AppEngineDI2 engine.
e. Derived a new template from the $RedundantDIObject object, name it $tRedundantDIObject,
and assign it to the Training template toolset.
f. Create an instance of the $tRedundantDIObject template and name it InControl.
g. In the General tab, configure the object as follows:

Primary DI source: DIO1

Backup DI source: DIO2

h. In the Scan Group tab, copy the common scan groups and attributes from the primary or
backup DI sources.
i. Host the InControl instance on the AppEngine object.

Test the Redundant DI Object

j. Deploy the AppEngineDI1, AppEngineDI2, DIO1, DIO2 and InControl objects.
k. Using the watch list created in Lab 5, add a new watch window called RDIO, add the following
attribute references for the InControl Instance, and Save the watch list:
z DISourcePrimary
z DISourceBackup
z DISourceActive
z DISourceStandby
z StatusPrimaryDISource
z StatusBackupDISource
z ConnectionStatus
z SwitchReason
z ForceFailoverCmd
l. Force a failover in the system and monitor the objects using Object Viewer and the different
watch windows created during the class.

See the next page for Detailed Lab Instructions

Wonderware Training
 Lab 19 – Configuring the Redundant DI Object 9-37

Detailed Lab Instructions

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

Configure DI Redundancy
1. Create two new instances of the $tAppEngine template.
2. Name the new instances AppEngineDI1 and AppEngineDI2 and assign them to the
ControlSystem area.

3. In the Deployment view, host AppEngineDI1 on the GRPlatform platform and

AppEngineDI2 on Platform_001 platform.

4. Undeploy the InControl instance.

5. Rename the InControl instance DIO1.

System Platform - Part 1

9-38 Module 9 – Multi-Node Applications

6. Host the DIO1 object on the AppEngineDI1 engine.

7. Use Lab 6, “Connecting to the Field” to create another device integration object, but name it
DIO2 instead of InControl. Assign it to the ControlSystem area.

Note: You can export your object, rename the original, and then import the object to create a
copy of the object with all of the original object’s configuration attributes.

Wonderware Training
 Lab 19 – Configuring the Redundant DI Object 9-39

8. In the Deployment view, host the DIO2 object on the AppEngineDI2 engine.

9. Create a derived template from the $RedundantDIObject template named

$tRedundantDIObject and assign it to the Training template toolset.

10. Create an instance of the $tRedundantDIObject template named InControl and assign it to
the ControlSystem area.

System Platform - Part 1

9-40 Module 9 – Multi-Node Applications

Note: The template name InControl is used here to match the existing attribute references that
were configured in the objects and scripts in previous labs.

11. Double-click the InControl instance to open its configuration editor.

12. In the General tab, configure the object as follows:

Primary DI source: DIO1

Backup DI source: DIO2

Wonderware Training
 Lab 19 – Configuring the Redundant DI Object 9-41

13. Select the Scan Group tab and click on the Copy Common Scan Groups button.

14. In the Copy Common Scan Groups dialog box, click the OK button to accept tagname as
the scan group for the new InControl object.

System Platform - Part 1

9-42 Module 9 – Multi-Node Applications

15. Click on the Copy Attributes From Primary button.

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

Wonderware Training
 Lab 19 – Configuring the Redundant DI Object 9-43

17. In the Deployment view, host the new InControl object on the AppEngine engine.

Test the Redundant DI Object

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

System Platform - Part 1

9-44 Module 9 – Multi-Node Applications

24. Add the following attributes from the InControl instance to the watch list:
z DISourcePrimary
z DISourceBackup
z DISourceActive
z DISourceStandby
z StatusPrimaryDISource
z StatusBackupDISource
z ConnectionStatus
z SwitchReason
z ForceFailoverCmd
z SwitchCnt
Your data should look similar to the following:

25. Save the watch list.

26. Force a failover to the second device integration object by writing true to the
ForceFailoverCmd attribute of the Redundant DI Object. You can use the Mixer 1 watch
window to verify that the objects are running properly.

27. Failover the system doing any of the following on the second computer:
z Unplug the power cable
z Shut down Windows
z Put the DIO2 object off scan

Wonderware Training
 Lab 19 – Configuring the Redundant DI Object 9-45

You can use the Mixer 1 watch window to verify that the objects are running properly.

System Platform - Part 1

9-46 Module 9 – Multi-Node Applications

Wonderware Training
 Section 3 – Multi Node Application 9-47

Section 3 – Multi Node Application

Section Objective
This section deals with migrating from a standalone configuration to a network configuration. At
the conclusion of this section you will have an understanding of the steps necessary to migrate to
a network environment.

This section provides an understanding of how to migrate from a standalone configuration to a

network configuration. At the conclusion of this section you will have an understanding of the steps
necessary to migrate to a network environment.

Standalone to Network Configuration

Earlier we discussed the standalone configuration you have been using up to this point. At this
time you want to migrate over to a network configuration that will reflect four nodes accessing one
Galaxy Repository. This will allow us to utilize a networked configuration to convey more complex
concepts relating to connectivity, exporting objects and templates and other multi-node
environmental considerations.
Each of the nodes contains the Bootstrap, the ArchestrA IDE, and a Galaxy Repository. Once you
have reconfigured the environment there will be one machine (Node1) that will contain the
Bootstrap, the ArchestrA IDE, and a Galaxy Repository. Three other nodes will be connected to
the Galaxy on Node1. Those other three nodes will contain only the Bootstrap and the ArchestrA
IDE.
In the networked architecture a common Galaxy Repository will be shared between a set of PCs
allowing multiple users to simultaneously work on the same application.
The existing standalone environment is illustrated as follows:

System Platform - Part 1

9-48 Module 9 – Multi-Node Applications

The networked environment that you are migrating to is illustrated as follows:

Wonderware Training
 Section 3 – Multi Node Application 9-49

Multi User Conversion Considerations

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

System Platform - Part 1

9-50 Module 9 – Multi-Node Applications

– Intentionally left blank –

Wonderware Training
 Lab 20 – Convert to Network Environment 9-51

Lab 20 – Convert to Network Environment

Introduction
This lab describes the steps necessary to convert to a Networked Configuration. In this lab you
team up with your classmates to create a galaxy that spans across multiple nodes. In the
networked environment a common Galaxy Repository is shared between a set of PCs allowing
multiple users to simultaneously work on the same application.
To speed up the process, templates you created in the class are re-used.
Since there can only be one Galaxy Repository per galaxy, your team needs to designate one of
the team members’ computer to become the sole Galaxy Repository for the galaxy. This person/
computer is designated as the Galaxy Master. The Galaxy Master has specific extra steps to
perform.

Objectives
Upon completion of this lab you will be able to:
z Configure a galaxy for a multi-node environment.

System Platform - Part 1

9-52 Module 9 – Multi-Node Applications

Summary Lab Instructions

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

Note: For this lab there are no detailed steps on the following pages. Only general guidance is
given to allow you the chance to put what you have learned into practice.

This section is to be performed by everyone.

Preparation
a. Undeploy your galaxy.
b. Rename the Training toolset, adding your initials to the beginning. In this example, the
Training toolset will be renamed ABTraining.
c. Rename all of your template objects, preceding each object name with your initials.
For example, Ann Brown’s initials are AB. Ann Brown would rename her Platform template to
ABtWinPlatform, her AppEngine template to ABtAppEngine, and so on.
d. Export all your templates to a file called MyTemplates.aaPKG.

This section is to be performed by the Galaxy Master only.

Export the InControl instance and create a New Galaxy

e. Export the InControl instance to a file called InControl.aaPKG.

Note: If you did Lab 19, then export both the I/O 1 and I/O 2.

f. Create a new galaxy named MultiNodeGalaxy.

g. Import the MyTemplates.aaPKG and InControl.aaPKG files.
h. Create an area instance named ControlSystem and assign the InControl object to it.
i. Create a platform instance named ABPlatform where AB is your initials and assign it to the
ControlSystem area.
j. Create an engine instance named AppEngineDI and assign it to the ControlSystem area.
k. On the Deployment view:
Host AppEngineDI on ABPlatform.
Host InControl on AppEngineDI.
Host ControlSystem on AppEngineDI.
l. Deploy the ABPlatform object on cascade.
m. Configure the galaxy’s security Authentication Mode to Galaxy.
n. Create a user account that belongs to the Administrator role for each member of the team.

Wonderware Training
 Lab 20 – Convert to Network Environment 9-53

This section is not to be performed by the Galaxy Master.

Setup the Platforms

o. Use the ArchestrA IDE to connect to the MultiNodeGalaxy galaxy in the Galaxy Master’s
computer using your designated user account.
p. Import your MyTemplates.aaPKG file.
q. Create a platform instance named ABPlatform where AB is your initials, and configure it with
your local computer’s name. Assign it to the ControlSystem area.
r. Deploy the ABPlatform object on cascade.

This section is to be performed by everyone.

Test the Galaxy

s. Create an engine instance named ABAppEngine, assign it to the ControlSystem area and
host it on your ABPlatform object, where AB is your initials.
t. Create an area instance named ABLine and host it on your ABAppEngine object, where AB
is your initials.
u. Create an instance of your mixer template and name it properly with the valid 3-digit mixer ID
at the end (ABMixer_1XX) as identified in Lab 2. Host it on your ABLine area, where AB is
your initials.
v. Deploy your ABAppEngine object on cascade, where AB is your initials.
w. Use Object Viewer to verify that all objects are running properly and are getting data from the
field.

Note: Feel free to experiment and play around with the multi-node system to reinforce the
knowledge acquired during this class.

System Platform - Part 1

9-54 Module 9 – Multi-Node Applications

– Intentionally left blank –

Wonderware Training
 Appendix A

Wonderware Application Server Glossary

A-2 Appendix A – Wonderware Application Server Glossary

– Intentionally left blank –

Wonderware Training
 Appendix A – Wonderware Application Server Glossary A-3

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

System Platform - Part 1

A-4 Appendix A – Wonderware Application Server Glossary

AutomationObject
A type of object that represents permanent things in your plant (such as Application Objects or
Device Integration Objects) as objects with user-defined, unique names within the Galaxy. It
provides a standard way to create, name, download, execute, and monitor the represented
component.
Automation Object Server (AOS)
A computer that hosts one or more application engines and associated automation objects. A
Wonderware Application Server Galaxy Namespace can contain several Automation Object
Servers, each which requires a Platform.
Backup Application Engine
The object created by the ArchestrA infrastructure when the Primary object has been enabled for
Redundancy. See Redundancy for further detail.
Base Template
A root template at the top of a derived hierarchy. Unlike other templates, a base template is not
derived from another template but developed with the Application Object Toolkit and imported into
a Galaxy. Base templates and derived templates always have a $ before their name in the IDE.
Block Read Group
A DAGroup that is triggered by the user or another object. It reads a block of data from the external
data source and indicates the completion status.
Block Write Group
A DAGroup that is triggered by the user or another object after all the required data items have
been set. The block of data is then sent to the external data device. When the block write is
complete, it indicates the completion status.
Bootstrap
The base ArchestrA service which is required on all ArchestrA computers. It provides the base
software environment to enable a platform and allows a computer to be included in the Galaxy
Namespace.
Change Log
The revision history that tracks the life cycle activities of ArchestrA Objects, such as object
creation, check-in/check-out, deployment, and import/export.
Change Propagation
The ability to create templates which will allow each component template to support changes such
that a change in one of the elements can be automatically propagated to all — or select, related —
instances.
Check-In
IDE operation for making a configured object available for other users to Check-Out and use.
Check-Out
IDE operation for the purpose of editing an object. It makes the item unavailable for other users to
Check-Out.
Checkpoint
The act of saving to disk the configuration, state, and all associated data necessary to support
automatic restart of a running AutomationObject. The restarted object has the same configuration,
state, and associated data as the last checkpoint image on disk.
Compound Object.
An Application Object that contains at least one other Application Object.

Wonderware Training
 Appendix A – Wonderware Application Server Glossary A-5

Contained Name
An alternate naming convention that when combined with the tag name of the root container
object, results in the Hierarchical Name. For instance, for a given object, it’s Hierarchical Name =
Line1.Tank1.InletValve and its Contained Name= InletValve
Containment
A hierarchical grouping that allows one or more AutomationObjects to exist within the name space
of a parent AutomationObject and be treated like parts of the parent AutomationObject. This
functionality allows for relative referencing to be defined at the template and instance level.
DAGroup
A data access group associated with Device Integration Objects (DIObjects). It defines how
communications is achieved with external data sources. It can be a ScanGroup, Block Read or
Block Write groups.
DAServer Manager (DAS Manager)
The System Management Console (SMC) snap-in supplied by the DAServer that provides the
required user interface for activation, configuration, and diagnosis of the DAServer.
Data Access Server (DAServer)
The server executable that handles all communications between field devices and client
applications. Similar in function to I/O Servers but with more advanced capabilities.
Data Access Server Toolkit (DAS Toolkit)
A developer tool used to build Data Access Servers (DAServers).
Deployment
The operation which instantiates an automation object instance in the AutomationObject Server.
This action involves installing all the necessary software and instantiating the object on the target
platform with the objects default attribute data from Galaxy Repository.
Deployment View
The part of the Applications View in the IDE that shows how objects are physically dispersed
across Platforms, Areas and Engines. This is a view of how the application is spread across
computing resources.
Derivation
The creation of a new Template based on an existing Template.
Derivation View
The part of the Applications View in the IDE that shows the parent-child relationship between base
templates, derived templates and derived instances. A view into the genealogy of the application.
Derived Template
Any template with a parent template.
Device Integration Object (DIObjects)
An AutomationObject that represents the communication with external devices or software.
DIObjects run on an Application Engine, and include DINetwork and DIDevice objects.
DIDevice Object
An object that represents the actual external device (for example, a PLC or RTU) that is
associated with a DINetwork Object. It provides the ability to diagnose and browse data registers
of the DAGroups for that device.
DINetwork Object
An object that represents the network interface port to the device via the Data Access Server or
the object that represents the communications path to another software application. It provides
diagnostics and configuration for that specific network card.

System Platform - Part 1

A-6 Appendix A – Wonderware Application Server Glossary

Element
Basic shapes, such as rectangles, lines, and text elements, and controls you can use to create an
ArchestrA Symbol to your specifications.
Engine Object
An ArchestrA system enabled object that contains Local Message Exchange and provides a host
for Application objects, Device Integration objects and Area objects.
Event Record
The data that is transferred about the system and logged when a defined event changes state (for
instance, an analog crosses its high level limit, an acknowledgement is made, or an operator logs
in to the system).
Export
The act of generating a Package file (.aaPKG file extension) from persisted data in the Galaxy
Database. The resulting .aaPKG file can be imported into another Galaxy through the IDE import
mechanism.
FactorySuite Gateway
FactorySuite Gateway is a Microsoft Windows application program that acts as a communications
protocol converter. Built with the ArchestrA DAS Toolkit, FS Gateway can be used to link clients
and data sources that communicate using different data access protocols.
Galaxy
The entire application. The complete ArchestrA system consisting of a single logical name space
(defined by the Galaxy Database) and a collection of Platforms, Engines and objects. One or more
networked PC’s that constitute an automation system. This is referred to as the Galaxy
Namespace.
Galaxy Database
The relational database containing all persistent configuration information like Templates,
Instances, Security, etc. in a Galaxy Repository.
Galaxy Database Manager
The Galaxy Database Manager is a utility you can use to manage your Galaxies. It can back up
and restore Galaxies should they become corrupted or to reproduce a Galaxy on another
computer. The Galaxy Database Manager is part of the System Management Console (SMC).
GalaxyObject
The object that represents a Galaxy.
Galaxy Repository
The software sub-system consisting of one or more Galaxy Databases.
Graphic Toolbox
The part of the IDE main window that shows a hierarchy of graphic toolsets, which contain
ArchestrA Symbols and client controls.
Hierarchical Name
The name of the object in the context of its container object. For instance, Tank1.OutletValve,
where an object called Tank1 contains the OutletValve object.
Historical Storage System (Historian)
The time series data storage system, used to compress and store high volumes of time series data
for latter retrieval. For the Wonderware Application Server, the standard Historian is IndustrialSQL
Server.
Host
The parent instance of a child instance in the deployment view. (Example: a Platform instance is a
Host for an AppEngine instance).

Wonderware Training
 Appendix A – Wonderware Application Server Glossary A-7

Import
The act of reading a .aaPKG File and using it to create AutomationObject instances and Templates
in the Galaxy Repository.
Wonderware Application Server
Refers to the Wonderware A2 Supervisory Control Platform, commonly known as the Application
Server. The Wonderware Application Server is sized by (a) the number of Workstation / Server
Platforms, (b) by real I/O in the system, and (c) the number of Terminal Services sessions. The
Application Server license is per Galaxy. An Application Server can be distributed across multiple
computers as part of a single Galaxy Namespace. The Wonderware Application Server is
designed to leverage existing Wonderware products such as InTouch for visualization, Industrial
SQL as its historian, and the device Integration product line (I/O Servers) for device
communications. The Wonderware Application Server uses InTouch v8.0 or InTouch View v8.0 for
visualization with the addition of Platforms to the visualization node.
Instance
An object, which is a unique representation of a template that can exist in runtime.
Instantiation
The creation of a new object instance based on a corresponding Template.
Integrated Development Environment (ArchestrA IDE)
The Integrated Development Environment (IDE) is the user interface for the configuration side of
Application Server. It is used to manage templates, create object instances, deploy and un-deploy
objects and a host of other functions associated with the development and maintenance of the
system. It is only available as part of the Wonderware A2 Development License.
InTouch View
InTouch View Clients are InTouch Runtime Version 8.0 clients that solely use of the Wonderware
Application Server for its data source. In addition, standard InTouch v8.0 runtimes can leverage
the Wonderware Application Server with the addition of a Platform license.
I/O Count
Number of I/O points being accessed into the Galaxy. I/O points are real I/O and are not equivalent
to InTouch tags. I/O count is based on the number of I/O points that are configured through an
OPC Server, I/O Server, DA Server or InTouch Proxy Object, over the whole Application Server
Namespace, regardless of how many PCs are in the system.
Life Cycle Cost
The cost of a Supervisory Control System attributed to initial development, application changes
and on-going maintenance. The Wonderware Application Server reduces these costs through the
use of a component object-based development environment and automated change propagation
capabilities.
Live Mode
An action in ActiveFactory that enables the configuration of a Runtime application to be refreshed
at a designated interval.
Log Viewer
A Microsoft Management Console (MMC) snap-in that provides a user interface for viewing
messages reported to the LogViewer.
Message Exchange
The object to object communications protocol used by ArchestrA and the Wonderware Application
Server.
Model View
The part of the Applications View in the IDE that shows how objects are arranged to describe the
physical layout of the plant and supervisory process being controlled.

System Platform - Part 1

A-8 Appendix A – Wonderware Application Server Glossary

Object
Any template or instance found in a Galaxy Database. A common characteristic of all objects is
they are stored as separate components in the Galaxy Repository.
Object Extensions
The capability to add additional functions to an Automation Object while not altering the objects
original behavior. Can be added to derived templates and object instances. They include Scripts,
User Defined Attributes (UDAs) and Attribute Extensions.
Object Viewer
A utility in which you can view the attribute values of the selected object in run-time. This utility is
only available when an object is deployed. Object Viewer provides the user with diagnostic
information on Application Objects for the purpose of detecting performance parameters, resource
consumption and reliability measurements. In addition to viewing an object’s data value, data
quality and the communication status of the object, you can also modify some of it’s attributes for
diagnostic testing. Modifications can include adjusting timing parameters and setting objects in an
execution or idle mode.
OffScan
The state of an Object that indicates it is idle and not ready to execute its normal runtime
processing.
OnScan
The state of an Object in which it is performing its normal runtime processing based on a
configured schedule.
Package Definition File (.aaPDF)
The standard description file that contains the configuration data and implementation code for a
base template. File extension is .aaPDF.
Package File (.aaPKG)
The standard description file that contains the configuration data and implementation code for one
or more object instances or Templates. File extension is .aaPKG.
Platform Count
Number of PCs in the Galaxy. Each Workstation and/or Server communicating directly with the
Application Server requires a platform to be part of the Galaxy Namespace. This includes each
InTouch 9.0 or higher and InTouch View 8.0 or higher client. Each InTouch Terminal Services
Session needs IAS Terminal Services Session License. A Platform License includes a per seat
FSCAL2000 with Microsoft 2000 SQL Server CAL. Stand-alone computers that only host Historian
Servers or remote DA Servers do not need a platform license.
Platform Manager
The Platform Manager provides Galaxy application diagnostics by allowing you to view the run-
time status of some system objects and to perform actions upon those objects. Actions include
setting platforms and engines in an executable or idle mode and starting and stopping platforms
and engines. This utility is an extension snap-in to the ArchestrA System Management Console
(SMC).
Platform Object
An object that represents a single computer in a Galaxy, consisting of a system wide message
exchange component and a set of basic services. This object hosts all Application Engines.
PLC
Programmable logic controller.
Primary Application Engine
The object created by the ArchestrA infrastructure when the Backup object has been created
through Redundancy. See Redundancy for further detail.

Wonderware Training
 Appendix A – Wonderware Application Server Glossary A-9

Properties
Data common to all attributes of objects, such as name, value, quality, and data type.
Proxy Object
A Proxy Objects is an Automation Object that represents an actual product for the purpose of
device integration with the Wonderware Application Server or InTouch® HMI. For example, there
is a Proxy Object that enables the Wonderware Application Server to access an OPC server.

Redundancy
During Configuration
z Primary object: The object intended as the main or central provider of the functionality in
the run-time. For AppEngines, it is the object you enable for redundancy. For data
acquisition, it is the DIObject you intend to use first as your data source in the run-time.
z Backup object: The object that provides the functionality of the Primary object when it fails.
For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary
object has been enabled for redundancy. For data acquisition, it is the DIObject you do not
intend to use first as your data source in the run-time.
During Run-Time
z Active object: The object that is currently executing desired functions. For AppEngines, it
is the object that is hosting and executing ApplicationObjects. For data acquisition, it is the
object that is providing field device data through the RedundantDIObject.
z Standby object: The passive object; that is, it is waiting for a failure in the Active object’s
condition or for a force-failover. For AppEngines, it is the object that monitors the status of
the Active AppEngine. For data acquisition, it is the object that is not providing field device
data through the RedundantDIObject.
Redundant DI Object
The RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike
redundant AppEngines, individual DIObject data sources do not have redundancy-related states.
For all intents and purposes, they function as standalone objects.
Redundant Message Channel
The Redundant Message Channel (RMC) is a dedicated Ethernet connection which is required
between the platforms hosting redundant engines. The RMC is vital to keep both engines
synchronized with alarms, history, and checkpoint items from the engine that is in the Active Role.
Each engine also uses this Message Channel to provide its health and status information to the
other.
Reference
A string that refers to an object or to data within one of its attributes.
Relational Reference
A reference to an object’s attributes that uses a keyword in place of an object's tagname. These
keywords allow a reference to be made by an object's relationship to the target attribute. Examples
of these keywords are "Me", "MyPlatform", and "MyContainer".
Remote Reference
The ability to redirect ArchestrA object references or references to remote InTouch tags. The new
script function used to redirect remote references at runtime is IOSetRemoteReferences.
Runtime
The InTouch (WindowViewer) function that provides the viewing of data from the configuration of
the application in InTouch development (WindowMaker).

System Platform - Part 1

A-10 Appendix A – Wonderware Application Server Glossary

Scan Group
A DAGroup that requires only the update interval be defined and the data will be retrieved at the
requested rate.
Scan State
The Scan State of an object in run-time. This can be either off-scan or on-scan.
Security
Wonderware Application Server security is applied to the ArchestrA IDE, the System Management
Console (SMC), and the runtime data level. At the runtime data level which centralizes the
definition of all permissions to the ApplicationObjects. These ApplicationObjects can be accessed
by a variety of clients but the security is centrally defined allowing ease of maintenance. The users
that are allowed to modify these ApplicationObjects at runtime are mapped to the objects by user
defined roles. These roles can be mapped directly to existing groups in a Microsoft Domain or
workgroup.
SmartSymbols
SmartSymbols are objects that integrate object-oriented technology with InTouch graphics to
transform them into reusable templates. Changes made to the templates automatically propagate
throughout an application – even across multiple networked PC nodes. They are created from a
graphic in an InTouch window that has been made into a cell and converted into a SmartSymbol.
In addition, libraries of SmartSymbols can be exported to other applications and plants, enabling
companies to standardize on graphics throughout the entire organization.
System Management Console (SMC)
The central runtime system administration/management user interface in which all required
runtime administration functions can be accomplished.
System Objects
Objects that represent an Area, Platform or Engine.
TagName
The unique name given to an object. For instance, for a given object, its TagName = V1101 and its
HierarchicalName = Line1.Tank1.InletValve.
Template
An object containing configuration information and software templates used to create new Derived
Templates and/or Instances.
Template Toolbox
The part of the IDE Main Window that hosts template toolsets, which contain object templates. The
Template Toolbox contains a tree view of template categories in the Galaxy.
Toolset
A named collection of Templates displayed together in the IDE Template ToolBox.
User Defined Attributes (UDA)
The purpose of a User Defined Attribute is to allow users to add new functionality to an object. An
attribute which is added to an object at configuration time
UserDefined object
An AutomationObject created from the $UserDefined template. This template does not have any
application-specific attributes or logic. Therefore, the user must define these attributes and
associated logic.
WinPlatform object
An object that represents a single computer in a Galaxy, consisting of a system-wide message
exchange component, a set of basic services, the operating system, and the physical hardware.
This object hosts all AppEngines.

Wonderware Training
 Appendix B

Plant Model Planning Diagrams

B-2 Appendix B – Plant Model Planning Diagrams

– Intentionally left blank –

Wonderware Training
 B-3

The Plant Model Planning Diagrams are displayed on the following pages.

System Platform - Part 1

B-4 Appendix B – Plant Model Planning Diagrams

Wonderware Training
 B-5

System Platform - Part 1

B-6 Appendix B – Plant Model Planning Diagrams

Wonderware Training