ArchestrA Training Manual - Class 1

Revision A
September 2007
Part Number 05-2090
on
Wonderware@Application Server 3.0 and Device Integration Products
INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

O 2007 by lnvensys 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 lnvensys
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.
lnvensys 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 lnvensys software described
in this document is subject to the terms of the applicable Wonderware Corporation or lnvensys Systems, Inc.,
license. These terms include provisions that limit your rights such as use restrictions, disclaimers of
warranties and limitations of Wonderware and lnvensys liability. A copy of the applicable license will be
displayed upon initial installation of the software. If a copy of the license is not displayed or you require an
additional copy of the license, you may obtain one from lnvensys' Wonderware business unit upon request by
calling 1.949.727.3200 or by sending an e-mail to support@wonderware.com.
Invensys; Wondeware; ActiveFactory; ArchestrA; DT Analyst; FactorySuite; FactorySuite A2; InBatch;
Incontrol; IndustrialSQL Server; InTouch; InTrack; QI Analyst; SCADAlarm; SPCPro; SuiteLink;
Suitevoyager; WindowMaker; Windowviewer; Every system in your plant, working in concert; and the
Visualize, Analyze, Optimize logo are trademarks or service marks of lnvensys plc, its subsidiaries and
affiliated companies. All other brands and product or setvice names may be the trademarks or service marks
of their respective owners.
Table of Contents
Table of Contents
Module 1
Introduction .................................................................................
- 1
Section 1 -Course Introduction
Section 2 - Wonderware System Platform
Lab 1 -Creating a Galaxy
Section 3 -The ArchestrA IDE
Section 4 -Automation Object
Section 5 - System Requireme
.............. 1-77
Section 6 - Application Plannin
Lab 2 - Identifying the Mixer .....................................................................
1-91
Module 2
Application Infrastructure .......................................................... 2-1

Section 1 - The Plant Model ..............................................................................
2-3
Lab 3 - Creating the Plant Mode
Section 2 -The Deployment Mod
Lab 4 - Creating and Deployi
........................... 2-17
Section 3 - The Runtime Envi
Lab 5 -Using Object Viewe
Section 4 - Connecting to the
........................................ 2-41
Lab 6 -Connecting to the
Module 3
Application Objects ....................................................................3-1

Section I-Templates and lnstan
Section 2 -The $UserDefined Ob
Section 3 - Change Control and Propagati
Lab 8 -Change Control and Propagat
Section 4 -The $
Lab 9 - Meter
Section 5 -The $
Lab 10 -Valv
Module 4
Extending the Objects ................................................................4-1

Section 1 - UDA
Section 2 - Exte
Lab 13 - DDESuiteLinkClient Auto Reconnect

Lab 14 -Automatic Reference Configuration
Module 5
Alarms and History .....................................................................5-1

Section 1 -Alarm
.....................................................................
Module 6
5-9
Security ........................................................................................
6-1
Section 1 - Security Overview ...........................................................................
6-3
Lab 17 -Security ......................................................................................
6-13
Wonderware System Platform 3.0 Course -Part 1
Wonderware System Platform 3.0 Course - Part 1

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

Section 1 -Exporting and Importing Objects
Section 2 -Configuring Instances Through
Section 3 -System Management Console (SMC) ...........................................
Section 4 - Network Account Utility
Module 8
Device lntegration Products ..................................................... 8-1

8-3
Section I - Wondeware 110 Server
Section 2 - Data Access Server
Section 3 - Device Integration
Module 9
7-21
7-33
8-9
-19
. .
Multi-Node Appl~cat~ons
..........................................................9-1
Section I -Application Redundancy ..................................................................
9-3
Lab 18 - Configuring Application Redundancy ......................................... 9-17
Section 2 - Dl Redundancy.................................
Lab 19 -Configuring the Re
Section 3 - Multi Node Applicatio
Lab 20 - Convert to Network
Appendix A Wonderware Application Server Glossary ...............................

A-I
Appendix B Plant Model Planning Diagrams ................................................
B-I
Wondenvare Training
Introduction
Section 1 - Course Introduction
Lab 1 - Creating a Galaxy
Section 3 - The ArchestrA IDE
Section 4 - Automation Objects
Section 5
- System Requirements, Licensing and Support
Section 6 - Application Planning

Lab 2 - Identifying the Mixer
1-2
Module 1 - Introduction
Module Objective
Introduce the Wonderware@System Platform and its archftecture, envlronrnent, and
requirements for installation and l~censing.
Wonderware Training
Section I Course lntroduction
Section I- Course lntroduction

Section Objective
This section :denrifies the objectives and agenda for the Wonderware System Platform 3.0 - Part
1 course as well as the key basics of Wondeware Application Server.
This section describes the Wonderware@System Platform 3.0 course - Part 1, (Wonderware
Application Server 3.0), the objective of the course, intended audience, prerequisites, and the
course agenda. It also includes a description of Wonderware Products.
Course Description
The Wonderware System Platform 3.0 - Part 1 course is a four-day, instructor-led course designed
to provide a fundamental understanding of the basic principles of ArchestrAa and supply the
knowledge necessary to develop and support applications for the Wonderware Application Server
3.0. The course utilizes a number of hands-on labs to reinforce concepts and features.
The focus of this course is to illustrate the use of ArchestrA@tools and services in the System
Platform to develop a project utilizing connectivity to the field, data processing, scripts, alarms and
nistory, using feat~resand f~nctionaitys ~ c as
h A~tomationObjects, templates, template
nstances, ArchestrAO Integrate0 Development Env ronment and Quickscript .NET.
This course also provides a fundamental understanding of how to utilize the lnTouch@Alarm DB
Logger for real-time alarm recording as well as the security settings available for securing the
applications.
Course Objectives
Upon completion of this course, you will be able to:
e
Create new projects using ArchestrAB Integrated Development Environment
Model the plant floor using automation objects

Work with the alarm and history configuration in the Galaxy
Configure ArchestrAB security in the Galaxy
Troubleshoot Wonderware Application Server applications
Audience
This training class is targeted to engineers, application developers, system integrators, and other
individuals whose jobs include creating and/or maintaining a Galaxy for use with the Wonderware
System Platform
Prerequisites
The prerequisites for this course are:
Completion of Getting Started with Wonderware Application Sever web tutorial located at
http://ww.wonderware.com/training/online~training/tutorials.asp
e
Manufacturing industry experience
Wondeware System Platform 3.0 Course -Pad 1
1-3
1-4
Module I- Introduction
Agenda
Module I- lntroduction
Section I -Course lntroduction
This section describes the Wonderware0 System Platform 3.0 course - Part 1, (Wonderware
Application Server 3.0), the objective of the course, intended audience, prerequisites, and the
course agenda. It also includes a description of Wonderware Products.
This section provides an overview of the Wonderware System Platform, the architecture of
ArchestrA and the importance of how it is critical to plant automation, and an overview of the
differences between Object-oriented and traditional Tag based HMI and SCADA products and
how it applies to Wonderware System Platform applications. It also provides an understanding
of what a Galaxy is, how it relates to the Galaxy Database and the Galaxy Repository and how
a Galaxy is created.
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 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.
Module 2 - Application Infrastructure

Section I -The Plant Model
This section provides an explanation of the importance of having a model of the plant facility.
Additionally, it explains the concept of how to utilize ArchestrA Application Server to model a
specific facility.
Lab 3 -Creating the Plant Model
Section 2 -The Deployment Model
This section provides an explanation of the Deployment Model and demonstrates the structure
of the Deployment Model.
Wondeware Training
Section I- Course Introduction

Lab 4 -Creating and Deploying 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 t o the Field
This section provides an understanding of the Device Integration Objects, I10 Server and DA
Sewer. It also provides an overview of Dl Objects.
Lab 6 - Connecting to the Field
Module 3 -Application Objects

Section I-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 5UserDefined object and its functionality.
Lab 7 - 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 - Change Control and Propagation
Section 4 -The $AnalogDevice Object
This section introduces you to the concept of the 5AnalogDevice object and its functionality.
Lab 9 - Meter
Section 5 -The SDiscreteDevice Object
This section introduces you to the concept of the 5DiscreteDevice object and its functionality.
Lab 10 -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 -Mixer
Module 4 - Extending the Objects

Section 1 - UDAs
This section introduces and explains WDAs and how they are configured and used
Section 2 - Extensions
This section provides describes the Output Functionality for Application Objects in the
Extensions environment.
Lab 12 - Motor Speed
Section 3 - lntroductiori t o Quickscript .NET
Wonderware Svstern Platform 3.0 Course Parl 1
1-5
1-6
This section introduces and explains the scripting environment and the various scripting
configuration attributes of the Applicationobject
Module 5 - Alarms and History

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

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
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.
This section discusses the role of changing thenetwork account and how to use the Change
Network Account and how to configure it.
Module 8 - Device Integration Products

Section I - Wonderware 110 Sewers
This section will describe the configuration of a Wonderware 110 Server (Modbus)
Section 2 - Data Access Servers

This section provides familiarization with DASewer and its use with Wonderware Application
Server.
Wondenvare Training
1-7
Section 3 -Device Integration Objects

This section provides familiarization with Dl Objects and their use with Wondenvare
Application Server.
Module 9 - Multi-Node Applications

Section I -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 Dl Objects
Lab 18 -Configuring Application Redundancy
Section 2 - Dl 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 Dl Objects
Lab 19 -Configuring the Redundant Dl 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
.-
Wondenvare System Platform 3.0 Course -Pad 1
1-8
Wonderware Software Solutions

WonderwareB Software Solutions provide valuable tools for optimizing and standardizing your
industrial organization. They offer essential time- and cost-saving techniques that increase
efficiency and reduce application engineering effort and deployment.
The solutions deliver manufacturing and operational performance improvements that can reduce
the amount of project-specific work required to develop information and automation applications
that are integrated across entire operational enterprises. These solutions can also be implemented
in the context of existing systems, at your own pace and to the extent that you choose.
The Wonderware solutions leverage a powerful, layered software architecture that enables a
variety of features and capabilities.
Wonderware Approach
to industrial Applications
Microsoft@ Technologies, such as Microsoft Windows@, Microsoft SQL Server, and

.NET, are applied as a basis, enabling compatibility with commercial IT hardware and
software.
Wonderware System Platform and Wonderware Client Software provide a
comprehensive set of services and capabilities to enable an industrial infrastructure that
includes all the necessary functions needed by any industrial application solution.
Function-Specific Modules make it easier than ever before to optimize production and
performance management by providing common tools for a variety of functions, from
tracking production orders to analyzing performance data.
Wonderware Quickstarts provide examples of configuration best practices, pre-defined
graphics, and Web reports, using a fully functional and documented demo application.
All Wonderware Software Solutions-whether in the areas of Supervisory HMI, Production and
Performance Management, or Geo-SCADA-leverage the comprehensive ArchestrAB industrial
automation and information software architecture.
Wonderware Training

Wonderware System Platform
The Wondeware System Platform provides a single platform for all the SCADA, Supervisory HMI,
and Production and Performance Management needs of industrial automation and information
personnel. The Wonderware System Platform, built on ArchestrA technologies, is a strategic
application infrastructure. Its modular approach allows new application components to be created
now, with the understanding that the requirements, and even the application itself, could
completely change tomorrow.
Functional Capabilities
The Wonderware System Platform contains an integral core set of capabilities and services to
support sustainable production and operations performance improvements via a comprehensive
set of six capability areas:
Industrial domain services for industrial computing functions that are not provided by
commercial operating systems or products
Software and device connectivity services for easy communication to any plant or
business information source
Information and data management services for management of real-time and historical
information
Information-delivery and visualization services for functions that provide information to
the right user at the right time, and in the form in which they expect it
Application development services that provide easy and intuitive development of
modular industrial software solutions that are easily changed to meet future needs
System management and extensibility services that provide easy management,
expansion, and modification of the application or host computing architecture
Wonderware Svstem Platform 3.0 Course -Pad 1
1-9
1-10
S y s t e m Platform Components
The Wondeware System Platform consists of a variety of software components

e
Wonderware Application Sewer (formerly known as Industrial Application Server)
framework for system-wide, real-time data acquisition, alarm and event management,
centralized security, data manipulation, remote deployment, and collaborative engineering
Wonderware Historian (formerly known as IndustrialSQL ServerTM)plant data historian
e
Wonderware lnformation Sewer (formerly known as Suitevoyage@) industrial portal
software for Internethtranet visualization and content management
Wonderware Device Integration Tools for field device connectivity
Wonderware Clients
e
Wonderware InTouch63 View human-machine interface (HMI) software as a visualization
client for the System Platform
e
ActiveFactoryTMtrending and analysis software
Reporting Client-Access Licenses for lnformation Server to enable information-sharing
and reporting over the Web
Wonderware Functional Modules
To complement the capabilities and benefits offered by the Wondeware System Platform,
Wondeware also offers a set of easily implemented add-on modules to assist you in the areas of
Performance Management, Production Management, Supervisory Control, and Geo-SCADA.
Wonderware Training
Section I-Course Introduction

Production and Performance Management Software Solutions
Wonderware provides tools that empower you to take a proactive approach to production and
performance management. Appropriate for a wide range of manufacturing and production
operations, these integrated software applications are designed to drive operational improvements
and substantially decrease total cost of ownership.
These soflware solutions:

Integrate with your existing plant, IT and business systems, creating one effective system
for the entire organization
e
Leverage a single, open and scalable soflware architecture called the ArchestrA industrial
automation and information software architecture
e
Complete MES and flexible batching capabilities that can help you actively manage
production and collect data for analysis and reporting
Enable secure, wide-scale delivery of reports on KPls, downtime, OEE, and SPC through
a powerful portal that delivers the information contextually
Improve data analysis and information sharing with advanced trending and reporting
capabilities
.*
1-11
Module 1 -Introduction
P r o d u c t Offerings
The Wonderware Production and Performance Management Software Solutions consist of a
variety of products:
Wonderware System Platform providing a core set of service capabilities as a
foundation for application development, operations, and information delivery
lnBatchTMflexible batch management software
e
Manufacturing Execution Module (formerly known as lnTrackTM)resource and WIP
tracking software
e
Equipment Operations Module for formula management including product definitions
and equipment setups, and for capturing and storing information from production events
including product and production history and genealogy
e
Equipment Performance Module (formerly known as DT AnalystTM)equipment
downtime tracking and performance management software
e
QI AnalystTMfor using real-time and historical data to monitor, analyze, and predict
potentially harmful process variations, allowing for online adjustments for improved
production quality and consistency
Supervisory HMI Software Solutions

The Wonderware market-leading Supervisory HMI Software Solutions can be applied in process,
discrete, and hybrid markets where there is demand for an information and automation
infrastructure for centralized monitoring and control. These software solutions enable plant
personnel to:
e
Easily design, build, deploy and maintain the most flexible and secure supervisory
solutions with the lowest total life-cycle costs
e
Scale from a single machine up to multiple networked supervisory stations
Integrate plant devices, databases, and control systems
0
Incorporate strong security at the data-element level and for every user in the system
Rapidly expand production and performance management solutions
Standardize on a common set of supervisory HMI tools at all levels of the plant with
rugged Wonderware Industrial Tablets and Touch Panel Computers, which are prebundled with powerful visualization software
P r o d u c t Offerings
f h e Wonderware Supervisory HMI Software Solutions consist of a variety of products:
e

a core set of service capabilities as a
InTouch human-machine interface (HMI) software for process visualization and control
lnControlTMreal-time control software
Wondeware Training
Section I- Course Introduction

Geographically Distributed SCADA (Geo-SCADA) Software Solutions
Since the late 1980s, the Wondeware Geographically Distributed (Geo-SCADA) Software
Solutions have been present in almost every industry including water & wastewater, oil & gas,
facility management, power delivery, transportation, and telecommunications.
These solutions offer several unique features that can greatly benefit companies looking to
implement a new SCADA solution or upgrade an existing system.
The easiest and most efficient, open software solution for SCADA
Highly available, reliable, and scalable SCADA applications
Single-click software redundancy
Leverages ArchestrA architecture for easy configuration and management of operational
and system security that is compatible with existing IT security capabilities
Empowers users to design, build, deploy, and maintain standardized SCADA applications
Lowest total system lifecycle costs
Product Offerings
The Wondeware Geo-SCADA Software Solutions consist of a variety of products:
e
foundation for application development, operations, and information delivery.
e
SCADAlarmTMevent notification software for real-time alarm notification, data acqqisition,
and remote control from telecommunication devices to industrial automation software
systems
Wondeware Syslem Plalform 3.0 Course -Part 1
1-13
1-14
Wondenvare Individual Software Products
All the latest Wonderware software offerings leverage the latest ArchestrA technology and are
essential to the Wonderware Production and Performance Management, GEO-SCADA, and
Supervisory HMI Software Solutions.
The following Wonderware products offer increased functionality and flexibility as well as
extensive connectivity:
e
Wonderware Application Server (formerly known as Industrial Application Sewer) for
system-wide, real-time data acquisition, alarm and event management, centralized
security, data manipulation, remote deployment, and collaborative engineering
rn ArchestrA Object Toolkit for creating application objects for use within the
Wonderware Application Sewer
e
e
e
Functional Modules for searnlessly integrating new functional capabilities into
Wonderware Application Sewer applications using a modular approach, including:
Equipment Operations Module for formula management and real-time production
events collection
Equipment Performance Module (formerly known as DT Analyst) for equipment
downtime tracking and performance management
rn
Manufacturing Execution Module (formerly known as InTrack) for resource and
WIP tracking
Wonderware Historian (formerly known as IndustrialSQL Server) real-time historian for
SCADA and factory data
e
Wonderware Information Server (formerly known as Suitevoyager) Web analysis
software for InterneVintranet visualization and content management
e
Device and Software Connectivity Tools offering a library of hundreds of DA Servers
and 110 Servers, the DA Server Toolkit, and Device Integration (Dl) Objects
InTouch View human-machine interface (HMI) software as a visualization client for the
System Platform
ActiveFactory trending and analysis software for accelerating and improving decisionmaking at all levels within an organization
QI Analyst statistical process and quality control software to predict process variations
and enable online adjustments for improved production
e
Incontrol real-time control soflware
InBatch flexible batch management software
e
SCADAlarm event notification software for real-time alarm notification, data acquisition,
and remote control from telecommunication devices to industrial automation software
systems
0
InTouch for Terminal Services software for remote hosting of InTouch applications
Wondenvare software offers robust, best-of-breed soflware components that empower customers
to effectively develop and manage their automation and information applications in continuous,
discrete, process, hybrid, and batch manufacturing environments.
The Wonderware mission is to power intelligent plant decisions in real time.
.-
Wondeware Training
Section I- Course introduction

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 controll
simulation systems.
ArchestrA leverages advanced software technologies to fill the gap between ERP systems and the
control systems. This architecture provides the following:
e
Framework: supports common services and a core set of system objects
e
Domain Objects: are industry-specific objects
Object Development Toolkit: allows 3rd parties to create new domain objects
customized for specific needs
The ArchestrA infrastructure, or Framework, supports core services that are required by most of
the different types of supervisory control and manufacturing information systems mentioned
above. These core services include the following:
Integrated development environment
Version management
License management and centralized deployment
System diagnostics and system administration
Internationalization
Data visualization and monitoring
Event based processing, scripting, and calculation capabilities
Alarm and event management, historization, and security
Data acquisition and field device integration
Inter-object communications and name service
Reporting and ad-hoc query capability
Support for industry standards such as OPC and SQL
The ArchestrA Framework consists of:
Configuration and Deployment Related Components: which include the centralized
object repository (called Galaxy Repository), integrated development environment (IDE)
and object deployment services (called Bootstrap). These components are installed just
like any other Windowsa application. They are required for centralized deployment of the
runtime components.
Runtime Components: which include PCs with core infrastructure (called Platforms), key
software applications (Engines) and objects (Framework Objects) that expose framework
related functionality. These components are centrally deployed and administered.
Wanderware System Plafform 3.0 Course - Parl 1
1-15
1-16
- Intentionally
Wondenvare Training
left blank -
This section provides an overview of the Wonderware System Platform, the architecture of
ArchestrA and the importance of how it is critical to plant automation, and an overview of the
differences between Object-oriented and traditional Tag based HMI and SCADA products and
how it applies to Wonderware System Platform applications. It also provides an understanding 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, ArchestrAe
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:
e
lndustrial domain services
e
Software and device connectivity services
Information and data management services
0
Information-deliveryand visualization services
e
Application development services

System management and extensibility services
Industrial Domain Services

The Wonderware System Platform offers industrial domain services that are not provided by
commercial operating systems or generic IT products. It provides a powerful infrastructure that
Wondenvare System Platform 3.0 Course -Part 1
1-17
Module I - Introduction
enables Wondeware 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, 2417.
Industrial Domain Services provide:
Real-time, peer-to-peer communications and messaging, enabling instant responses
High computing availability and redundancy for critical applications
r
Centralized alarm- and event-monitoring for operational conditions
..
Data-level security to protect plant equipment

Audit logging and extended security protection for developers and system-maintenance
personnel
Pager, mobile phone, PA system and e-mail alerts for unattended operational monitoring
A single global Namespace to access data elements anywhere, without tag limitations
Plant information and supervisory functions to script special behavior and responses
Support for slow and/or intermittent data networks
Software and Device Connectivity Services

The Wondeware System Platiorm 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:
e
Integration of manufacturing and business systems
e
Easy importing and migration of legacy systems and external system configurations
e
Conversion of non-structured devicecommunication models into structured systems to
increase the maintainability of applications and systems
Connectors and communication servers for control devices, applications and systems
including:
Automation devices, control systems and HMls
m
Historians and relational databases
Quality and maintenance systems
I
I
Enterprise resource management (ERP) and business systems

Manufacturing execution systems (MES)
Information and Data Management Services

Furthermore, the Wondeware 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 becauseit enables immediate access to key
Wonderware Training
Section 2 - Wonderware Svstem Platform

performance indicators (KPls); 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 Wondeware
System ~lafformprovides 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:
e
Content management tools
e
Streaming real-time data (available to all authorized users)
A high-performance process historian and production database that offer:
A production history archive for a single production line, an entire facility or the
complete enterprise
rn
Data compression, which reduces disk storage and makes more data available online
An historical archive that's auto-configured, eliminating duplicate work
Off-line and late data handling for:
rn
Manual data
Labs and quality systems
Remote terminal unit (RTU) environments
Correlation of events and alarms with production history
Data transformation and normalization
Data Buffering and Store & Forward features
Simple and fast configuration with powerful process event monitoring
rn
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
1-19
1-20
Module I
- Introduction
Capabilities
e
Multiple client interfaces [i.e., Thick, Terminal Services Edition (TSE) or Web Client]
.
e
Visualization and HMI

Expansive graphical user interface (GUI)
Access-level Windows authentication and data security, as well as enhanced
password encryption
Comprehensive alarm troubleshooting tools
Information Analysis and Reporting
Integration with trending tools and Microsoft Office products
Production, SPC, downtime and batch analysis tools
Automatic data retrieval calculations - reduction and aggregate methods
Open SQL access, enabling simplified data queries with powerful retrieval modes
Secure access across firewalls
Multi-language client support
Application Development Services

The Wonderware System Platform and its underlying ArchestrA technology provide easy and
intuitive development of modular industrial software solutions, which can be easily changed to
meet Wonderware customersi; 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.
.-
Wondeware Training
Section 2 - Wondenvare System Platform

Application Development Services provide:
Flexible, comprehensive software development capabilities for HMI andlor MES
applications
Advanced ArchestrA technology, which facilitates the assembly of applications that are
component-based and generated from standard templates
e
Smartsymbol technology, enabling the creation of re-usable graphics
e
Different development views, which show:
.
e
How the application is related to the facility or plant

How the application is distributed across the network
rn
Parent-child relationships for templates and runtime components
Multi-Developer Environment for concurrent development
Modeling -Applications can be structured based on a plant model; are self-documenting;
and offer common security, validation and audit trails
Unification with Microsofl products including:
Microsofl Windows operating systems
The Visual Studio development system
m
rn
SQL Server, BizTalk server

Sharepoint services
Microsofl Office
Internet Ex~lorerinternet browser
System Management and Extensibility Services

Furthermore, the Wonderware System Platform facilitates the easy management, expansion and
modification of applications or the host computing architecture. These services provide a range of
architectural choices, both during the initial system design phase and throughout the lifetime of an
installed system.
Leverage the flexible and scalable ArchestrA soflware 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:
e
The ability to re-architect systems at any time to support different system topologies (i.e.,
Single Node, ClientIServer, Peer-to-Peer or Web-centric
e
Easy redistribution of server load
Remote application installation and administration
e
An online configuration database that centrally maintains soflware
e
Remote change propagation
e
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.
W o n d e w r e System Platform 3.0 Course Part I
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 lnvensys 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 ~ l a n t s .
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 realtime environment. In other words, the majority of manufacturers have not successfully integrated
the functionalities of automationlbusinesslinformation 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
v
find it difficult to quantify resulting tangible benefits.
Wondeware Training

The most compelling aspect of the problem now facing manufacturers is that the underlying
technology of these systems is rapidly becoming obsolete. As general technology lifecycles
shorten, manufacturers are pressed to procure and integrate new technologies with everincreasing speed - making the ultimate goal of productivity improvement even more difficult to
achieve.
BUSINESS
SYSTEMS
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, lnvensys has developed a solution, ArchestrATMautomation 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 !/A Series A2TM
system (IIA Series A2) has taken the first major step toward reducing the risk of automation
obsolescence and protecting manufacturers' investments far into the future.
Wondenvare System Plalform 3.0 Course -Pad 1
1-23
1-24
Manufacturing Goals
For approximately a decade, manufacturers have been revising business practices, organization
charts, and systems infrastructures to become more market-driven and customer-centric. Their
overall objectives have been straightforward and consistent:
Become more responsive to market shifts and the increased competition brought on by
globalization
0
Develop greater agility and a more collaborative, data-driven environment.
Synchronize the manufacturing process with planning and scheduling functions to
optimize enterprise performance
Empower operators with critical information to foster improved plant performance
e
Utilize existing assets more efficiently to increase production, without the need to expand
the plant or build new capacity
e
Ensure the greatest possible return on assets, and improve profitability, in the face of
continuing manpower reductions
.
.
To achieve these goals, managers know they can no longer simply "invest in technology" and
expect improvements to come about automatically. In fact, millions of dollars have already been
invested with only marginal returns. However, management cannot afford to stand still, because
there are significant rewards to be reaped by those who develop improved responsiveness,
greater agility, and a higher return on assets.
Compounding the problem, many of yesterday's automation and information systems are
beginning to show their age, failing to offer the agility or rapid response that today's producers
require. Acting as a massive anchor, they actually impede the organization's forward progress as
they increasingly require greater amounts of maintenance and the corresponding expansion of
infrastructure support. But the original investment in these systems was so extensive - and so
visible to owners and investors - that it is understandably difficult to broach the subject of
"bulldozing" and starting over with the latest generation of technology. Further, it means not only
eliminating extensive hardware infrastructure, but also destroying an asset that is even more
valuable - the intellectual capital unique to the manufacturing mission.
Synchronization of Systems
Today's collaborative manufacturing environment requires that manufacturers synchronize
automation systems with business/information systems to accomplish total supply chain
management.
To facilitate this collaborative environment, many manufacturers are working toward a rational,
cost-effective solution that does not require enormous investment and allows for the preservation
of as much existing infrastructure as possible. They are preserving, to the maximum extent
feasible, existing investments in hardware and software, as well as in intellectual properties
contained in application-specific software. They are working to synchronize the various
informational elements within the manufacturing domain, namely automation systems, business
systems, and information systems, thereby fulfilling these systems' original promise of improved
manufacturing efficiency. They are identifying optimal long-term strategies based on total cost of
ownership.
The pace of change has increased to a point at which it is difficult for manufacturers to execute a
new strategy before market conditions change once again. Today's manufacturer, however, must
have the ability to respond to challenges that are virtually unanticipated. Response times have
now become the cornerstones of manufacturing competitiveness, and will remain so for the
foreseeable future.
Wonderware Training

The challenge has been to develop an architectural infrastructure that optimizes quality, customer
satisfaction, and efficiency of operation, while facilitating quick response and easy reengineering.
And to identify and deploy a plant information superstructure that embraces existing systems while
providing expansion capabilities for the long term.
Such an architectural infrastructure is available through ArchestrA. This allows manufacturers to:
Preserve a significant portion of their existing automation and information infrastructures
e
Integrate and synchronize existing production systems and new applications
e
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 ~ l a n t .
ArchestrA Architecture
ArchestrA, developed by lnvensys, 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.
BUSINESS
SYSTEMS
Wondeware System Platform 3.0 Course -Part 1
1-25
ArchestrA enables manufacturers to synchronize the various informational elements within the
manufacturing domain and supply the information required by business systems in real time.
ArchestrA provides a number of key functions designed to free users from the complexities of
dealing with current underlying technologies. So users require only assembly skills, not
sophisticated programming knowledge, and are able to apply their time to functions in which they
have more expertise. By embedding common application services directly into a common
infrastructure, application engineers can design and reuse solutions that are instantly integrated.
The key elements of the software infrastructure are the following:
Common design and development environment
e
Deployment, scripting, and calculation services
e
Alarm and event subsystems with reliable delivery
Built-in distributed architecture services for scalability
Integration with various types of field devices
.
..
e
e
e
e
e
e
Inter-object communication and name service management

Version management services
Security model services
Centralized license management and deployment services
Centralized system diagnostics and administration
Internationalization of objects and application services
Graphical user interface (GUI) editing services
Automation lnformation 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 lnformation 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 lnformation
Pyramid.
Wondeware Training
Wondeware System Platform 3.0 Course -Part I
1-27
1-28
Scalability
Wonderware Application Sewer 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.
I,
Structure
Graphics Development
Background Process
Promotion of Standards
Global Application Change
Data Represented By
1 Hlerarchlcal
Done Last
Developed in Objects
Strictly Enforced
Progagated from Templates
Physical Devices as Objects
Tag Based
Flat
Done Early
Developed in Tags
Not Strictly Enforced
Changed in Tools like Excel
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 Microsofl Excel or as a text file and then
re-imported into the application. Reuse in a tag-based system is commonly instituted through
dynamic or client-server referencing, that allows a common graphic to be created. Then a script is
executed to switch the tags being viewed in run-time. Furthermore, because of the flat structure of
the application, changes need to be sought out and analyzed as to the affect on the rest of the
application.
Use of the word "Object-oriented" with SCADA

The phrase "Object-oriented SCADA" has been with us since the early 1990's. It is mostly used
today to refer to the ability to build graphics and draw pictures based on classes or a hierarchy.
This is referred to as Object Oriented Graphics. This allows you to build a symbol and replicate it
across a screen or HMI application and have visual changes made to all the similar symbols at the
same time. This is useful functionality, but SCADA applications are more than just pretty pictures. .For example, the majority of work that goes into a supervisory application is for things like:
e
Alarm Monitoring
Wondenvare Training
Section 2 - Wondeware System Platform
e
e
e
e
0
Animation Scripts
Security Scripts
Supervisory Scripts
Historical data storage
Integration with other applications and Databases
Event Detection
Flow and movement calculations
Device integration
AlarmstEvents
ocumentation
In order to fully realize the benefit of an Object-oriented architecture, a SCADA System today
needs to depict all of these things, along with the graphics as objects.
Types of objects
In object-oriented SCADA, objects contain the aspects or parameters associated with the device
they represent. For example, a valve object can contain all the events, alarms, security,
communications and scripting associated with a device. Objects don't just represent plant
equipment. They can also model common calculations, database access methods, Key
Performance Indicators (KPls), 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.
Wondenvare System Platform 3.0 Course Paii 1
Using object-oriented tools in manufacturing applications
Manufacturing applications typically have a lot of common components. These include common
types of:
Plant devices and equipment
e
Operating procedures
Process measurements
Calculations
e
Graphics displays
This leads to a cookie cutter approach, where typically small software programs are developed as
objectslcode modules that can be stamped out and joined together to form an application. Almost
all of the automation vendors have this capability today with their software. Where an objectoriented SCADA System is different, is that after the cookies are stamped out, you can change the
stamp, and all of the cookies you already made are automatically changed
Parent
Template
Child Objects
Replication
D~aphragm
valve
Diaphragm
valve
D~aphragm
valve
D~aphragm
valve
1
Change
Propagation
Powered
valve
Powered
valve
Powered
valve
Powered
valve
This is possible because when a SCADA package is truly object-oriented, it has the notion of a
parent-child relationship, where parent templates are developed and then "Child Objects" are
replicated or instantiated from the parent templates. Now all of the children are tied back to the
parent, so a change in the parent can be replicated to all of the children. This is an extremely
powerful development capability in that:
Application creation is optimized by using parent Templates and automated child object
replication
Project change orders are easily accommodated by making changes in the parent
template and having the child objects inherit the changes via change propagation
Ongoing system changes and expansions are easier and more cost effective because of
automated object replication and change propagation
Wondenvare Training

Traditional, Tag Based SCADA Development Process
From the inception of PC based HMI and SCADA software, users have built operator graphics and
linked them to tags, which represented addresses in a PLC or a control system. The concentration
was on the computer and the software application. Here is an example of how a traditional tagbased SCADA application is developed.
1. A new HMI application is created on a single computer
2. Windows or displays are created for the application

3. Graphics are created for the windows
4. Tag definitions are imported from the PLC or manually configured
5. Alarm and Event Detection Scripts are defined for each tag
6. Tags are linked to graphic elements

7. Graphics animation scripts or links are created
8.
1
0 Tags are defined and linked to the application
9.
If the application is to be deployed in a client-server environment, the application is rearchitected to centralize alarming, event detection, history archiving, graphics and 10 servers.
10. Changes to the system require shutting down the application, making changes to the many
scripts and tag database references to enable the new functionality, and reloading the new
HMI application on each workstation.
Object oriented Development Process- graphics are created last

Wondenvare Application Sewer and the ArchestrA Integrated Development Environment (IDE)
have brought a new era to SCADA Software development through the ability to create a complete
plant device model. The developer is abstracted from the complexities of the computing
environment and allowed to concentrate on "modeling" how the production facility is laid out and
the different manufacturing cells and processes that comprise plant-wide supervisory control.
Once the plant model is captured, it is easy to implement supervisory control functions. A small
investment in creating Templates yields big results in engineering productivity. The ten easy steps
to creating a supewisory application using the Application Sewer 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 supewisory 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, inputloutputs, 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 I drain valves and agitator.
Wondemare System Platform 3.0 Course Pae 1
1-31
5. Device templates have attributes which represent real I10 available in the PLC or control
system. These attributes are then linked to the I f 0 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 lnTouch@,the world's most popular HMI software
package. This can also be done using the Smart-Symbol functionality contained in InTouch
9.0 SP 2 which allows a graphic element to be created and linked to a template in the
ArchestrA IDE. That way the display graphics are also object-oriented and tightly coupled to
the plant model.
10. Once the application is developed, maintenance of the system is easy. Changes made to
Templates can be propagated to the "Child Objects" linked to the Templates. For example, if
the units associated with a level transmitter need to change from gallons to liters, this can be
done once in the template, and the changes can automatically propagate to all the operator
displays in the plant.
Wondenvare Training

Plant Model for Developing Application Server Course Application
In this course, the manufacturing environment that is modeled centers on a Plant with various
Tanks and assorted Tank related components. Initial focus is on one Area of the Plant and model
that Tank System in the Integrated Development Environment (IDE) of the Application Server.
Templates are then developed which allow for the simple creation of multiple instances of your
Tank System.
The following Figure illustrates the Tank System Model that created in the application developed
throughout the course of this class.
AGITATOR
B
PUMP 1
OUTLEl
What is a Galaxy?
It's important to understand what a Galaxy is before one is created. A Galaxy is your whole
application. The complete ArchestrA system consisting of a single logical name space and a
collection of WinPlatforms, AppEngines and objects. One or more networked 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.
Wondeware Sysfem Platform 3.0 Course Part I
1-33
1-34
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 t o Galaxy dialog box is displayed.
This dialog box is comprised of three groups of options:

Galaxy RepositoryIGalaxy connect selections: This consists of the GR Node Name and
Galaxy Name boxes.
Action buttons: Connect, New Galaxy, Delete Galaxy, About and Cancel.
e
Licensing information
If the Galaxy Name box is empty, you have not yet created a Galaxy on the computer shown in the
GR Node Name box. Before you can start the ArchestrA IDE, you must either browse for a Galaxy
on another node or create a new Galaxy.
All new Galaxies are created with no security. They also have the following characteristics: two
users (Defaultuser and Administrator, both with full access to everything), two security roles
(Default and Administrator, both with full privileges) and one security group (Default).
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.
Wondeware Training
Lab 1 - Creating a
Introduction
This lab illustrates the steps necessary to create a default Galaxy and open the ArchestrA
Integrated Development Environment (ArchestrA IDE). Throughout this class you will use this
Galaxy to develop a sample application.
Objectives
Upon completion of this lab you should be able to:
r
Create a Galaxy
r Open the ArchestrA development environment
Note: To better facilitate the clarity of individual work in this training environment, because of the
Global Naming Space, ALWAYS preface the object name with your FIRST and LAST initial.
(e.a., if the user is Ann Brown, Valve would be ABValve)
Summary Lab lnstructions

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 Galaxy
1. Create a new Galaxy named cyour initialszGalaxy.
2. Connect to the new Galaxy and open the ArchestrA development environment.
See the next page for Detailed Lab lnstructions
Wondenvare System Platform 3.0 Course - P a d 1
1-35
1-36
Detailed Lab lnstructions

Following are Detailed Lab Instructions for completing this lab. For a summary of instructions,
please refer to the Summary Lab lnstructions on the previous page@).
Create a Galaxy
1. Launch the Integrated Development Environment by selecting Start IAll Programs I
Wonderware IArchestrA 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. The New Galaxy dialog box is
displayed.
Note: The different Galaxy types will be discussed later.
Wondeware Training
Lab 1 - Creating a Galaxy

3.
For Galaxy name enter the ABGalaxy and make sure Galaxy type is set to
This must be the

node that contains
the Galaxy
Repository (the
Host name of the
computer).
4.
Click the Create button to continue

This will display the Create Galaxy dialog box indicating the progress on creating the new
Galaxy
Creating galax/ A B G a l a v on S\I'SPiATFORL!VPC
Creating Galaxy 'ABGalaxy' on SYSPiATFORI,!VPC ...

... with Security not enabled
Cleaning up File and Global Data Repositories...
Restore galaxy begin
Get database connection information
Get file repository information
.
-
-.
...
.I
35% completed
I
...
-.
.: ..,
Wonderware System Platform 3.0 Course -Pad 1
1-37
1-38
5. As soon as the process is complete and the Close button is enabled, click Close
uccess u y c e
Get database connehon ~nformabon

Get file repository lnformabon
Remove restore duectory
Restore from backup files
Restore database
Restore file repository
Restore global data
El
6. At the Connect To Galaxy dialog box the name of the newly created Galaxy, ABGalaxy, is
displayed in the Galaxy name drop-down list.
Click the Connect button.
Wonderware Training

This closes the Connect To Galaxy dialog box and displays the Integrated Development
Environment (ArchestrA IDE).
Wondeware System Platform 3.0 Course Pad 1
1-39
1-40
- Infentionally left blank -
Wondeware Training

Section Objectives
..
Discuss ArchestrA IDE

Introduce the Template Toolbox and Application Views
Discuss the object Check-intcneck-out process.
This section provides an overview of the ArchestrA IDE, the Template Toolbox and Application
Views and the object Check-inlcheck-out process.
The ArchestrA IDE User-Interface

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

The Main window is the user interface in which you can create your appliCation and deploy it to
your enterprise. This main window provides the key platform where a wealth of functionality
capability can be accessed and configured. Some of these key functions include the following.
Galaxy Configuration
Connect to an existing Galaxy on the network
D
Create a new Galaxy
Destroy a Galaxy
ImporVExport Objects (aapackage, .csv)
s ImporVExport script function libraries (.dll, .tlb, .olb, .wdf, .aaSLIB)
Security Configuration
Configure User security
rn
Configure Object security
e
Object Configuration
rn
Create new objects
rn
Check out objects
Edit objects
m
Configure Historization through objects
rn
Configure objects for Alarms and Events
Extending object functionality
rn
Check in objects with comments
Deploy/undeploy objects
a
Propagate changes to runtime objects
rn View object's configuration errorstwarnings
1-41
1-42
Upload runtime changes to Galaxy database

IDE Configuration
Set user preferences
Create a Tool Box
As the main aspects of the ArchestrA IDE Main View (e.g., Menu options, Toolbars, Template
Toolbar and Application Views, etc.) are identified and discussed, they are elaborated on in
greater detail as to how these Key Functions can be used
The ArchestrA IDE User Interface

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

Operations View
Status bar
Wondeware Training

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.
Menu Bar
The ArchestrA IDE Menu Bar is a dynamic element that includes the following menus:
Galaxy, Edit, View, Object, Window, and Help. Depending on what object or Main Window
element is in focus, what condition it is in, or whether certain functions are logically permitted,
some menu commands may be deactivated. The following is a description of menu commands.
Galaxy menu - Providing Galaxy or user-level global commands, the Galaxy menu includes the
following:
New - For creating a new Instance, Derived Template, or Template Toolset

Open - For opening the editor of the object in focus. The editor appears in the Object
Editor Client Area of the Main Window.
Open Read-only - For opening the editor of the object in focus, but only in read-only
mode. There are several conditions that can place this restriction CN 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.
Wondeware System Platform 3.0 Course Part 1
1-43
1-44
e
e
e
e
e
Close - For terminating the object edit session in focus. This command is available only if
the editor for one or more objects is open. If the object has been modified, you are
prompted to save the new data to the Galaxy Repository. The same validation scenario
applies as described in the Save menu command.
Import- For importing Automation Objects, Script Function Library, and Galaxy Loads.
Export - For exporting Automation Objects, All Automation Objects, Script Function
Libraries, and a Galaxy Dump.
Save- For saving the currently-opened object's configuration, which is persisted to the
Galaxy Repository. This command is available only if the editor for at least one object is
open and configuration data has been modified in at least one of them. Validation occurs
on the editor level; if errors or warnings are identified during validation, they are displayed
in a message box and the user is given the choice to continue saving or cancel the save.
Save All - For saving ALL the currently-opened object's configuration, which is persisted
to the Galaxy Repository. This command is available only if the editor for at least one
object is open and configuration data has been modified in at least one of them. Validation
occurs on the editor level; if errors or warnings are identified during validation, they are
displayed in a message box and the user is given the choice to continue saving or cancel
the save.
Configure - For configuring Security, the Time Master, or to Customize Toolsets.
Galaxy Status - For viewing information relating to the Galaxy such as the total number
of instances, total number of templates and other related Galaxy information.
Properties - For viewing the properties of the object in focus.
Change Galaxy - For selecting a Galaxy repository that is different from the one to which
you are currently connected, this command opens the Select Galaxy dialog box.
Change User- For changing the logged in user of this ArchestrA IDE, this command
opens the ArchestrA IDE Login dialog box.
Edit menu - providing edit capabilities, the Edit menu includes the following commands:
e
e
Rename - For renaming the object in focus.

Rename Contained Name - For renaming the contained name of the object in focus.
Delete - For deleting the object in focus.
Find - For locating specific items of information based on a variety of configurable search
criteria.
User Information - For viewing the Prompts, Initial Scan State, Scan State Defaults, and
User Defaults.
Wondeware Training
Section 3 -The ArchestrA
IDE
View menu - similar to a standard Microsoft View menu, this menu provides commands for
controlling the Main Window display. On your initial ArchestrA IDE login, all four Main Window
components listed below are visible (checked) and the client language is set to the one chosen
during installation. Subsequent logins by the same user implement the previously saved ArchestrA
IDE settings. This menu includes the following commands:
Model - For bringing focus to the Model view of the Main Window.
Deployment - For bringing focus to the Deployment view of the Main Window.
Derivation - For bringing focus to the Derivation view of the Main Window.
Template Toolbox - For bringing focus to the Template Toolbox of the Main Window.
Graphic Toolbox - For bringing focus to the Graphic Toolbox of the Main Window.
Operations - For displaying the progress and results of a set of Galaxy database
operations that can be done at the same time as other application-building operations.
Synchronize Views - For specifying that a selected object stay selected as you move
through the views.
Reset Layout - For resetting everything back to its original default locations.
Toolbars - For toggling onloff the Toolbar of the Main Window.
Status Bar - For toggling onloff the Status Bar of the Main Window.
Wondenvare Syslem Platform 3.0 Course - Parf 1
1-45
1-46
Objects menu - the Objects menu includes the following commands:
Check-Out - For checking out an object from the Galaxy Repository so that you can
maintain sole authority to configure that object. Nobody else connected to the Galaxy can
affect the configuration of the object until you have checked it back in to the Galaxy.
Check-In - For checking in to the Galaxy Repository an object which was previously
checked out. This command opens the Check-In Object dialog box.
Undo Check-Out - For reversing a previous check-out without affecting the configuration
of the object in question. The result of this command is the object can be checked out by
anyone connected to the Galaxy.
Override Check Out- Use this command to disable the checked out flag on the selected
object. This command typically requires special security permissions and should be used
only in those circumstances in which it is certain that object configuration is not being done
by the user who originally checked out the object. If the object's editor is currently open,
the override function fails.
Validate - For checking allowable attribute value ranges, compiling its scripts, updating
and binding its references, validating its extensions, updating its status, and validating
other configuration parameters that may be unique to the object.
Note: See "Validating Objects" on page 1-49 for additional information regarding this feature.
e
e
e
e
View i n Object Viewer- For allowing the evaluation of attributes and conditions when the
objects are deployed. It provides a visual display of the actions being executed.
Deploy - For deploying the object or objects currently in focus to the nodes their
configurations denote, this command opens the Deploy Object dialog box.
Undeploy - For undeploying the object or objects currently in focus from the nodes that
currently host them, this command opens the Undeploy Object dialog box.
Assign To - For assigning objects to a different plafform.
Unassign - For unassigning objects to a different platform.
Set As Default - For setting a System Object, such as WinPlatform or AppEngine, as the
default for assigning appropriate objects.
Wonderware Training
Upload Runtime Changes - For uploading a deployed object's configuration to the

Galaxy Repository. This function is useful when changes to certain attributes
(Writeable-UC. Writeable-UC-Lockable, Writeable-USC. Writeable-USC-Lockable) are
made in the configuration environment, but at a later time, the runtime object's
configuration is determined to be preferred. Select the desired object and click Upload.
The runtime configuration overwrites the configuration environment data In the Galaxy
Repository.
Window menu - For manipulating the Object Editor Client Area of the Main Window, this menu is
available if at least one object's editor is open. This menu includes the following commands:
Cascade - Standard Windows command for cascading (layering) multiple object editors.
Tile Horizontally - Standard Windows command for displaying the editors horizontally.
Tile Vertically - Standard Windows command for displaying the editors vertically.
Close All - For closing all open object editors. If any data was changed on any editor, you
are prompted to save those changes individually for each editor.
Windows - For selecting through a separate dialog box which editors to activate or how
they are to be displayed.
Help menu- similar to a standard MS Help menu, the ArchestrA IDE Help menu includes the
following commands:
Help Topics -Standard Help command, used for opening the ArchestrA IDE's HTML
Help documentation system.
Object Help - Provides information about the object in focus.
About ArchestrA IDE - Opens the About ArchestrA IDE dialog box which provides
software version and copyright information.
Operations Pane
The Operations pane displays the progress and results of a set of Galaxy database operations
that can be done at the same time as other application-building operations. Currently, validating
the configuration of objects is the only operation that uses this pane.
Important! Validation can be done on both templates and instances, but only on those that are
chedied in.
Wonderware System Platform 3.0 Course -Par/ f
1-47
1-48
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 scriot libraries and uodates their status to Good.
To display the Operations pane, either
e
Right-click on an object (multi-select is allowed) and click Validate on the shortcut menu.
Click Operations on the View menu.
The following pane is then displayed in the Main Window.
&
BAppEnslne
$Area
$AnalogDevce
$DDESuteLmkCbent
Good
Good
&
~l
ood
Good
Succeeded
Succeeded
succeeded
Succeeded
- Object s a Bare Template

- Object s a Base Template
- Object ir a Bare Template
- Object is a Base Template
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 ErrorsiWarnings 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 CtrlcC). The Operations pane, like the Template
Toolbox and Applications Views, is also updated as the status and conditions of objects in the
Galaxy change.
Wondeware Training

Validating Objects
Each object in a Galaxy has a set of possible configurations that authorizes its proper use in an
application. That set of configuration possibilities is validated by the object either while you are
configuring it or when you save that configuration to the Galaxy database.
Validation of an object's configuration includes checking allowable attribute value ranges,
compiling its scripts, updating and binding its references, validating its extensions, updating its
status, and validating other configuration parameters that may be unique to the object.
Typically, each option on an object's editor that requires a string or numeric input has an allowable
range of inputs. If you type an input outside the allowable range and then attempt to change editor
page, close the editor or save the object's configuration, a message is displayed about the input
error indicating the allowable range.
Some configuration settings are dependent on associations with external components, such as
script function libraries and relative references to other objects' attributes. The status of these
external components can change, perhaps rendering some capability of the object inoperative
For instance, an object may referto 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 ooerations 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.
..Wonderware Syslem Platform 3.0 Course - Parl 1
1-49
1-50
Toolbar
The ArchestrA IDE Toolbar consists of icons for quick access to frequently used commands. It is
shown below, and each icon, from left to right, is described afterwards. The description titles
associated with each below are based on the tool tip that appears when you hover over each
Toolbar icon.
Change Galaxy - For selecting a Galaxy repository that is different from the one to
which you are currently connected, this command opens the Select Galaxy dialog box.
*,.-z
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).
O ~ en For o~eninathe editor of the obiect in focus. The editor appears in the Object
Editor d~ientArea o i 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.
h g d Check-In - For checking in to the Galaxy Repository an object which was previously
checked out. This command ;pens 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 tf?; object in focus.
Wondeware Training
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 fmm the nodes that
currently host them, this command opens the Undeploy Object dialog box.
bd
Delete - For deleting the object in focus
%,ssa
3 Customize Toolsets - For maintaining the toolset categories displayed in the Template
Toolbox, this command opens the Customize Toolsets dialog box.
User lnformation - For configuring global user preferences for the ArchestrA IDE
Using this command opens the Configure User lnformation dialog box.
Galaxy Status - For accessing the status of the current Galaxy.
Model View - For displaying the Model view in the Main Window.
""-2 Deployment View - For displaying the Deployment view in the Main Window.
bxs-i
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.
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.
Wonderware System Platform 3.0 Course - Parf 1
1-51
1-52
When you first log in, the default toolset with default object templates is opened. Once a user has
logged in to the Galaxy Repositoly, 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.
Section 3 - The ArchestrA
IDE
Application Views
The Application Views pane displays the galaxy configuration based on how an object is related to
other objects:
e
Model View - This defines the Object relationship to the automation scheme layout. The
Objects are organized into Areas to represent the physical plant layout.
e
Deployment View - This view defines the Object instance relationship to the PC that the
Object code is running on.
Derivation View - This view displays what the derivation path is from Base Template to
Instance. All templates and instances are displayed in this view.
The Model view is the default display when the ArchestrA IDE is first launched. 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:
4
ass~gnedArea
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, DevicelntegrationObjects,.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.
Wondeware Syslem Plafform 3.0 Course Part 1
1-53
1-54
Deployment View
Note: More detail of the Deployment View is discussed in Module 2. Section 2, "The Deployment
Model", page 2-11.
The deployment view is used to display the assignment of the automation scheme to physical
machines and process engines. This view describes where the objects are running. This view
does not represent your physical plant environment.
An example of a Deployment view is as follows:
This diagram represents the tree view that is displayed within the deployment view. This
represents the topology view based on which PC and Engines the objects run on. The diagram is
read left to right and top to bottom, so a Platform can host an AppEngine. Also, an AppEngine can
host an Area.
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Host" root of the tree.
To assign an object to another, drag-and-drop it onto the host object. An inappropriate assignment
match is not allowed. Conversely, to unassign an object, drag-and-drop it to the Unassigned
folder.
Derivation View
The Derivation view presents objects and templates in terms of their genealogy relationships. The
derivation view is the only tree view that shows both templates and instances. The purpose of this
view is to display to the user from which templates and derived templates an instance inherits its
properties.
Wondeware Training

An example of a Derivation view is as follows:
. ..
; :..-..@ AnalogDavice-001
6.. @
. $AppEngine
.
.
:---.. AppEngine-001
.
.
&
. $Area
.
:--.@ Area-OOi
El 8 $DiscreteDevice
El.. O BFieldReference
6..
. @
. $Winplatform
; '..-.%Winplatform-001
El- 0 Unused Base Templates
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.
match is not allowed. Conversely, to unassign an object, drag-and-drop it to the Unassigned

folder.
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.
Wondeware System Plalform 3.0 Course -Pad 1
1-55
1-56
An example of a Graphic Toolbox is as follows:
g.aAnalog Meters
@ &3~uttons
@ rnclock
&
acompressors
Counters
El.
DiqitalMeters
E l BDisplays
Fans
@-
BISA
Symbols
Lights 8.Indicators
a--&3 Panels
&- 0 Pipes
+.-&3
Pumps
Sliders
Switches
9.
Q val%/es
h...
Vessels
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:
Wondeware Training

Three Types of Status Indicators
There are three kinds of indicators that accompany object icons:
e
deployment status (for instances only)
configuration status (for templates and instances)

redundancy status (for instances only).
Deployment status indicators include:
DESuiteLinkClient-001 in example above)
AppEngine-001 in example above)

I
Deployed w~thsoftware update requlred (see

W~nPlatform-001in example above)
1-57
1-58
Configuration status indicators include:
F.
. .
.Description
.. . -
. . .
. . .
... .
1-
.. --..
Configuratlon warning
I (no indicator) / Configuration good

Redundancy status indicators include:
Description
AppEnglne undeployed. 11sredundant palr
deployed
AppEngine
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:
! Description
-m
Icon
Appltes to InTouchV~ewAppdeployment when

files are bemg transferred
Wondeware Trarnrng

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 IDESconnect 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 u n r e s e ~ e d
objects
a.
Select them in the Template Toolbox or Application Views
b. On the Object menu, click Check Out
Or, right-click on the object and select Check Out. Optionally, an object is automatically
checked out to you when you open its configuration editor. If the object is already checked out,
you can open its editor only in read-only mode.
To determine an object's status and history, open the Properties dialog box.
Woodeware System Platform 3.0Course -Pad 1
1-59
1-60
WinPlatform_OOl
WinPlatform_OOl
WinPlatFoim_OOl
WinPlatform_OOl
Defaultuser
Defaultuser
Defaultuser
DefaultUser
Updated configuration.
Updated configuration.
Checkin by user.
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 t o the Galaxy database

a.
Select it and, on the Object menu, click Check In
Or, right-click on the object and select Check In. The Check I n 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):
Wonderware Training
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 I n dialog box enables you to provide comments about configuration changes made
while the object was checked out. It is comprised of the following options:
e
Comment: Use this box to enter your comments about configuration changes made to the
object.
Don't Prompt for Check-In Comments in the Future: Use this check box to turn off the
comment feature when checking in objects in the future. If you decide to reinstate this
feature, click User lnformation on the Edit menu and select Ask for Check In
Comments in the Configure User lnformation dialog box.
Undo Checkout, Override Check O u t

Two other ArchestrA IDE commands related to the conceDt of check out and check in include:
Undo Check Out: Use this command to change an object's status from checked out to
checked in. Afterwards, any user can check out and configure the object. The check ouV
check in function places a notation in the object's change log. Use Undo Check Out to
effectively check in the object without affecting the change log. Changes you made to the
object when it was checked out are backed out. This command is not allowed when the
object's configuration editor is open.
Override Check Out: Use this command to disable the checked out flag on the selected
object. This command typically requires special permission, and should be used only in
those circumstances in which it is certain that object configuration is not being done by the
user who originally checked out the object. If the object's editor is currently open, the
override function fails.
Wonderware System Platform 3.0 Course Pad 1
1-61
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 110 servers and other
platforms.
Wondenvare Training

Section Objectives
Introduce the various objects in the ArchestrA IDE.
Identify when an0 how they are used.
Explain how to create and configure instances of objects.
lntroduce 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
Within the Template Toolbox there are three main categories of objects. These are:
0
Application objects
AnalogDevice
Boolean
DiscreteDevice
Double
FieldReference
n
Float
Integer
Sequencer
String
Switch
UserDefined
Device Integration objects

DDESuiteLinkClient
InTouchProxy
OPCClient
RedundantDlObject
System objects
AppEngine
Area
InTouchViewApp
ViewEngine
Winplatform
1-64
Application Objects
@J Application
;..... @ $AnalogDevice
;-----@ $Boolean
;----. g $DiscreteDevice
;--.-- g $Double
;-----@ $FieldReference
;----. @ $Float
;---. Q $Integer
;---- Q $Sequencer
;----. 8 $String
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 lnput (with optional Output) or as an AnalogRegulator that
provides an external representation of a PID controller that exists elsewhere (typically a PLC or
DCS).
The AnalogDevice can be configured to have a personality of one of the two basic types:
Analog - a basic Analog lnput or Analog Output
e
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:
e
Supports optional scaling of input and output, both linear and square root conversions.
e
Supports HiHi, Hi, Lo, and LoLo level alarms on PV with both value and time
deadbanding.
e
Supports Rate of Change (ROC) alarming on PV for both positive-slope and negativeslope ROC.
PV Override - when true, allows the PV to be written by a user if the PV mode is set to
Manual.
Adds SP read and write capability with'optional separate read-back address. For data
integrity, the value of SP always represents the value read from the external controller, not
the requested SP that is output to the external controller.
Wondenvare Training

e
*
e
Supports minor and major deviation alarming when PV deviates from SP.
Initial Control Mode - When in Cascade, the SP can only be written by other objects.
When in Manual, a user can write the SP. When None, anything can write to it.
Control Tracking - optional capability to read a Boolean control track flag from an external
device or object. When tracking is on, the SP is pure read-only and cannot be changed.
Boolean Object
The Boolean object is derived from the FieldReference object and is used for evaluations that
result in either of the truth values of 'true' of 'false', often coded 1 and 0 respectively.
DiscreteDevice Object
A Discrete Device is a general purpose Object that is used to represent a large class of physical
equipment common in manufacturing such as pumps, valves, motors, and conveyors. These
devices have two or more physical states (e.g. Open, Closed, Moving), and are optionally
controlled using a combination of discrete outputs. Their actual state is monitored via a
combination of discrete inputs.
The meaning of the states depends on the kind of Discrete Device. In the case of a pump, the
states might be configured as "Of? 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 " P V (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 " B a d 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:
lnput and Output states of the DiscreteDevice object are totally independent of each other
and can be configured as required by the user's application.
lnput 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.
e
Supports devices with two to three commandable states ('Passive', 'Activel', 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.
e
Supports the three input modes 'Auto', 'Manual', and 'Simulate'.
Supports the two control modes 'Manual' and 'Cascade'.
CtrlTrack allows a PLC to notify the Discrete Device that the PLC is in control of the state
e
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).
.-
1-65
1-66
D o u b l e Object
The Double object is derived from the FieldReference object.
FieldReference Object
The FieldReference object is the generic object for accessing data from an external device. This
object can act as both the field input and a field output.
The FieldReference Object can be configured into three basic access modes:
e
ReadOnly - Input object
e
Readwrite - Output object with scanned Feedback
e
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.
lnteger 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 Wondeware Application Server application.
You can use it to automate:
0
repetitive manufacturing procedures with a finite number of steps
r 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.comltraining or call 1-866-WW-TRAIN (1-866-998-7246) or email
Wondeware Training at training@wonderware.com.
String Object
The String object is derived from the FieldReference object.
S w i t c h Object
~he'switchobject is the object for accessing data from a simple discrete (011) device. This object
can act as both a discrete input and a discrete output.
Wondeware Training

The Switch Object can be configured into three basic access modes:
e
ReadOnly - Input object
Readwrite - Output object with scanned Feedback
e
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:
e
As a "container" for other objects. An object relationship in which one object is comprised
of other objects is called containment. Containment allows you to group various objects
together to make complex objects. For detailed information on object containment, see the
Integrated Development Environment (IDE) documentation.
To use the UserDefined object as a container object, you simply create an instance of the object,
and add ApplicationObjects to it while in the Model View. The only indication of this containment
structure is in the tree structure in the Template Toolbox or Model View. The UserDefined object
editor does not provide any indication of this containment relationship. To edit the configuration of
any contained objects, you must open the individual editors of those objects.
Note: A UserDefined object can only contain ApplicationObjects

e
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 ( I n l e t )
--V102 ( O u t l e t )
--LT103 ( L e v e l )
The Tank object derived from the UserDefined object can be customized to raise an alarm when
both the lnlet 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:
i f r n e . i n l e t == "Open" a n d m e . o u t l e t == "Open" t h e n
me.statealarrn
else
rne.statea1a.m
endif;
true;
false;
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.
Wondeware System Platform 3.0 Course - Pad 1
1-68
Device lntegration Objects
@Device Integration
i... @j $DDESuiteLinkClient
1- $InTouchProxy
j... $OPCClient
L.%
TBRedundantDIObiect
A Devicelntegration object (DlObjects) is an Automationobject that represents communication
with external devices. DlObjects run on an AppEngine, and include DlNetwork Objects and
DlDevice Objects. A DlDevice Object is a representation of an actual external device (for example,
a PLC or RTU) that is associated with a DlNetwork Object. A DlNetwork Object is a representation
of a physical connection to a DlDevice Object via the Data Access Sewer.
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
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:
e
hosting application objects, device integration objects and areas
containing the logic to setup and initialize objects, when they're deployed.
e
containing the logic to remove objects from the engine, when they're undeployed.
e
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.
Wonderware Training

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 alarmlevent clients to monitor their areas of
responsibility.
This object is very simple; it only allows the value of three attributes to be historized:
e
Active alarm counter
e
Unacknowledged alarm counter
e
Disabled (or silenced) alarm counter
InTouchViewApp Object
The InTouchViewApp object represents an lnTouch application in the Industrial Application server
environment. The InTouchVewApp object manages the check-in, check-out, and deployment of an
InTouch application.
When you create an InTouchViewApp for a new lnTouch 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.
WinPlatforrn Object
The WinPlatform platform object is a key base object. The key functionality of this object includes:
e
Calculating various statistics related to the node it's deployed to. These statistics are
published in attributes.
e
Monitoring various statistics related to the node it's deployed to. These monitored
attributes can be alarmed as well has historized.
e
Starting and stopping engines, based on the engines startup type, which are deployed to
it.
Monitoring the running state of engines deployed to it. If the platform detects an engine
has failed it can (optionally based on the value of the engine's restart attribute) restart the
engine.
There is a special instance of the platform object called the galaxy platform. This platform
instance:
Exists on the galaxy node.
e
Is used by message exchange to bind unresolved attribute references
1-69
1-70
Hosting and Containment Relationships

Host relationships are displayed in Deployment View.
Galaxy
Platform (representative of your Plant)
Engine
Area
Application Objects
Dl Objects
Containment relationships are displayed in Model View.
Areas
Areas
Application Objects
Application Objects
Wondeware Training
Templates and lnstances

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, 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 Sewer comes with predefined templates, called base templates. You
cannot change these templates. All templates you create are derived from base templates.
You can also nest templates, or contain them. Contained templates consist of nested object
templates that represent complex devices consisting of smaller, simpler devices, including valves
A reactor is a good candidate for containment.
Templates only exist in the development environment.
Using the Diaphragm valve template, you can quickly create an Diaphragm valve instance when
you need another Diaphragm valve in your application.
Templates
/Emt
Template
Each template inherits

attributes
from theone above it
Child Instances
Each object instance

inherits attributes
from its template
lnstances
lnstances are the run-time objects treat$ from templates in Wonderware Application Sewer.
lnstances are the specific things in your environment like processes, valves, conveyer belts.
Wondeware Syslem Plafform 3.0 Course -Pail 1
1-71
holding tanks, and sensors. lnstances can get information from sensors on the real-world device
or from application logic in Wonderware Application Sewer. lnstances 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
tem~latescome in.
Creating and Deleting lnstances

Applicationobject instances are created from the templates provided by the Template Toolbox.
A default name is given to the new instance. The newly created Object instance is put into focus
and set to rename mode.
This view also allows the Object instance to be edited.
Object instances can be deleted from this view if the Object does not have any other Objects
assigned to it.
By default the first instance of the Platform object will be configured with the name of the Galaxy
Repository node name. This platform can then be renamed.
There are two ways to create an instance of a template. This is indicated as follows:
Creating an Instance - 1
Drag and drop the template object from the Template Toolbox to the Application View. To delete
an instance of the Platform object highlight it and click on the Delete icon in the menu icon bar
,:,.,."n
j($,<]
;-.,.-,.,or, right-click on it and select Delete.
Wondenvare Tmining
the Model View.
@.
m
. D e v i c e Integration
!. m$DDESuiteLinkClient
.i . @$InTouchProuy
;. .. D$OPCClient
i..
~
Once the instance has been created it displays as follows:
It can now be renamed using the naming convention as designated by your instructor.
Wondeware Sysfem Plafform 3.0 Course Pad 1
1-73
1-74
Creating a n Instance 2
Highlight the object in the Template Toolbox for which you desire an instance. Then from the
Galaxy menu, select GalaxylNewllnstance or use the short cut which is Ctrl+N.
Component Names
ArchestrA AutomationObject Toolkit This is the toolkit for developing core ApplicationObjects,
in a C++ environment, which will be imported into the Galaxy via the IDE.
Area AutomationObject - the AutomationObject that represents an Area of a plant within an
Application Server Galaxy. The area object acts as an alarm concentrator and is used to put other
AutomationObjects into the context of the actual physical automation layout.
ApplicationEngine (AppEngine) - a real-time Engine that hosts and executes
AutomationObjects.
Applicationobject - An AutomationObject that represents Some element of a user application.
This may include things such as (but not limited to) an automation process component (e.g.
thermocouple, pump, motor, valve, reactor, tank, etc.) or associated application component (e.g.
function block, PID loop, Sequential Function Chart, Ladder Logic program, batch phase, SPC
data sheet, etc.).
AutomationObject - A type of object that represents permanent things 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 monitorthe
represented component.
.-
Wondeware Training

ContainedName -This is the final portion of the HierarchicalName that defines the name of the
object within that containment level, i.e. HierarchicalName = Linel .Tankl.InletValve, TagName =
V l l O l ContainedName = Inletvalve
Device Integration Objects (DlObject) - AutomationObjects that represent the communication
with external devices, which all run on the application engine local. The objects for example are:
DlNetwork Object - Refers to the object that represents the network interface port to the
device via the Data Access Server, providing diagnostics, and configuration for that
specific card.
DlDevice Object - Refers to the object that represents the actual external device (e.g.
PLC, RTU) which is associated to the DlNetwork Object. Providing the ability to diagnose,
browse data registers, and DAGroups for that device.
Framework - An infrastructure consisting of a common set of services, components and
interfaces for creating and deploying Automation objects that collect, store, visualize, control,
track, report and analyze plant floor processes and information.
Galaxy - complete Application Server system consisting of a single logical name space (defined
by the Galaxy Repository) and a collection of Platforms, Engines and Objects that are included
within it. One or more networked PC's that constitute an automation system. It defines the name
space that all components and objects live in and comply with a common set of system level
policies. This is the whole application.
GalaxyDatabase - the relational database containing all persistent configuration information for
all Templates and Objects in an Application Server Galaxy.
GalaxyRepository - the soflware sub-system consisting of the Galaxy Repository Engine,
Package Server, Repository Interface, and the Galaxy Database.
HierarchicalName - This is the name that is created by the system that positions the object within
any containment i.e. HierarchicalName = Linel.Tankl.InletValve, TagName = V1101
Integrated Development Environment (IDE) -The IDE is an lntegrated Development
Environment consisting of various configuration editors that are used to configure the total system,
aimed for the application engineer, and general use.
Objects - AutomationObjects (all types), Automationobject, Userprofiles, Displays, Symbols,
Displaysets, ActivityObjects are collectively referred to as Objects. Common characteristic of all
Objects is that they are stored as separate components in the GalaxyRepository.
e
ObjectTemplate - a specific state of an Object in which the Object is a generic template
from which instances can be generated.
Objectlnstance - a specific state of an Object in when the Object has been substantiated
to the actual unique instance of the object that will run in the system.
PlatForm Object- a representation of the physical hardware that the Application Server soflware
is running on. Platform Objects host AppEngine Objects (see WinPlatform).
QuickScript .NET - this is the name of the scripting language component that is an enhanced
version of InTouch QuickScript with new language features and integration with Microsoft@.NET.
System Management Console (SMC) - This is the central runtime system administration I
management user interface, where all required runtime administration functions like new users,
redeployment, license management will occur.
TagName - This is the Galaxy-wide unique name given to a Object.
i.e. HierarchicalName = Linel .Tankl.InletValve, TagName = V1101
Wondeware System Platform 3.0Course - Parf I
1-75
1-76
Module I
- Introduction
WinPlatform - a single computer in an Application Server galaxy consisting of Network Message

Exchange, a set of basic services, the operating system and the physical hardware; hosts
Application Server Engines and is a type of Platform Object.
Product Names
ArchestrAObject Toolkit - a programmer's tool used to create new Application and Device
Integration Object Templates, including their configuration and run-time implementations along
with their corresponding ID editors.
Wonderware Application Server - This is the product name given to the Wonderware A2
Application Server, which will run the objects as a blind node, allowing a product to be loaded on
top of existing systems to extend value. This product has an execution engine (AppEngine) which
hosts the application objects performing the functionality, and then stores this into a history
storage system, which is also included in the product.
DAServer Toolkit - This is the toolkit for building Data Access Servers, which are the next
generation of 110 servers, and are 110 server executable. These are OPC servers, and this toolkit
is to be a product which enables Wonderware and third parties to develop powerful OPC servers
which can connect to third party clients and Application Server clients.
Data Access Server (DAServer) - Refers to the Sewer executable that interfaces to the device
serving data to the DlNetwork Object and DlDevice Object, via standard client protocols OPC, or
to any third party client. These replace our current 110 Servers.
Components of a DAS Toolkit:
e
Client Plug-ins: These are the components which are added to a DAS server to enable
communication with clients. Examples are: OPC 2.03, DDEISuitelink, etc.
DAS Engine: This is the .DLL which contains all the common logic to drive data access
(this used to be called "Core toolkit").
Device Protocol: This is custom code set up by the user to define the communication
with a particular device.
DAS Control Client: This is the MMC snap-in supplied with the DAServer that provides
the necessary UI for activation and configuration.
DAS Diagnostic: This is part of the DAS Control Client MMC snap-in-that provides a
set of diagnostic information for DAServers within the system
DAS Configuration: This is part of the DAS Control Client MMC snap-in which
enables configuration of the DAServer either locally or remotely.
rn
DAS Activation: This is part of the DAS Control Client MMC snap-in which enables
the user to start and stop the DAServer.
DAS AppWizard: This is the C++ Wizard that generates the framework of the DAServer
Generic State Engines: These are engines which enable the device protocol developer
to build the particular functions:
rn
Device Engine
m
Serial Engine
TCPllP Engine
Section 5 - System Requirements, Licensing and Support

Section Objectives
Describe the necessary system requirements for a successful installation
Discuss Licensing requirements
Discuss Support services
This section provides a detailed explanation of the system requirements necessary for System
Platform, discusses Licensing details and covers Support services.
System Requirements for Wonderware Application ServerlGalaxy

Repository
Note: There is an Online Seminar available for the Installation of Wonderware Application
Server 3.0. To register, visit www.wonderware.comltraining or call 1-866-WW-TRAIN (1-866998-7246) or email Wonderware Training at traininq@wonderware.com.
Hardware Requirements
The following list shows the recommended hardware requirements to install Application Server
version 3.0.
Galaxy Repository Platform:
e
Dual core PC with 2 gigahertz (GHz) or faster processor clock speed, or single core PC
with 3 gigahertz (GHz) or faster processor clock speed
Dual core processor recommended for optimal performance
2 gigabytes (GB) or more of RAM. (1 GB minimum supported; may limit performance of
some features) The Galaxy Repository locks the SQL Server maximum memory usage to
65% of the physical memory.
Non-Galaxy Repository Platforms (IDE or Runtime):
e
PC with 2 gigahertz (GHz) or faster processor clock speed
e
1 gigabyte (GB) or more of RAM
All Systems (IDE, GR, Runtime):
e
30 gigabytes (GB) of available hard disk space
Super VGA (1024 x 768) or higher resolution video adapter and monitor
e
CD-ROM or DVD drive

Keyboard
Mouse or compatible pointing device
The Windows Vista operating system imposes hardware requirements that may exceed the
minimum requirements for Application Server version 3.0. If you intend to run Application Server
3.0 with Windows Vista, see the following Microsoft web site for hardware requirements:
1-77
1-78
Software Requirements
This section describes the operating system and other software requirements to install Application
Server version 3.0.
Operating System
The following table lists the supported operating systems that can be installed on computers
runnina server. client. and run-time comDonents.
I
Operating Systems
Windows Vista Business (See Vista Restrictions)
Windows Vista Enterprise (See Vista Restrictions)
Windows Vista Ultimate (See Vista Restrictions)
Windows Server 2003 Standard Edition SP2
Windows Server 2003 Enterprise Edition SP2
Windows Sewer 2003 Standard Edition R2 SP2
Windows Server 2003 Enterprise Edition R2 SP2
Windows XP Professional SP2
Windows XP Tablet 2005
Aoolication
Sewer Comoonents
.
Galaxy
ArchestrARun
ArchestrA IDE
Repositoly
Time
0
0
0
0
&3
13
I3
63
I3
0
&3
l
3
Notes:
Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server
are not supported operating systems for Application Server version 3.0. If you attempt to
install or upgrade Application Server on a computer running one of these operating
systems, an error message appears.
Windows Server 2003 Standard Edition SP2 is the recommended operating system to run
server components.
Windows XP Professional SP2 is the recommended operating system to run client

components.
If you plan to run Application Server version 3.0 on computers running Windows Vista, all
editions except for Home Basic and Home Premium are supported. The Business Edition
is recommended.
Windows XP Professional SP2 and Windows Vista may be used on a Galaxy Repository
Node for only single-node solutions.
The Bootstrap, IDE, and Galaxy Repository are supported on the following language versions of
Microsoft operating systems: English, Japanese, Chinese, German, and French. The Galaxy
Repository is also supported in English, Japanese, Chinese, German, and French versions of
Microsoft SQL Server 2005.
Wonderware Training

Other Software Requirements
The following list describes other third-party software requirements to support Application Server
version 3.0.
e
Microsoft SQL Server 2005

n
SQL Server 2005 with SP2 (Standard or Enterprise) is the only database supported
by Application Server version 3.0. The Compact, Express, and Workgroup editions of
SQL Server 2005 are not supported for the Galaxy Repository.
The SQL Server 2005 SP2 database must be installed on the same computer as the
ArchestrA Galaxy Repository.
TCPIIP must be enabled on the computer running SQL Server. The TCPIIP protocol
setting can be verified from the SQL Server 2005 Network Configuration under SQL
Server Configuration Manager.
Microsoft Visual Studio 2005 (toolkits only)
.NET Framework Common Language Runtime (CLR) 2.0.50727
Note: The Microsoft SQL Server login for BUILTIN\Administrators group must be present and
enabled.
Note: Application Server 3.0 requires installing Microsoft SQL Server 2005. You cannot use
Microsoft SQL Server 2000 with this version. You also cannot install and use Application Server on
a computer that has both Microsoft SQL Server 2000 and Microsoft SQL Server 2005 installed.
Vista Restrictions
Application Server version 3.0 can run under Windows Vista Enterprise, Windows Vista
Business, or Windows Vista Ultimate. The Windows Vista Home Basic and Home
Premium editions are not supported.
Users must log on as a Windows Vista administrator to run Application Server version 3.0.
You cannot run Application Server as a Windows Vista standard user or power user.
You can run Wonderware 32-bit software only with a 32-bit version of Windows Vista.
Running Wonderware 32-bit software with a 64-bit version of Windows Vista on 64-bit
hardware is not supported
The Windows Vista User Account Control (UAC) must be disabled when running
Application Server. Refer to Microsoft Windows Vista documentation for instructions to
disable UAC.
When you disable Windows Vista UAC, you must restart the computer before attempting
to install the ArchestrA IDE or Wondeware Application Server. A Galaxy connection error
occurs if you attempt to install the ArchestrA IDE or Wondeware Application Server and
you did not restart the computer after you disabled the UAC.
Windows Vista does not support a traditional Application Server 3.0 single-node
configuration that includes Wondeware Historian (formerly IndustrialSQL Server).
A Vista Platform cannot be configured to be an alarm provider and also have InTouch
Windowviewer on the same computer configured to generate alarms. Only one of the two
will function properly as an alarm provider.
Windows Vista does not support NetDDE. ArchestrA graphics make use of the client layer
when accessing InTouch tags, and appear as a third-party client trying to access
Wondeware System Platform 3.0 Course -Pail 1
1-79
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.
Application Server 3.0 cannot be configured to run as a service under Windows Vista.
Windows Vista security prevents started Windows services from interacting with desktop
objects. When Application Server 3.0 is installed on a computer running Vista, scripts do
not run correctly if they include the InTouch ActivateAppO and SendKeysO functions.
These functions interact with desktop objects by starting Windows programs and sending
keystrokes to these programs.
The Galaxy Repository is only supported on Vista for single-node systems. For multiplenode Galaxies, Windows Server 2003 is the preferred operating system for the Galaxy
Repository node.
Using Multiple Network Interface Cards with Vista

If you are using multiple network interface cards (NICs), you must configure certain settings forthe
firewall or else a remote Vista node cannot connect to a 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 boot, 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".
e
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.
e
The Public profile is designed to keep the computer from being visible to other computers
on the network. Network discovery is turned off for the Public profile.
The Private profile is used for a more trusted environment. Network discovery is turned on
for a Private profile. Firewall exceptions and rules can be created on any or all of these
profiles.
This is important because the OS Configuration utility and the Vista Firewall utility apply their
firewall exceptions to the Domain and Private profiles only.
As previously noted, you can specify which profile you want assigned to a connection as long as
that connection is not a Domain connection. This is done through the "Network and Sharing
Center". Click on the Network icon in the right-hand side of the task bar and then click on one of
the networks that is displayed. 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 re-boot of your computer, or even a re-boot of a
computer to which you are connected, can change your connection back to the Public profile.
Wonderware Training
;.

Once again the firewall exceptions will not be effective. You'll have to change the connection back
to the Private profile after each re-boot or a re-boot 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 NlCs follow the actions below:

e
If the second NIC is not physically connected to anything (that means no wire in it), no
action is required. The profiles and firewall rules are automatic.
If the second NIC is connected, it MUST be configured. Follow the rules for
configuring a normal redundancy setup, Vista will identify this NIC and assign it a
Private profile. If the NIC is not configured, Vista will assign a profile of pubic to this
NIC and cause all of our firewall exceptions to be deactivated on all NICs. Forthe NIC
to be configured properly, give it an IP address, sub net mask and gateway address.
The gateway address can be the same as the IP address. Usually these addresses
will be the internal, non-routable addresses like 192.168.0.x or the 10.x.x.x range.
If you have more than two NICs, make sure all connected NlCs are configured with an
IP address and default gateway address and have been assigned a profile of Private.
Wonderware System Platform 3.0Course -Part 1
1-81
1-82
Licensing
-.
.......
......
-. .
. . .
. . -
I?
Description
...... ... - . . . -.
.
~ n i s ; e z t o me lora Appl callon Moue thal rcstdes in a Galaxy repository
Galaxy
Term
Platform Count
/ Number of PCs in the Galaxy (note each InTouch needs a platform to be part /
NJmber of 110 ponls

oeing
accessed
:nlo tne
Ga axy
110C..o~nl
. . . . .
.
.
.
. -.
.
......
Inlegraled Devc opmenl Environment (the ed tlng envlronmenl for Applcat on
ArcnesrrA IDE
Sewer). Only available as part of the ArchestrA Development License.
Access to the Galaxy Repository is controlled by a license. If a license-related message is

displayed when you are attempting to open the IDE, you have a problem with your license. This
message may indicate one of the following conditions:
e
No license has been installed
Your license has expired.
You may have exceeded the licensed 110 count or number of WinPlatforms
Use the License Utility to correct these problems. Until the problem is resolved, you cannot:
e
Open the ArchestrA IDE.
e
Connect to existing Galaxies.
e
Create new Galaxies.
Afler you have updated your license, you should be able to connect to your Galaxy and open the
ArchestrA IDE with no further problems.
Note: If a license expires while you are using the ArchestrA IDE, you are not allowed to connect to
the Galaxv the next time vou ooen the ArchestrA IDE.
To check your current license, expiration date (if any) and limitations (if any), double-click the
License icon at the bottom of the ArchestrA IDE's Main Window
For more information on licensing requirements, please contact your local distributor.
--
Wondeware Tramnmg

Product Support
Product Support
Wonderware provides responsive, award-winning teams of specialists committed to delivering
world-class customer support, training, and consulting selvices. For information on the various
customer support programs, contact your local distributor or access the Wonderware Technicai
Support site online at http:llwww.wonderware.comlsupport/mmil
You will find a variety of information on the Technical Support site including the Expert Knowledge
Base, 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 Suppod Policies, Terms & Conditions guide
which provides information on how to contact Technical Support, information on the support
policies and procedures, and much more.
Wondeware System Platform 3.0Course -Pad 1
1-83
1-84
Module 1 - introduction
- Intentionally left blank -
Wondeware Training

Section Objectives
Explain a project workflow and area devices and wny they are needed
Identify functional requirements and naming conventions
Expand on the concept of ArchestrA and how it relates to the manufacturing
environment.
Explain the b e n e h of migrating to an ArchestrA architectdral 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 Wondeware A2 environment, you should start
with careful planning to come up with a working model of your plant or plant area. A six-step
project workflow is provided that describes how to complete different tasks in a logical and
consistent order, so that you minimize the engineering effort.
The project information that you define will become your guide when actually creating your
industrial application using the ArchestrA IDE. The better your project plan, the less time it will take
to create the application, and with fewer mistakes and rework.
Suggested Project Workflow

Just as there are many different criteria for 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
Wondewwe System Platform 3.0 Course -Part 1
1-85
1-86
1 ldentifv Field Devices and Functional ~ e q u i r e m e n t s j

Define Naming Conventions
Define the Area Model
Plan Templates
Define the Security Model
Define the Deployment Model

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.
rr
F~eldDevice
.-.
.
.
. - . ...
Valves
. ..-
7
5
1 Attribute Name
t
- -....- ..
*
Data Type
.- ...
..
. - . ...
2
G
f
Default
Description
..
Value
Default
Min Max Securily
(D
Inputs Q)
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
Wanderware Training

up of more base-level devices. For example, a motor is a device that may be part of an agitator or
a pump.
After you have identified all of your field devices, you will then need to determine the functionality
for each.
Identifying Field Devices

When identifying field devices, you should start with your piping and instrumentation diagram
(P&ID). Typically, this diagram shows all of the field devices and illustrates the flow between them.
if you have a good P&ID, the application planning process will take less time and go more
smoothly. You should verify that your P&ID is correct and up-to-date before starting the planning
process.
The following diagram shows a simple P&ID:
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.
Wonderware Sysfem Plafform 3.0 Course - Paii 1
1-87
1-88
Once you have created the complete list, group the devices according to type, such as valves,
pumps, and so on. Consolidate any duplicate devices into common types so that only a list of
unique basic devices remains, and then document them in your project planning worksheet.
Each basic device is represented in the ArchestrA IDE framework as an "object." An instance of an
object must be derived from a defined template. The number of device types in your final list will
help you to determine how many object templates you will need to create for your application. You
can group multiple basic objects to create more complex objects, which is a concept known as
"containment."
Identifying Functional Requirements

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

The second step in the workflow is to define the naming conventions for templates, instances, and
object attributes. Naming conventions should adhere to:
Conventions that you use within your company.
0
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:
Wondeware Training

HMls
ArchestrA
YY123XV456\OLS
.CLS
Individual Tags
Object
mformat~onrefer
to the InTouch to
IAS Migration
document
Object
Attributes
For ArchestrA IDE, references are created using this naming convention:
<objectnarne>.cattributename>
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 Dispatch Area. You will need to define and document all of the Areas of your
plant that will be part of your application.
Each object will need to be assigned to a particular Area. When you install 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:
e
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.
e
It is helpful to create a System Area to which you can assign instances of WinPlatform and
AppEngine objects. WinPlatform and AppEngine objects are used to support
communications for the application, and do not necessarily need to belong to a plantrelated Area or any Area for that matter.
e
Alarms will be grouped according to Areas.
Areas can be nested.
When building an Area hierarchy, keep in mind that the base Area that is assigned to a Platform
determines how the underlying objects will be deployed. If a plant area (physical location) is going
to contain two computers running Automationobject Server platforms, then two logical Areas will
have to be created for the one physical plant area.
One approach for creating instances of an object is to create an instance for one Area at a time. If
you use this approach, then mark the Area as the default, so that each instance is automatically
1-89
assigned to the selected Area. Before you begin to create instances in another Area, change the
default to the new Area.
A final consideration for constructing Areas is that the various Areas equate to alarm groups. It is
at the Area level that alarm displays can easily be filtered.
Object Templates
A template is an element that contains common configuration parameters for objects that are used
multiple times within a project. Templates are instantiated to represent specific objects within the
application.
For example, you might need multiple instances of a valve within your application, so you would
create a valve template that has all of the required properties. This allows you to define once, and
reuse multiple times. If you change the template, the changes can be propagated to the instances.
You can use simple drag-and-drop within the ArchestrA ID 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-7.
The next three steps (Planning Templates, Defining the Security Model, and Defining the
Deployment Model) are done once the initial Plant Model is in place. These are represented
through subsequent Modules in this training course. Please refer to additional information which is
available in the Wondeware A2 Deployment Guide.
Wondenvare Training
Lab 2 - ldentifying the Mixer

Introduction
In this lab you will study
This lab provides the three detailed diagrams used to identify the factory layout for the simulated
scenario; as well as the main pieces of equipment that you are going to model and develop during
this training course.
The diagrams provided in this lab will be used as reference in following exercises and are listed
below:
Factory Layout
0
Heat Exchanger: Process Diagram & Field 110 Signals

Mixer: Process Diagram & Field I10 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 helpyou familiarize yourself with the work that is going to be made in the rest of the
labs for the class.
Objectives
Understand the information that needs to be collected before proceeding to develop a
Galaxy
Feel familiar with the naming convention and device structure to be used in this class
Summary Lab Instructions

Following is a summary of the general steps you will complete for this lab
Note: For this lab there are no additional detailed instructions.
Identify the Sample Application
1. Study and discuss the following diagrams with your instructor
2. Create the IDSfor the heat exchangers and mixers assigned to you
Wondeware System Platform 3.0Course -Part 1
1-92
Wondemare Training
*+
Heat Exchanger: Process Diagram 8r Field 110 Signals
Student Number (XX):
Heat Exchanger 1 ID (XYO):
Heat Exchanger 2 ID (XXI):
Signal
Equipment
Hm-TCl
TCI: Temperature Transmitter

TCZ: Tewerature Transmitter
TC3: Temperature Transmitter
TC4: T%n?peratureTransmitter
--
----
I
I
uo
l 1
Type
Float
--
Flat
RAW: 0 - 4095
EU: 0 250
Float
RAW: 0 - 4095
EU:0 - 250
Flat
RAW 0 4095
/I
EU: 0 250
I
I
Celsius
Celsius
1i
Celsius
Temperature for the Hot Wsier Our.
/ Temperature for the Cold Pfcduct,

Temperature for the WorwFmdud.
I
1
j
!
i
1-94
Wondeware Training
Lab 2 - identifying the Mixer
Wonderware System Platform 3.0 Course - Part I
1-95
1-96
- intentionally lee blank -
Wondeware Training
Application Infrastructure
Section 1 - The Plant Model
Lab 3 - Creating the Plant Model
- The Deployment Model

Lab 4 - Creating and Deploying the Deployment Model
Section 2
Section 3 - The Runtime Environment

Section 4 - Connecting to the Field
2-2
Module 2 -Application Infrastructure

Module Objective
Explain the concept and describe the need of developing a Plant Model before
configuring the Wonderware Application Server
Identify key factors necessary for building successful appl~cations.
Explain Galaxies and introduce you to the Integrated Development Environment (IDE)
Explain Plant Modeling as it relates to Objects and Object Instances
Wondeware Training
Section 1 -The Plant Model
Section 1 -The Plant Model

Section Objectives
Explain the importance of having a model of the plant facility.
Examine the concept of how to utilize ArchestrA Application Server to model a specific
fac'lity.
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 Sewer to model a
specific facility.
Modeling of the Facility

With the ArchestrA Application Sewer it is possible to create a working model of the plant
manufacturing environment which will utilize the product. Having this model will enable you to
implement a structured naming convention that will facilitate the coordination of all the processes
and areas. It will also provide the ability to create objects representing your actual plant, configure
them to your own specifications and create templates from them which will enable you to
propagate one area to another.
The ArchestrA plant application model allows you to organize a distributed computing application
by:
Plant
+Section + Area
+ Production
Line
Manufacturing
Cell
Once a plant application model has been developed, applications can be easily extended or
replicated based on the structure you have provided. With this Facility Model you can:
Rapidly create application standards.
e
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.
.-
Wonderware System Plafform 3.0 Course Part 1
2-3
2-4

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
Device Integrationobjects
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
Lab 3 - Creating the
lant 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. An additional $Area instance is created to
accommodate future system objects created throughout the rest of this class.
To help organize the templates, a custom toolset is created to hold the templates created in the
class.
Objectives
Create new template toolsets
e
Create derived templates
Create instances
Use the $Area object to create a plant model for the Galaxy
Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.(e.g., if
the user is Ann Brown, Valve would be ABValve) This will eliminate problems when deploying
your objects in a common galaxy later in the course.

instructions, please refer to the Detailed Lab lnstructions on subsequent pages.
Create a-Template Toolset
1. Create a new Template Toolset named AB Training under the Galaxy.
Create the Plant Model

2. Create a derived template from the $Area object named $ABArea and assign it to the AB
Training template toolset.
3. Create the following instances out of the new $ABArea template:

AB Discharge
0
ABlntake
e
ABProduction
r ABLinel
s ABLine2
e
ABControlSystem
4. Arrange the new $Area instances to model the factory layout defined in Lab 2.
See the next page for Detailed Lab Instructions
2-5
Detailed Lab Instructions

Following are Detailed Lab Instructions for completing this lab. For a summafy of instructions,
please refer to the Summary Lab Instructions on the previous page@).
Create a Template Toolset

1.
In the ArchestrA IDE, make sure that the Template Toolbox is selected
2.
In the Template Toolbox, right-click on the Galaxy and select New Template Toolset
Wonderware Training

3. A new template toolset is created. Use AB Training for the name.
Create the Plant Model

4.
In the Template Toolbox, create a derived template of the $Area object by right-clicking the
$Area template and selecting New I Derived Template.
Wonderware System Plafform 3.0 Course -Pa!+ 1
2-7
2-8

5. A new template is created. Use $ABArea for the name.
6. Move the $ABArea object to the newly created template toolset.
i i g l e m p l a t e Toolbox
-
Wonderware Tram~ng
- 9 . X
-

7. Ensure that the Model view is selected
8. Create a new instance of the 5ABArea template by drag-and-dropping the $ABArea object
from the Template Toolbox to the Model view.
Name the new instance ABDischarge.
&3 SDiroeteDevire
Device integration
2-9
2-10
9.
Repeat step 8 to create the following areas:

e
ABlntake
ABProduction
ABLinel
ABLine2
ABControlSystem
:
:. ...a' Model
..
-.
--
.. . -
. - - - . ... .
V V .
X-
!.---a
BJ
UnassignedArea
;...
/..... @ ABDischarge
j...- @ ABIntakr
i - 9ABLinel
;--9ABLine2
'-----9ABProduction
10. Drag-and-drop the newly created objects to assign areas ABLinel and ABLine2 to the
ABProduction area. The final plant model should look like the following illustration.
"-
j--- 9ABDischarge
: 9ABIntake
b '$ ABProdlrction
;..--9ABLinel [ ABLinel]
i...
9ABLineZ [ ABLine2 ]
Wondeware Training
Section 2 - The Deployment Model
Section 2 - The Deployment Model
Section Objectives
Explain the concept of the Deployment Model.
Demonstrate the structure and organizational execution of the Deployment Model.
This section provides an explanation of the Deployment Model and demonstrates the structure of
the Deployment Model.
Deploying the Galaxy

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

Deploying your Galaxy copies the objects from the development environment to the run-time
environment. This makes your objects~"live"and functional.
Until you deploy your ArchestrA IDE configuration environment to the run-time environment,
changes you make in the ArchestrA IDE do not appear in the run-time environment. To see runtime data associated with yourobjects, use Object Viewer or InTouch.
Objects deploy from the configuration environment to the run-time environment as follows:
...
Wondeware System Platform 3.0 Course -Par/ I
2-11
2-12

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.
Deploying Objects
You deploy object instances for three reasons:
e
Testing.
Place the application into production to process field data
Update an existing application with changes you made.
When you are ready to deploy, make sure the following conditions are met:
e
Bootstrap software is installed on the target computer(s).
The objects being deployed are not in an error state in the Galaxy database.
e
You created, configured, and checked in objects to the Galaxy.
Objects are assigned to a host.
The object's host is already deployed. A cascade deploy operation, which deploys a
hierarchy of objects, deploys all objects in the correct order:.This deploys an object's host
before the object is deployed.
Wanderware Training

To 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

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.
e
Include Redundant Partner: Select this check box to also deploy an AppEnginers
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.
e
Skip: If one of the objects you are deploying is currently deployed, selecting Skip makes
no changes to the already-deployed object.
e
Deploy Changes: If one of the objects you are deploying is currently deployed, this option
updates the object in question with new configuration data.
e.
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.
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.
In the Currently undeployed objects area, select the Deploy New Objects check box to
start a normal deployment.
Wondeware System Platform 3.0 Course - Par/ 1
2-13
2-14

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:

e
On Scan: Sets the initial scan state to on scan for the object@)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."
p~
Note: Objects can only execute when both the hosffengine is "on scan" and the object is "on
scan." If either the hosffengine 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.
e
Off Scan: Sets the initial scan state to off scan forthe 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 hosffengine. 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 dialoa box.
h. Click OK to deploy the object@).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.
To redeploy
a.
On the Object menu, click Deploy.
b. Follow the procedure for Deploying Objects.
Wondeware Training

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.
To undeploy
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.
e
Cascade Undeploy: Select to undeploy the selected object as well as any objects it
hosts.
e
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.
e
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.
On Failure Mark as Undeployed: Marks the object as undeployed in the Galaxy when
the object targeted for undeployment is not found
2-15
2-16
- Intentionally leff
Wondenvare Training
blank -
Lab 4 - Creating and eploying the

eployment 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 start by organizing the system objects using the
plant model created in the previous lab, and then, after creating the deployment model, the
complete Galaxy is sent to the runtime environment by deploying all objects.
Objectives
e
Use the $Winplatform, $AppEngine and $Area objects to create a deployment model for
the Galaxy
Deploy instances to the runtime environment
2-17
2-18

Following is a summay of the general steps you will complete for this lab. For detailed
Create the $WinPlatform Object

1. Create a derived template from the $WinPlatform object named $ABPlatforrn and assign it to
the A B Training template toolset.
2. Create an instance of the $ABPlatform template named ABGRPlatForm and assign it to the
ABControlSystern area.
Create the $AppEngine Object

3.
Create a derived template from the $AppEngine object named $ABAppEngine and assign it
to the A B Training template toolset.
4. Create an instance of the $ABAppEngine template named ABAppEngine and assign it to the
ABControlSystern area.
Create the Deployment Model

5. Using the Deployment view, host the ABAppEngine object on the ABGRPlatForrn object and
all areas on the ABAppEngine object.
Deploy the Objects

6.
Deploy the ABGRPlalform on cascade

please refer to the Summary Lab lnstructions on the previous page(s).
Create the $WinPlatform Object

In the Template Toolbox, create a derived template of the $WinPlalform object by rightclicking the $Winplatform template and selecting New IDerived Template.
A new template is created. Use $ABPlatform for the name.
Move the $ABPlatform object to your template toolset.
2-19
2-20

4.
Using the Template Toolbox and the Model view, create a new instance of the $ABPlatform
template.
Name the new instance ABGRPlatform.
+- @
ABIntake
6.StJ ABProduction
i . @ ABLind [ ABLinel ]
ABLinEZ [ ABLineZ]
5. In the Model view, assign the ABGRPlatform instance to the ABControlSystem area
i -t., Model
.
.............
;..... @ ABIntake
6 9ABProduction
9 ABLinel [ ABLinel]
9ABLine2 [ ABLineZ]
Wonderware Tmining

Create the $AppEngine Object
6. In the Template Toolbox, create a derived template of the $AppEngine object by rightclicking the $AppEngine template and selecting New I Derived Template.
7. A new template is created. Use $ABAppEngine for the name.
8.
Move the $ABAppEngine object to your template toolset.
Wondewwe System Plafform 3.0 Course -Pad ?
2-21
2-22

9. Using the Template Toolbox and the Model view, create a new instance of the
$ABAppEngine template.
Name the new instance ABAppEngine
/..... Stj
Q
ABIntake
@ ABProduction
Stj ABLinel [ABLinel]

' . % ABLineZ [ABLine2]
10. In the Model view, assign the ABAppEngine instance to the ABControlSystem area.
6-$j ABProduction
Stj
Wondeware Training
ABLinrl [ ABLinel]
ABLine2 [ ABLine2 I
Lab 4 -Creating and Deploying the Deployment Model

Create the Deployment Model
11. Select t h e Deployment view.
12. Assign t h e ABAppEngine instance t o the ABGRPlatform.
n...
.-
ABGalax)
a,.
Unassigned Host
. a
.
;..
. @ ABControlSysterr
;..-.
/....@ ABIntake
.
.
.
..
.-
;. -9 ABDischarge
.
..
9 ABLinel [ ABLinel ]
9 ABLine2 [ ABLine21
:....-a
ABProduciion
Wondewere System Platform 3.0Course -Part 1
2-23
2-24

13. Assign all areas to the ABAppEngine instance.
ABGalaky
6 Unassigned Host
E l@
AEGRPlatforrn
l
i(
,:"
-
Deploy the Objects

14. On the Deployment view, right-click the ABGRPlatforrn instance and select Deploy
Wondeware Training

15. The Deploy dialog box is displayed. 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.
16. Leave the default settings andclick the OK button. This will d i s, ~ l .
a va second Deploy dialog
box indicating the progress onbeploying the objects.
As soon as the process is complete, the Close button is enabled.
Deploycomplete
Valldabng GRNodeInfu...
0
1
Chedong wheiher oblecis being deployed requlre software upgrade...
Sorbno and Valldabno 8 obiectM starbno from ABGRPlafform hosted bv ~lafformABGR!
Wondenvare System Platform 3.0 Course Pari 1
2-25
2-26

17. Click the Close button to return to the ArchestrA IDE.
The different views now display the instances in their deployed state.
"-
i--.-6% ABIntake
;----6% ABLinel [ ABLind ]

i..---& ABLine2 [ ABLine21
I. & ABProduction
Wonderware Trarnrng
"-
;----&% ABIntake
6 -& ABProduction
i... & ABLinel [ ABLinel]
& ABLine2 [ABLine2]
Section 3 - The Runtime Environment
..
Section Objectives
Explain the concept of the Runtime Environment.
lllustrate the differences in the Development environment and the Runtime environment.
Explain the use of the Object Viewer in monitoring the Runtime environment.
This section provides an explanation of the Runtime environment and explains the use of the
Object Viewer in monitoring the Runtime environment.
Runtime Environment
The previous workflow task defined the deployment model that specifies where objects are
deployed. In other words, the deployment model defines which nodes will host the various
AutomationObjects.
The objects deployed on particular platforms and engines define the objects' "load" on the
platform. The load is based on the number of 110 points, the number of user-defined attributes
(UDAs), etc. 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 Sewer 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 Sewer requires information about all of the variables being created. As
object and object attribute values change (e.g. 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, 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 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.
.-
Wondenvare Syslem Platform 3.0 Course - Pad 1
2-27
2-28

Deployed Objects section
Objects deployed on the Platform.
COiW
C?
co;-
C*
PI
Individual attributes of the obiect.
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 rnylnteger. 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 mylnteger of 31. If you redeploy
this object, the original value of 30 overwrites any value assigned during run time. To avoid losing
changes made during run time, upload changes before redeploying an object.
Wondeware Training

If you want to upload run-time changes to the Galaxy, make sure the selected objects are:
0
Not edited and checked in since last deployment or upload
e
e
Not in Pending Update state

Checked in
Objects whose configuration are successfully uploaded have a new version number and a change
log entry for the upload operation. The run-time object's version number also has a new version
number. That version number matches the version in the configuration database.
If you select an object that is currently checked out to you, a warning appears during run-time
upload. If you continue, you lose all configuration changes you made to the checked out object.
The Galaxy performs an Undo Check Out operation on it before the run-time attributes are copied
to the Galaxy database.
Note: You cannot upload run-time changes for obiects checked out to other users
To upload run-time changes to the Galaxy
Select one or more objects in the Model view or Deployment view. For example, you could
select an entire hierarchy from AppEngine down.
On the Object menu, click Upload Runtime Changes. The run-time attributes of the selected
objects are copied over those in the Galaxy database.
Wondewwe System Platform 3.0 Course - Pad1
2-29
2-30
- lnfenfionally left blank -
Wondeware Training

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 3then saved in a single file for future reference.
Objectives
e
Open Object Viewer from the ArchestrA IDE
Add attributes to watch windows to get a live feed
.
e
Create and rename watch windows within Object Viewer

Save watch windows to disk
your obiects in a common galaxy later in the course.

Using O b j e c t v i e w e r
1. Open Object Viewer from within the ArchestrA IDE.
2. Rename the default watch window to Platform lnfo and add the following attribute references:
e
ABGRPlatforrn.CPULoad
ABGRPlatforrn.DiskSpaceFree[l]
ABGRPlatform.RAMAvai1ableAvg
3. Create a new watch window called Engine lnfo and add the following attribute references:
e
ABAppEngine.Scheduler.ScanPeriod
e
ABAppEngineScanState
ABAppEngineScanStateCmd
4. Save the watch list to you training folder (C:\Wonderware Training) with the name My Watch
Windows.
Wanderware System Platform 3.0 Course - Parl1
2-31

Following are Detailed Lab lnstructions for completing this lab. For a summay of instructions,
please refer to the Summary Lab Instructions on the previous page($.
Using Objectviewer
1. In the Model view, open Object Viewer by right-clicking the ABGRPlatlorm instance and
selecting View in Object Viewer.
Wonderware Training

2. The Object Viewer application opens displaying the attributes of the selected object on the
right panel.
Deployed Objects section
Objects deployed on the Platform.
Attribute Monitoring section Location

for monitoring attribute activity.
3.
Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the default Watch List Itab
Modify.,.
Remove horn Waiiii
Add Atblbuti? Reference..
Add Watch Window
Wondemare Syslem Platform 3.0 Course -Pad 1
2-33
2-34
Module 2 - Application infrastructure

4. The Rename Tab dialog box is displayed. Enter Platform lnfo for the Tab Name field and
click OK.
5. The tab is now labeled Platform lnfo
Wondeware Training

6. On the Attribute List (right section of Object Viewer) locate and right-click on the CPULoad
attribute and select Add t o Watch to add the attribute to the watch list.
ABGiilaxy
EnaMe
Enable
false
false
C0:Good
CO:Good
CO:Good
CO:Gaod
CO:Good
CO:Good
GR.TimeORastCon%Chanse
$26/20074:35
...
CO:Good
Ok
Ok
Ok
Ok
Ok
Ok
Ok
operate
Readmly
ReadOnly
Readhly
Readhlly
Readmy
ReadOnly
operate
opwate
Readonly
Resdmly
Readmly
Readonly
ReadOniy
Readonly
ReadOnly
Readonly
ReadOnly
Tune
ReadOnlv
~ead0nl;
Writes
...
Cdda...
writes...
S y r t m...
system...
systan...
CaloAa...
Wntea ...
Writea ...
CidoAa...
Writea.. .
sy* tan...
Writea...
Writea. ..
System...
System...
Calcula. ..
Cdcula...
!wtea...
Cdcula. ..
Cdmla...
UnL&d
CustomEnum
CustomEnum
Boolean
Boolean
inteaer
RefeienreType
Integer
Integer
Boolean
lime
Time
Wandenvare Syslern Platform 3.0 Course - Pad 1
2-35
2-36

7. Repeat step 6 for the following attributes:
e
e
8.
DiskSpaceFree (enter 1 as the array index to access drive C:)

RAMAvailableAvg
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.
Remove ton? Watch

Add Atbibute Reference.
Rename Tab..
Open..
Save
Save As...
Wondeware Trammg
..

9.
Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the default Watch List I tab.
...
Modify
Remove +on Watch
Add Atinbute Reference..

Add Watch \Vindow
Remove \Vat& Window
...
Open
save
Save As..
10. The Rename Tab dialog box displays.
Enter Engine Info for the Tab Name field and click OK.
-OK-_I
Cancel
Wondeware System Platform 3.0 Course - Pail f
2-37
2-38

11. On the Object List (left section of Object Viewer) select the ABAppEngine object to display
its attributes.
Wondenvare Training

12. On the Attribute List (right section of Object Viewer) locate the following attributes, right-click
on them, and select A d d to Watch to add them to the watch list:
e
SchedulerScanPeriod
Scanstate
e
ScanStateCmd
13. Right-click in the Watch List (bottom section of Object Viewer) and select Save As to save
the watch list to disk.
Remove fi-om Wairi?
Add Awibute Reference
...
Add Watch \nlindow

Remove Watch \hiindow
RenameTab
...
Open..
2-39
2-40

14. The Save As dialog box displays
Navigate to the C:\Wonderware Training folder and enter My Watch Windows in the File
name field.
Click Save to save the watch list to the selected location.
----
Wonderware Tmmmg
Section 4 - Connecting t o the Field
..
Section Objectives
Be famdiar w;th Device lntegration Objects, 110 Server and Data Access Server
Overview of Dl Objects.
This section ~rovidesan understanding

.of the Device Integration Obiects, 110 Server and DA
Server. It also provides an overview of Dl Objects.
Introduction
'Dynamic Data Exchange (DDE)
Dvnamic Data Exchanae
- ,1DDE) is a communication Drotocl31 developedi by Microsoft to allow
athications
in the Windows enhronment to sendlreckve data and instrt~ctionstolfrom each other.
,
It implements a client-server relationship between two concurrently running applications.
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 Microsofl Excel can simultaneously be both a client and a server.
Note: NetDDE, an older protocol used for communication over the network to Wonderware and
non-Wonderware sources, is supported on Windows XP and Windows 2000, but not on Windows
2003 Server. Communication with Wonderware sources is recommended using SuiteLink.
Wondeware System Plafform 3.0 Course -Pad ?
2-41
2-42

Wonderware S u i t e L i n k
Wonderware SuiteLink uses a TCPIIP-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:
e
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.
e
Value Time Quality (VTQ) places a time stamp and quality indicator on all data values
delivered to VTQ-aware clients.
Extensive diagnostics of the data throughput, server loading, computer resource
consumption, and network transport are made accessible through the Microsoft Windows
N p operating system performance monitor. This feature is critical for the scheme and
maintenance of distributed industrial networks.
e
The network transport protocol is TCPllP using Microsoft's standard Winsock interface.
To use the SuiteLink Communication Protocol, the following conditions must be satisfied.
e
You must have Microsoft TCPllP configured and working properly,
e
You must use computer names (Node Names) of no more than 15 characters
For more information on installing and configuring Microsoft TCPIIP, see your
Microsoft Windows operating system's documentation.
e
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 a n d SuiteLink 110 A d d r e s s i n g

DDE and SuiteLink identifies an element of data in an 110 data source program by using a threepart 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 I10 data source program or service is running on
Application: Name of the source program or service that provides I10 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 tolfrom which the data is to be readlwritten.
--
Wondenvare Tramng

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 COMIDCOM
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 HMls) 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.
Wondeware System Platform 3.0Course -Part 1
2-43
2-44

Device Integration Objects
Device Integration
.....
$GPCCiient
'..... W BRedundantDIGbiect
A Devicelntegration object (DlObjects) is an Automationobject that represents communication
with external devices. DlObjects run on an AppEngine, and include DlNetwork Objects and
DlDevice Objects. A DlDevice Object is a representation of an actual external device (for example,
a PLC or RTU) that is associated with a DlNetwork Object. A DlNetwork Object is a representation
of a physical connection to a DlDevice Object via the Data Access Sewer.
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 110 Server. A DDE or SuiteLink I10 Sewer can provide data points to
Galaxy application objects through the DDESuiteLinkClient object.
Note: The DDESuiteLinkClient object is compatible with ail Wonderware 110 Sewers and
components.
There is a one-to-one relationship between an instance of the DDESuiteLinkClient object and a
running 110 Sewer. If you want to reference data points in more than one I10 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 ABTCP 110 Server and another
one to talk to the GEHCS I10 Server.
When you configure the DDESuiteLinkClientobject, you can specify one or more I10 Sewer topics
to which access is required. At run time, ail items that the Galaxy application requires for a
specified topic are updated with the latest values from the I10 Server. The rate at which the values
are updated depends on how the topics were configured within the target 110 Server.
If you want to connect to a DDE I10 Sewer, specify login information that the DDESuiteLinkClient
object uses to connect to the 110 Sewer.
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 110 Sewer 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 userdefined attribute name (alias). Creating the item list is not required in order to reference data from
the 110 Server.
The reference syntax for a DDESuiteLinkClient object data point is:
<objectnarne>.<topicname>.<itemname>
OR
<objectname>.<topicname>.<attributename>
The <objectname> is the name that you choose to give to the DDESuiteLinkCiient object.
Wondenvare Training

Each 110 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 lnTouchTMapplication. 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 Devicelntegration 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 obiect is com~atiblewith InTouch v7.11 and later a ~ ~ l i c a t i o n s
There is a one-to-one relationship between an instance of the InTouchProxy object and a running
InTouch node. An InTouch "node" is a unique combination of the computer name and InTouch
application. If you want to reference data points in more than one InTouch node, you must
configure and deploy more than one InTouchProxy object. For example, you would need to
configure one InTouchProxy object to get data from an InTouch application running on Computer1
and another one to get data from an InTouch application running on Computer2.
When you configure the InTouchProxy object, you might want to specify one or more existing
InTouch tagnames (items) to use as object attributes. At run time, if these attributes are added in
the client (for example, the Object Viewer watch window), they are updated with the latest values
from the InTouch items. InTouch sends a new data value for an item to the InTouchProxy object
each time the value changes. Any items that you configure for an InTouchProxy object
automatically becomes available within the ArchestrA Attribute Browser.
From other objects and from scripts, you can reference the attributes you created for InTouch
items. For example, you might configure the input source for a FieldReference object to reference
one of these InTouchProxy object attributes. Thus, the FieldReference object's input source would
be receiving data from a tag in an InTouch node through the InTouchProxy object. The reference
syntax for an InTouchProxy object data point is:
<objectname>.<InTouchTagName>
The <objectname> is the name that you choose to give to the InTouchProxy object
The group of specified InTouch items for an InTouchProxy object is also known as the "scan
group." Only one scan group exists in the InTouchProxy object. Run-time object attributes within
the scan group allow you to monitor errors related to the data quality for InTouch item values in a
scan group.
2-45
2-46

OPCClient
The OPCClient object is a key member of the core set of AutomationObjects within the ArchestrA
system infrastructure. The OPCClient object is a Devicelntegration (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 ABTCP OPC Server and another one to talk to the
ABClP OPC Server.
An OPCClient object supports the following operations on 110 points for the OPC DA Server:
Subscriptions, which are implemented via scan groups. Read transactions, which are
implemented via block reads.
e
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.
RedundantDlObject
The RedundantDlObject provides you with the ability to configure a single object with connections
to two different data sources (proxy objects or DlDevice 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 RedundantDlObject is a Devicelntegration 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
RedundantDlObject automatically switches to the other source object for continued data
acquisition.
The way the RedundantDlObject determines that a data source is in Bad state by monitoring the
Connectionstatus attribute common to all DlObjects, the ProtocolFailureReasonCode attribute
that reflects a failure in communication by a DAS DlObject with a field device, and the Scanstate
attribute common to all ApplicationObjects. When those attributes are, respectively, Disconnected,
non-zero, or Offscan, the status of the corresponding data source object is changed and a
switchover attempt is made to the other data source.
There is a one-to-two relationship between an instance of a RedundantDlObject and a pair of
source Devicelntegration objects.
The RedundantDlObject supports the following operations on I10 points from field devices:
e
Subscriptions, which are implemented via scan groups. Read transactions, which are
implemented via block reads (when available in the source DlObject). Write transactions,
which are implemented via block writes (when available in the source DlObject).
Wonderware Training
Note: Most Applicationobjects in the ArchestrA environment write only the last data received in a
scan cycle. DevicelntegrationObjects, including the RedundantDlObject, operate differently. They
queue all data received in a scan cvcle and write them all in the order received.
The two source DlObjects 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 RedundantDlObject checks the state of its source DlObiects on every scan cvcle.
Note: During configuration, one DlObject is set as the Primary Dl source and the other is set as
Backup Dl 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 RedundantDlObject must be configured to have the
DAGroups that are common to both source DlObjects. When the connection fails to the Active
DlObject, all items are unsubscribed from the Active DlObject and new subscriptions are made to
the Standby DlObject. If either DlObject has unique DAGroups, it is important that the
RedundantDlObject should not be configured to use those uncommon DAGroups.
RedundantDlObjects belong to a family of objects called DlNetwork objects.
2-47

110 Server
Different 110 data sources have different requirements. Two main groups are identified:
o
Legacy 110 Sewer 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 Dl 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 Dl Objects
be installed on the same node as the data server(s) they communicate with, it is highly
recommended in order to optimize communication throughput.
For Device Integration objects like ABClP and ABTCP DlNetwork objects, both the
DAServer and the corresponding Dl Objects must reside on the same computer hosting
an AppEngine.
I10 Servers can run on Workstations, provided the requirements for visualization processing, data
processing, and 110 read-writes can be easily handled by the computer. Run the I10 Server and
the corresponding Dl Object on the same node where most or all of the object instances (that
obtain data from that Dl Object) are deployed.
This implementation expedites the data transfer between the two components (the I10 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
Wonderware Training

Data A c c e s s S e w e r (DA S e w e r )
DAServers, are designed to provide simultaneous connectivity between plant floor devices and
modern DDE, SuiteLinkTMandlor 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 Wondeware@SuiteLinkTM,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:
e
Compliance with OPC version 2.05
e
Stand-alone operation mode
e
Support for hot'configuration, device additions and device- and server-specific parameter
modifications
e
A wide range of DA
Servers support connectivity to numerous protocols and products. Wonderware's current DA
Servers offering also includes support for:
e
Allen-Bradley's CIP protocol for ControlLogix
Allen-Bradley's TCP protocol
Allen-Bradley's DH Plus protocol
e
Siemens' SirnaticTMNet 57
e
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.
2-49
2-50
Module 2
- Application Infrastructure
- Infentionally left blank -
Wonderware Training
Lab 6 - Connecting t o the Field
Lab 6 - Connecting to the

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 provides the behavior of a regular 10 Server or DA Server
connected to a real PLC.
Objectives
Upon completion of this lab you will be able to:
Create and configure a $DDESuiteLinkClient object to connect to an 10 Server or DA
Server using SuiteLink as the communication protocol
Monitor the connection status of the $DDESuiteLinkClient object on runtime
Note: FOR THlS LAB ONLY!!! This time you will NOT preface the object name with your FIRST
and LAST initial. Aaain, this is for THlS LAB ONLY!

Create t h e Device Integration object
1. Derived a new template from the $DDESuiteLinkClient object, name it

$ABDDESuiteLinkClient, and assign it to the A B Training template toolset.
2. Create an instance of the $ABDDESuiteLinkClient template and name it InControl.
3. Configure the General tab of the new instance as follows:

e
Sewer node: cask your instructor>
Sewer name: RTEngine
e
Communication protocol: SuiteLink
4.
On the Topic tab, add a topic called tagname and import the Incontrol Items List.csv file
from the C:\Wonderware Training folder.
5.
In the Model view, assign the Incontrol instance to the ABControlSystem area.
Deploy t h e Object
6. On the Deployment view, assign the Incontrol instance to the ABAppEngine object and
deploy the object.
Wondenvare Sysfem Plafform 3.0 Course - Pad 1
2-51
2-52

Verify t h e Connection o n Runtime
7. Open Object Viewer from within the ArchestrA IDE
8. Using the watch list created in Lab 5, create a new watch window called Incontrol and add
the following attribute references:
e
Connectionstatus
e
Reconnect
ServerNode
Se~erName
ComrnunicationProtocoI
e
ScanGroupList (enter 1 as the array index)
9.
Save the watch list
Wondenvare Training

Followlng are Detailed Lab lnstructions for completing this lab. For a summary of instructions,
please refer to the Summary Lab Instructions on the previous page($
Create the Device Integration object

1. In the Template Toolbox, create a derived template of the $DDESuiteLinkClient object by
right-clicking the $DDESuiteLinkClient template and selecting New I Derived Template.
2. A new template is created. Use $ABDDESuiteLinkClient for the name.
3. Move the $ABDDESuiteLinkClient object to your template toolset
Wondenvare System Platform 3.0 Course - Pal? 1
2-53
2-54

4.
Using the Template Toolbox and the Model view, create an instance of the
$ABDDESuiteLinkClient template. Name the new instance InControl. (Note that you will not
use your initials for this object)
Configure the Instance

5. Double-click on the Incontrol instance to open its configuration editor.
Server node:
Server name:
Priority:
Communication protocol:
.c--,.8 : K
8-4
,.
..........
E c i r a - h r v huser
!
Domain name:
Wondeware Training
6. On the General tab, configure the object as follows:
Sewer node: <ask your instructor>. The following screenshot uses 'MOE' as an
(+F"
+?I)cl
example.
Sewer name: RTEngine
Communication protocol: SuiteLink
7. Select the Topic tab
Wondeware System Platform 3.0 Course - Par1 1
2-56

8. At the Available topics section, click the Add button, type tagname as the Topic name and
press the Enter key.
9. With the topic tagname selected, click the Import button at the Associated attributes for
tagname section.
The Open dialog box is displayed. Navigate to the C:\Wonderware Training folder, select the
Incontrol Items List.csv file and press the Open button.
Wondeware Training

10. The content of the CSV file is loaded within the Incontrol object.
-11 Click the Save and Close button and check in the object.

12. The Check In dialog box appears. Enter Initial configuration and setup in the Comment
field and click the OK button.
13. In the Model view, assign the Incontrol instance to the ABControlSystem area.
...
i.
....
. & ABAppEngine
i
i&.-& ABIntake
&.- 63 ABProduction
;----& ABLinel [ ABLinel J

i..... & ABLine2 [ ABLineZ 1
Deploy the Object

14. Select the Deployment view.
6
. @Unassigned
.
i !.....@
B
Host
ABGRPlalform
6;.@ ABAppEngine
ABControlSystem
...
& ABDischarge
i . 6%
ABIntake
i;b ABUnel [ ABLinel]
j .
Wondenvare Training
& ABUne2 [ ABLineZ]

62 ABProduction

15. Assign t h e Incontrol instance to t h e ABAppEngine object.
. .
Lo Deployment
- .
,a
Unassigned
. .--
- P X
,A
Host
$.-@ ABGRPiatforrn
R- @ ABAppEnqine
;----$3ABControlSystm
i-.-. i;il ABDischarge
I...-.611 ABIntake
i--- ABLinel [ ABLinell
i - ABLine2 [ ABLineZ]
16. Right-click t h e Incontrol instance a n d select Deploy.
Wonderware Sysfem Plafform 3.0 Course -Pad ?
2-59

17. The Deploy dialog box is displayed. By default the system will set the instance On Scan as
soon as the object is deployed.
18. Leave the default settings and click the OK button.
This will display a second Deploy dialog box indicating the progress on deploying the object.
As soon as the process is complete, the Close button will be enabled.

19. Click the Close button to return to the ArchestrA IDE. The different views now display the
instance in its deployed state
aUnassignedHost
8 . @ ABGRPlatforrn
@-.- @ ABAppEngine
+ $3ABControlSystm
:r.i
..
:.
i.
;---.-63 ABDischarge
: 63 ABIntake
: & ABLinel [ ABLinel ]
@
...
.
I.--
& ABAppEngine
63 ABProducUon
'..... 63 ABLinel[ ABLinel]
'..... 6% ABLine2[ABLineZ]
Verify Connection on Runtime

20. In the Model view, open Object Viewer by right-clicking the Instance instance and selecting
View in Object Viewer.
Wondenware Syslem Plafform 3.0 Course Part 1
2-61
2-62

21. The Object Viewer application opens displaying in the right panel the attributes of the
selected object. If you closed Object Viewer before, you can use File 1 Load Watch List to
open the file you saved on the previous Lab.
22. Right-click in the Watch List (bottom section of Object Viewer) and select Add Watch
M0dfy..
Remuve kcm Waicii
Add Atirlbute Reference.,,
Rename Tab..
Open..
Save
Save As..
Wonderware Training
Lab 6 -Connecting to the Field

23. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to
rename the default Watch List 1 tab.
I
I
Add Ath-ibute Reference...
~ d watch
d
whdow
...
Open
Save As...
24. The Rename Tab dialog box is displayed. Enter Incontrol for the Tab Name field and click
OK.
25. On the Attribute List (lefl section of Object Viewer) locate the following
- attributes, right-click
on them, and select ~ d t odWatch to add them to the watch list:
e
ConnectionStatus
Reconnect
e
ServerName
ServerNode
CommunicationProtocoI
ScanGroupList (enter 1 as the array index)
I----
Atb b~teRefmnce
Value
0d1ty
1nControl.ConnecbonSt~tus
Connected
1nControl.Reconnect
InControlServerNarne
InControlServerNode
RTEngine
C13:Good
CO:Good
CO:Good
CO:Good
CO:Good
C0:Good
false
MOE
Suitelink
InControl.A~B~(SmnGroupList)[l] tagname
1nCon~ol.ComrnunicationProtocol
/ stab2
Ok
Ok
Ok
Ok
Ok
Ok
Wondeware System Platform 3.0 Course -Par/ 1
2-63

26. Right-click in the Watch List (bottom section of Object Viewer) and select Save to save the
watch list to disk.
..
Modi*.
Remove from \Vat&
Add Amibute Reference...

Add W a t h chhdow
Remove Watch Window
RenameTab...
Wonderware Training
Application Objects
Section 1 - Templates and Instances
Section 2
- The $UserDefined Object
- Change Control and Propagation

Section 4 - The $AnalogDevice Object
Section 3
Lab 9 - Meter
Section 5 - The $DiscreteDevice Object
- Valve, Pump and Motor

Lab 11 - Mixer
Lab 10
3-2
Wonderware Training
Module Objectives
Be able to
Identify and work w ~ t htemplates
Derive and configure templates
3-4
Wondeware Training
Section 1 -Templates and lnstances
Section 1 - Templates and lnstances

Section Objectives
This section:
Introduces you to the concept of templates and explain how to derive a template.
This section introduces you to the concept of templates and explain how to derive a template.
Templates
One of the major benefits of Application Server is that it allows you to re-use existing engineering.
Working with templates is the best way to illustrate such capability.
A template is an entity that represents the common functional requirements of a field device
(valves, pumps), a group of field devices (skids, stations), or a user function (algorithms). These
requirements reflect information such as number of Inputs and Outputs, alarm conditions, history
needs, and security. One object template performs the equivalent functions of multiple InTouch
tags and scripts.
A template is created either from a base template or from another derived template. Base
templates are the objects provided with the Application Server. Base templates cannot be
modified.
Note: You should avoid creating instances directly from base templates, since you will not be able
to take advantage of advanced configuration and maintenance capabilities.
Templates are high-level definitions of the devices in your environment. Templates are like a
cookie cutter from which you can make many identical cookies.
You define a template for an object, like a valve, one time and then use that template when you
need to define another instance of that item. Template names have a dollar sign ($)as the first
character of their name.
A template can specify application logic, alarms, security, and historical data for an object.
A template can also define an area of your environment. You can extend and customize a template
by adding User Defined Attributes (UDAs), scripts, or extensions to meet the specific needs of
your environment. Objects inherit attributes from their parents.
Wonderware Application Server comes with predefined templates, called base templates. You
cannot change these templates. All templates you create are derived from base templates.
You can also nest templates, or contain them. Contained templates consist of nested object
templates that represent complex devices consisting of smaller, simpler devices, including valves.
A reactor is a good candidate for containment.
Templates only exist in the development environment.
Using the Diaphragm valve template, you can quickly create an Diaphragm valve instance when
you need another Diaphragm valve in your application.
Wondewre System Plafform 3.0 Course - Pad 1
3-5
3-6

rern plates
/ParentTemplate
Each template inherits
I from the one above it
Child Instances
Each object instance
inherih attributes
from its template
lnstances
lnstances are the run-time objects created from templates in Wonderware Application Server.
lnstances are the specific things in your environment like processes, valves, conveyer belts.
holding tanks, and sensors. lnstances can get information from sensors on the real-world device
or from application logic in Wondeware Application Server. lnstances 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.
Wondeware Training
Section 1 -Templates and Instances

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.
Valve 001
Valve 002
Valve 003
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.
-Application
Objects
$AnalogDevice
$DiscreteDevice
SFieldReference
Base Templates
SUserDefined
$Valve -Derived
Template
For your project planning, document which existing template can be used for which objects, and
what templates you will need to create yourself.
A child template that you derive from a parent template can be highly customized. You can
implement user-defined attributes (UDAs), scripting, and alarm and history extensions.
Note: You can use the Galaxy Dump and Load Utility to create a .CSV file, which you can then
modify using a text editor and load back into the galaxy repository. This allows you to make bulk
edits to the confiauratlon auicklv and easilv.
3-7

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

To derive a Template from another one, do the following:
1. Select the Template in the ArchestrA IDE the new Template is to be derived from.
2.
Right-click the selected Template and click Derived Template on the Create submenu of the
context menu. The new Template is created, placed in the same toolset as the original
Template, and set in rename mode.
3.
Rename the derived Template
Note: The new Template is created in the Galaxy in a checked in state. It can be viewed in the
Template Toolbox or in the Derivation View of the Aoolication Views Dane.
Wonderware Training

Section Objectives
T h ~ ssection
Introduces you to the 5UserDefined object and its functlonal~ty.
This section introduces you to the $UserDefined object and its functionality
$UserDefined Object
The UserDefined object provides the basic functionality you need to develop an ArchestrA
supervisory application. The UserDefined object provides this functionality as Field Attributes,
scripts, User Defined Attributes (UDAs), and attribute extensions.
You can configure Field Attributes as an Analog or Discrete type with one of the following access
modes:
Input. The Field Attribute only accepts input. The Field Attribute is updated based on the
value that is read from the configured input address.
e
InputOutput. The Field Attribute accepts input and sends output. The output destination
can optionally differ from the input source address. The InputOutput mode supports the
User writeable and Object writeable attribute categories.
Output. The Field Attribute only sends output. The Field Attribute writes to the specified
output destination. The Output mode supports the following categories:
m
Calculated
Calculated retentive
User writeable
rn
Object writeable
Note: We recommend you do not extend the Field Attribute value with an lnput, 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:
e
Integer
* Float
e
Double
The Analog Field Attribute provides the enabling and configuration for the following functionality:
Scaling of lnput and Output values
e
e
e
e
e
History
HIHi, Hi, Lo and LoLo Limit Alarms
Rate of Change Alarms
Target Deviation Alarms
Bad Value Alarm
Statistics
3-9
3-10

The Discrete Field Attribute provides the enabling and configuration for the following functionality:
e
State Labels
e
Histoly
State Alarm
e
Bad Value Alarm
e
Statistics
The UserDefined object is an object that you can use to create customized objects. You can use
the UserDefined object in the following ways:
1. 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:
e
LTIOO -Analog Field Attribute - lnput from a level transmitter configured with options
such as: Scaling, Limit alarms and Statistics (MinlMaxlAvg).
TT100 -Analog Field Attribute - lnput from a temperature transmitter configured with
options such as Rate of Change alarm and Statistics (MinIMaxlAvg).
SWlOOa - Discrete Field Attribute - lnput from a limit switch configured with options
such as State Labels and State alarm.
SWlOOb - Discrete Field Attribute - lnput from a limit switch configured with options
such as State Labels and State alarm.
XV100a - Discrete Field Attribute - lnputoutput to a solenoid valve configured with
options such as State Labels, State alarm, and Statistics (OpenlClose time).
XV100b - Discrete Field Attribute - lnputoutput to a solenoid valve configured with
options such as State Labels, State alarm, Statistics (OpenlClose 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 XVlOOa and XVlOOb 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:
I F m e . X V 1 0 0 a == "Open" AND me.XV100b == "Open" THEN
rne.Value0penAlarm = true;
ELSE
me.Value0penAlarm = false;
ENDIF;
2. 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.
Wondeware Training
Lab 7 - Heat xchanger

Introduction
In this lab the 8UserDefined 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
e
Configure and use object templates to create instances that will inherited the configuration
Use the Field Attributes functionality provided by the 5UserDefined object
Use the Galaxy Browser to build references to instances' attributes within the Galaxy
the user is Ann Brown. Valve would be ABValve) This will eliminate problems when deploying
vour obiects in a common oalaxv later in the course.

Create t h e Heat Exchanger Template
1. Derived a new template from the 5UserDefined object, name it $ABHeatEx, and assign it to
2. Add to the $ABHeatEx template four analog field attributes named T I , T2, T3 and T4.
Configure each field attribute as follows:
Access mode:
Input
Data type:
Float
Engineering units:
Deg F
Enable 110 scaling:
checked
Raw value - Maximum:
"
EU value Maximum:
EU range value - Maximum:

EU range value Minimum:
4095.0
250.0
-5.0
255.0
Wonderware System Platform 3.0 Course Parl I
3-11
3-12

Create a Heat Exchanger Instance
3. Create an instance of the $ABHeatEx template (leave the default name) and assign it to the
ABlntake area.
4. Configure the Input source of each one of the four field attributes with the following
references:
where X X i s your student number.
Deploy the Object

5. Deploy the object.
View the Heat Exchanger Data o n Runtime

6. Open Object Viewer from within the ArchestrA IDE.
7. Using the watch list created in Lab 5, add a new watch window called HeatEx and add the
following attribute references:
ABHeatEx.TI
ABHeatEx.T2
ABHeatEx.T3
ABHeatEx.T4
8.
Save the watch list

Following are Detailed Lab Instructions for completing this lab. For a surnrnaty of instructions,
Create the Heat Exchanger Template

1. In the Template Toolbox, create a derived template of the $UserDefined object by right.
clicking the WserDefined template and selecting New IDerived Template.
$oirartroe"i<e
'-
kBiBLine2 lABLlnr21
2. A new template is created. Use $ABHeatEx for the name.
3.
Move the $ABHeatEx object to your template toolset.
Wondeware Svsfem Platform 3.0 Course - Pad 1
3-13
3-14
4. Double-click on the $ABHeatEx template to open its configuration editor.
5. On the Field Attributes tab, click on the Add Analog button to add a new analog field
attribute.
d
$ABHeatEx
Feld Am D - u s /object
s. -UC-.... ..1nfo:rnation
... ..- I..Scr
. - .p
.-
Wondeware Training

6. Configure the new field attribute as follows:
Name:
TI
Access mode:
Input
Data type:
Float
Engineering units:
Deg F
Enable 110 scaling:
checked
Raw value - Maximum:
4095.0
EU value - Maximum:
250.0
EU range value - Minimum:
-5.0
EU range value - Maximum:
255.0
3-15
3-16

Repeat steps 5 and 6 to add three more field attributes. Name the attributes T2, T3 and T4
Click the Save and Close button and check in the object
The Check I n dialog box appears. Enter initial configuration and setup in the Comment
field and click OK.
Inlbal configurabon and setup.
Wonderware Training

10. A second Check In dialog box is displayed indicating the progress of the operation. As soon
as the process is complete, the Close button will be enabled. Click the Close button.
Check I n complete
Create a Heat Exchanger Instance

11. Using the Template Toolbox and the Model view, create an instance of the $ABHeatEx
template using the default name of ABHeatEx-001.
Assign the instance to the ABlntake area.
&
ABGalaxy
;--
UnassignedArea
Q
@
ABControI5ystnn
.
.
@ ABAppEngine
.. ..;----.. i---. @ ABGRPlatform
i.....[71
s Incontrol
j+ & ABDischarge
~.
-
! - -&ABLinel [ ABLinel]
61ABLine2 [ ABLineZ]
Wonderware Svstem Platform 3.0Course -Pad 1
3-17
3-18

12. Double-click on the ABHeatEx-001 instance to open its configuration editor.
Name:
A<clsr mode:
category:
Derolpbon:
13. On the Inherited field attributes section, select the T I attribute.
Wondeware Training
tiamr:
i1
Access mode:
In%:
AtltibvteWp
Data bps:
Lab 7 - Meat Exchanger

14. On the I10 section, click on the Input source ellipsis button to assign a reference using the
Galaxy Browser.
.I,O
..
a.
.;
input sa~rce:
.. .. ...
.--
...
-. .- .
...- ..
...-. .
. . .
15. The Galaxy Browser window appears
Wonderware Sysfem Plafform 3.0 Course Pad I
3-19
3-20

16. Select the reference as follows and click OK:
From the left panel select the Incontrol object.
From the right panel select tagname.HEXXO_TCI where XXis your student number. The
following screenshot uses '00' as an example.
17. The lnput source attribute contains the selected reference
18. Repeat steps 13 to 17 to configure the lnput source for attributes T2, T3 and T4 using the
tagname.HEXXO-TC2, tagname.HEXXO-TC3 and tagname.HEXXO-TC4 attributes.
19. Click the Save and Close button and check in the object.
Wonderware Training

20. The Check In dialog box appears. Enter Initial configuration and setup in the Comment
field and click OK.
Deploy the Object

21. Select the Deployment view, right-click the ABHeatEx-001 instance and select Deploy.
Wondeware System Platform 3.0 Course - Parf 1
3-21
3-22

22. The Deploy dialog box appears. By default the system will set the instance On Scan as soon
as the object is deployed. Leave the default settings and click OK.
23. A second Deploy dialog box appears indicating the progress on deploying the object. As soon
as the process is complete, the Close button will be enabled. Click Close
Validating connected galaxy.
Vrdidatino
...
. - -GRNodeInfo
-.
- - -~
~hechn~nhemer
omlecrs beng oeployed reqJre sofware upgrade...
Subng and '/a oabng 1objecr(s) smrbng from ABHearL-001 hosted by p l a 3 ~ r nABGRP
l
i
Deploying 1 ALrornauon Objectk) smrong n AKHeatEx-001 to the ABApp3g'ne
Wonderware Training

View the Heat Exchanger Data on Runtime
24. Open Object Viewer by right-clicking the ABHeatEx-001 instance and selecting View in
Object Viewer.
Wonderware System Platform 3.0 Course - Pad 1
3-23
3-24

25. The Object Viewer application opens displaying the attributes of the selected object. If you
closed Object Viewer before, you can use File ILoad Watch List to open the file you saved
earlier.
M06fy.. .
Remove +ern \Vat&
Add AtVibute Refrrenre...
Open
Save
...
Save As..
Wondeware Training

rename the default Watch List 1 tab.
Remove fiom Wat&
Add Attribute Reference
Add Watch Window
Open
save
save As...
...
...
28. The Rename Tab dialog box is displayed. Enter HeatEx for the Tab Name field and click OK.
29. On the Attribute List lrioht section of Obiect Viewer) locate the followina attributes, right-click
on them, and select Add t o Watch to a& them to thk watch list:
e
e
e
e
TI
T2
T3
T4
ABHeatEx-001.T2
ABHeatEx-OOl.T3
ABHeatEx-001.T4
201.8844
61.41854
152.7081
CO:Good
CO:Good
CO:Good
Ok
Ok
Ok
Wondenvare System Platform 3.0 Course - Pert 1
3-25
3-26
Module 3 - Application Objects

watch list to disk.
ModiFy..
Remove from Watd-i
Add Attribute Referene...
Add Watch Window
Remove Watch Window
Rename Tab
...
Wonderware Training

Section Objectives
Introduce the concept of attribute locking, and
Explain how locking attributes can propagate to previously derived instances.
This section presents the concept of attribute locking and provides an illustrations on how locking
attributes can propagate to previously derived instances.
Locking an attribute in a Template indicates that its value is to be logically "shared kith all derived
objects (Templates or instances). In other words, when the value changes in the template, that
change is propagated to all the derived children of the object. When an attribute is "locked" in the
Template, the value can be changed in that Template but not in any of the derived children.
Based on this concept, an attribute can have one of three logical lock types:
Unlocked: Both Templates and instances can have these. Attribute is read-write. The
object has its own copy of the attribute value and is not shared by derived objects.
Locked: Only Templates can have these. Attribute value is read-write. Derived objects
don't have a unique copy of the attribute value, but instead share the locked one (it is
Locked In Parent - see next item). By changing the value of a locked attribute, the logical
value of that attribute is updated in all derived objects.
e
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
Wondeware System Plafforrn 3.0 Course -Pad 1
3-27
3-28
To lock a Template attribute, do the following:

1. Select the desired Template in the ArchestrA IDE and launch its editor.
2.
Enter a value in an attribute field in the object's editor.
3.
Select the locking mechanism for that attribute. Some editors may have lock icons associated
with certain edit fields, but this possibility is within the scope of the developer of the object's
editor.
4. Save and close the object editor.
The locked attribute in any derived templates and instances created from this template are locked
and unavailable. To test this, you can derive a new template or create an instance from the original
template, and then check the new object's editor. The locked attribute is unavailable for editing.
Unlocking an Attribute
To unlock a Template attribute, do the following:
1. Select the desired Template in the ArchestrA IDE and launch its editor.
2. 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.
3. Save and close the object editor.

The previously locked attribute in any instances created from this template are now unlocked. The
previously locked attribute in any templates derived from this template are still Locked (in me). The
previously locked attribute in any instances of derived templates remain in Locked in Parent.
Wondeware Training
Lab 8 - Change Control and ropagation

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
Lock attributes in templates to control the changes that can be made on derived objects
e
Propagate changes from templates to derived object by modifying the value of locked
attributes

Lock the Attributes

1. On the 8ABHeatEx template, modify the configuration of the four field attributes as follow:
Engineering units:
'Celsius' and locked
Scaling section:
locked
Verify the Changes to the Existing Instance

2. Open the configuration editor for the ABHeatEx-001 instance to verify the changes made in
the template.
Redeploy the Object

3.
Redeploy the object
3-29
3-30

please refer to the Summary Lab Instructions on the previous page($.
Lock the Attributes

1 . In the Template Toolbox, double-click on the $ABHeatEx template to open its configuration
editor.
'1
,.Yabe
8@
1 D~~~~~~~~~~~~~~
~ ~ ~ 8
. .iW-
Wonderware Traming
Valuedeadban&
Engineering unill:
....
~T
8 :4 1
- ....
3-31
2. In the Field attributes section, select the T I attribute and change the configuration as follows:
Engineering units:
'Celsius' and locked
Scaling section:
locked
/
Access mode:
Ahributetype:
Wt
, ,I
! Cowenionmode:
i.
Datatype:
/Li"ear/8
.
13-1
ildwinpotto~lianse
tJ
. ...
3. Repeat step 2 for field attributes T2, T3 and T4.

Wondenvare System Platform 3.0Course -Part 1
.>
3-32

Verify the Changes to the Existing Instance
5.
The existing ABHeatEX-001 instance indicates that a change has been made to its
configuration since it was last deployed.
6.
Double-click the ABHeatEx-001 instance to open its configuration editor and verify the
changes.
Select the T I field attribute and expand the Enable 110 scaling section.
valvr deadband
7. Click the Close button to close the editor
Lab 8 -Change Control and Propagation

Redeploy the Object
8.
Select the Deployment view, right-click the ABHeatEx-001 instance and select Deploy.
Wondeware Syslem Platform 3.0 Course -Part 1
3-34

9. The Deploy dialog box appears. Leave the default settings and click OK.
10. A second Deploy dialog box appears indicating the progress on deploying the object. As soon
as the process is complete, the Close button will be enabled. Click Close.
Deploycomplete
1 Ivslidatins connected galaxy ...
..
validating ~ ~ ~ o d e ~ n f o .
Cheddng whether objects being deployed require s o h a r e upgrade..,
Sorting and Validating 1object(s) starting from ABHeatEx-001 hosted by platform ABGRPI:
Deploying 1Automation Object(s) starting with ABHeatEr 0 0 1 to the AB
Wondenvare Training

Section Objectives
This sect'on:
Introduces you to the concept of the SAnalogDevice 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 inputloutput object with
alarming and history. When configured as an analog regulator device, the AnalogDevice object
provides an external model of a PID controller that exists in a field device, in addition to providing
the traditional analog alarming and history capabilities.
AnalogDevice Object as a Basic Analog InputlOutput Object
e
AnalogDevice Object as an Analog Regulator Object
AnalogDevice Object as a Basic Analog InputlOutput 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 110 characteristics are:
The process value (PV) is read from the field (except when the AnalogDevice object is
configured to be in Manual mode).
You can configure the AnalogDevice object to enable or disable analog output. If you
enable output, you can configure the output destination address to be the same (default)
or different from the input source address. Commands to change the PV will result in an
output to field. For data integrity, the value of PV represents the value read from the
external controller (except when the AnalogDevice object is in Manual mode), not the
requested PV that is output to the external controller.
The input and outputs can be optionally scaled between raw counts and engineering unit
values using either linear or square-root conversions.
The AnalogDevice object supports alarming for PV conditions, such as when the PV:
e
Exceeds level limits, such as Lo, Hi, LoLo, and HiHi.
e
Exceeds rate-of-change limits, for both positive and negative directions
e
Exceeds major and minor deviations from a target value
e
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.
3-35
3-36

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 110 characteristics are:
The process value (PV) is read from the field (except when the AnalogDevice object is
configured to be in Manual mode), but is never written.
The SP value is both read from the field and written to the field. You can configure the SP
output destination address to be the same (default) or different from the input source
address. Commands to change SP result in an output to field. For data integrity, the value
of SP always represents the value read from the external controller, not the requested SP
that is output to the external controller.
The PV and SP can be optionally scaled between raw counts and engineering unit values
using either linear or square-root conversions.
The AnalogDevice object supports alarming for PV conditions, including when the PV:
Exceeds level limits, such as Lo, Hi, LoLo, and HiHi.
e
Exceeds rate-of-change limits, for both positive and negative directions.
e
Exceeds major and minor deviations from the SP value.
0
Has a quality value of BAD.
In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV
value. If you enable the PV override, then you can use the PV.Mode attribute to place the
AnalogDevice object into either Auto or Manual mode. When the AnalogDevice object is in Auto
mode, the PV is updated from the field and matches the value and quality of the PVAuto attribute.
When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated
from the field, but the PV value does not. Instead, the PV can be set by a user write or a script, and
the quality is always set to UNCERTAIN.
Other controller-oriented features that can be configured for an AnalogDevice object of type
analog regulator include:
Controller mode (CtrlMode attribute). You can use the controller mode to govern what
types of writes are allowed to the SP value within the system. Controller mode options are
Manual, Cascade, and None. When the object is in Manual mode, only end users are
allowed to command a change in the value of SP. In Cascade mode, only scripts or other
supervisory objects are allowed to command a change to SP. Finally, if None is specified
for the controller mode, any type of write is allowed for the SP.
Control tracking. A Boolean control track flag can be read from an external device or
object. When tracking is on, the external controller "owns" the value of the SP; the SP is
purely read-only and cannot be commanded to be changed and output to the field.
Wonderware Training
Lab 9 - Meter
Lab 9 - 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
e
Configure an $AnalogDevice object
Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.(e.g.. if
vour obiects in a common aalaxv later in the course.
General Steps
Create t h e Meter template
1. Derived a new template from the $AnalogDevice object, name it $ABMeter, and assign it to
2. Configure the object as follows:
Type:
Analog (locked)
Enable analog output:
Unchecked (locked)
Enable PV override:
Unchecked (locked)
Enable 110 scaling:
checked (locked)
Raw value Minimum:
0.0 (locked)
Raw value Maximum:
4095.0 (locked)
Conversion mode:
Linear (locked)
Clamp input t o EU range:
unchecked (locked)
3-37
3-38

please refer to the Summary Lab Instructions on the previous page(s).
Create the Meter Template

1. In the Template Toolbox, create a derived template of the $AnalogDevice object by rightclicking the $AnalogDevice template and selecting New IDerived Template.
2. Use $ABMeter for the name of the template and move it to your template toolset
i ;&Template
.
.
.-..- .... .
Toolbox
. . . .. . .
Ti
.. .
. . .. - ....
....
3. Double-click on the $ABMeter template to open its configuration editor.
Wandemere Training
Lab 9 - Meter
4. Configure the General tab as follows:
5.
Type:
Analog (locked)
Enable analog output:
Unchecked (locked)
Enable PV override:
Unchecked (locked)
Enable 110 scaling:
checked (locked)
Raw value Minimum:
0.0 (locked)
Raw value Maximum:
4095.0 (locked)
Conversion mode:
Linear (locked)
Clamp input t o EU range:
unchecked (locked)
Click the Save and Close button and check in the object.
Wonderware Svstem Platform 3.0Course -Pad 1
3-40
Wondeware Training
lnfenfionally left blank -
Section 5 - T h e $DiscreteDevice Object
Section 5 - The $DiscreteDevice Object

Section Objectives
This section:
Introduces you to the concept of the $DiscreteDevice object and its functionality.
This section introduces you to the concept of the $DiscreteDevice object and its functionality
$DiscreteDevice Object
The DiscreteDevice object is a general purpose Applicationobject that represents a large class of
physical equipment common in manufacturing, such as pumps, valves, motors, and conveyors.
These devices have two or more discrete physical states (for example, Open, Closed, and
Moving). The actual state of a device is monitored using a combination of discrete inputs, and a
device can be optionally controlled using a combination of discrete outputs.
The state names are configurable and are mapped to both input and output Boolean combinations
in truth-table form. The meaning of the states depends on the type of discrete device. For a pump,
the states might be configured as "OW' 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:
e
Passive
The passive state represents the state of the discrete device when it is idle, stopped, or
closed (the typical non-running position). For example, the passive state for a motor might
be "Off."
First Active
The first active state (Activel) 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.
Wondeware Svstern Plafform 3.0 Course -Pad 1
3-41
3-42

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

If you configure the DiscreteDevice object to have inputs (feedback) from the field, the input values
are used to update the overall state of the device. A DiscreteDevice object can have up to four
inputs. After defining the inputs, map the different input combinations to the possible states for the
device.
For example, you might have a valve on your discrete device that can be either opened or closed.
You have defined the passive state of the device as Closed, the first active state as Opened, and
the fault state as Bad. You would then create references for two field inputs: one for the open
position (Valve-Open), and one for the closed position (Valve-Close). You then would map the
inputs to the defined states. For example:
Valve-Open
Valve-Close
Mapped State
Bad
Closed
Opened
Bad
where:
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.
0
When the object is in Auto mode, the PV updates from the field and matches the value
and quality of PVAuto.
When the object is in Manual mode, PVAuto continues to update from the field but the PV
does not. Instead, the PV can be set by a user or script and the quality is always marked
as UNCERTAIN.
W o n d e w r e Training
Section 5 -The $DiscreteDevice Object

When the object is in Simulate mode, the PV value is set equal to the Crnd 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 Crnd attribute. The transition and fault states are not comrnandable. 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 Crnd 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:
0
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 Crnd, whereas Cascade indicates
that only scripts or other supervisory objects are allowed to request a change to Cmd.
Control tracking. A Boolean control track flag can be read from an external device or
object. When tracking is on, the external controller "owns" the value of the Crnd; the Cmd
is purely read-only and is set to the value of PV.
Alarm Capabilities
The DiscreteDevice object provides sophisticated alarming capabilities, including:
e
Command timeout alarm, which indicates that the PV state did not change to match the
Crnd state within a configurable timeout period.
e
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).
e
Individual alarms for each of Activel, Active2, and Fault state conditions.
Duration alarms for each of Activel 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 calculation^ that can be used for
equipment monitoring and time-in-use tracking, including:
The most recent time durations of the Activel, Active2 and Passive states.
e
The total accumulated time durations of the Activel, Active2 and Passive states, with
optional alarming on the Activel and Active2 total durations.
e
The number of transitions into the Activel. Active2 and Passive states.
A commandable reset of all statistics.
Wondeware Syslern Platform 3.0 Course - Pad 1
3-43
3-44
- Infentionally
Wondeware Training
left blank -
Lab 10 - Valve,
ump 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
e
Configure a $DiscreteDevice object

lnstructions, please refer to the Detailed Lab lnstructions on subsequent pages.
Create the Valve Template

1. Derive a new template from the $DiscreteDevice object, name it $ABValve, and assign it to
2.
Configure the object's General tab as follows:

Enable inputs:
Checked (locked)
Enable outputs:
Checked (locked)
..Wonderware System Platform 3.0 Course -Part 1
3-45
3-46

3. Configure the object's States tab as follows:
4.
Enable second active state:
Unchecked (locked)
Enable transition state:
Checked (locked)
State names:
(locked)
Passive state:
Closed
First Active state:
Opened
Transition state:
Traveling
Fault state:
Fault
Configure the object's Inputs tab as follows:

Number o f Inputs:
2 (locked)
lnput Name:
(locked)
lnput 2 lnput Name:
CLS
Input I lnput Name:
OLS
lnput t o PV Map:
(locked)
0 0: Traveling
0 1: Opened
1 0: Closed
1 1: Fault
PV override:
(locked)
5. Configure the object's Outputs tab as follows:

Number of outputs:
I(locked)
Output Name:
(locked)
Output 1 Output Name:
CrndOpen
Closed:
Unchecked (locked)
Opened:
Checked (locked)
Initial control mode:
~ a n u a(locked)
l
Control tracking:
(locked)
Wondemare Training

Create t h e P u m p Template
6.
Derived a new template from the $DiscreteDevice object, name it $ABPump, and assign it to
7. Configure the object's General tab as follows:

Enable inputs:
Checked (locked)
Enable outputs:
Checked (locked)
9.
Enable second active

state:
Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
First Active state:
Running
Fault state:
Fault
Configure the object's Inputs tab as follows:

Number of Inputs:
1 (locked)
Input Name:
(locked)
Input 1 Input Name:
FlowSwitch
Input t o PV Map:
(locked)
0: Stopped
1: Running
PV override:
(locked)
Number of outputs:
1 (locked)
Output Name:
(locked)
CrndStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
3-47
3-48

Create t h e M o t o r Template
11. Derived a new template from the $DiscreteDevice object, name it $ABMotor, and assign it to
the A 6 Training template toolset.
12. Configure the object's General tab as follows:
Enable inputs:
Checked (locked)
Enable outputs:
Checked (locked)

Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
First Active state:
Running
Fault state:
Fault
14. Configure the object's Inputs tab as follows:

Number of lnputs:
1 (locked)
Input Name:
(locked)
Input IInput
Name:
AuxContact (locked)
lnput t o PV Map:
(locked)
0: Stopped
1: Running
PV override:
(locked)

Number o f outputs:
1 (locked)
Output Name:
(locked)
CmdStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
Wondeware Training

Following are Detailed Lab lnstructions for completing this lab. For a summaw of instructions,
Create the Valve Template

1. In the Template Toolbox, create a derived template of the $DiscreteDevice object by rightclicking the $DiscreteDevice template and selecting New 1 Derived Template.
2. Use $ABValve for the name of the template and move it to your template toolset
3. Double-click on the $ABValve template to open its configuration editor.
3-49
3-50

4.
Configure the General tab as follows:

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

Unchecked (locked)
Checked (locked)
State names:
(locked)
Passive state:
Closed
First Active state:
Opened
Transition state:
Traveling
Fault state:
Fault
Wonderware Training

6.
Configure the Inputs tab as follows:

Number of lnputs:
2 (locked)
lnput Name:
(locked)
lnput 2 lnput Name:
CLS
Input 1 lnput Name:
OLS
lnput t o PV Map:
(locked)
0 0: Traveling
0 1: Opened
1 0: Closed
1 1: Fault
PV override:
(locked)
:.
Wondeware System Platform 3.0 Course - Parl 1
3-52

7. Configure the Outputs tab as follows:
Number of outputs:
I(locked)
Output Name:
(locked)
CmdOpen
Closed:
Unchecked (locked)
Opened:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
;m~km------
Numberof outputs:
Commandablertater:
a
output ~ a m eB
OutputDermatlon Reference
8. Click the Save and Close button and check in the object
Wondewere Training

Create the Pump Template
9.
In the Template Toolbox, create a derived template of the $DiscreteDevice object by right.
clicking the $DiscreteDevice template and selecting New I Derived Template.
10. Use $ABPump for the name of the template and move it to your template toolset
i &Template
Toolbox
.. . ... .
.....
-- ..-.- .. .....
8..
- J ? X
.. . . .
ABGalaw
E. l @
. AB Training
,~\
; ;.....@ $ABAppEngine
:
i
.
.
.
:
i:
..
.
.
.
.
i.....
:
..
& $ABArea
a$ABDDESuiteLinkClient
&) S4BHeatEx
;.... &) $ABMeter
11. . Double-click on the $ABPump template to open its configuration editor.
3-53
3-54

Enable inputs:
Checked (locked)
Enable outputs: Checked (locked)
Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
First Active state:
Running
Fault state:
Fault
,Shh,nnrrrr-t--.~
P a r w e state:
Stowed
R O t P d i v e state:
Runilg
*::;e2
Transitionstate:
~zuitrtate:
Wonderware Training
rPiiri"slr.i

14. Configure the Inputs tab as follows:
Number of Inputs:
I (locked)
Input Name:
(locked)
lnput 1 lnput Name:
Flowswitch
Input t o PV Map:
(locked)
0: Stopped
1: Running
PV override:
(locked)
3-56

Number of outputs:
I(locked)
Output Name:
(locked)
CrndStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
Wondeware Training

Create the M o t o r Template
17. In the Template Toolbox, create a derived template of the 5DiscreteDevice object by rightclicking the $DiscreteDevice template and selecting New I Derived Template.
18. Use 5ABMotor for the name of the template and move it to your template toolset.
.....
.......
WTunplate Toolbox
.....
.....
- ............
- P X
. .
19. Double-click on the 5ABMotor template to open its configuration editor.
Wondeware Syslem Plalform 3.0 Course Pad 1
3-57
3-58

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

Unchecked (locked)
Unchecked (locked)
State names:
(locked)
Passive state:
Stopped
First Active state:
Running
Fault state:
Fault
-state names
d?-
~arrivertate:
Tranritionrtate:
Faultstate:
Wondenvare Training

22. Configure the inputs tab as follows:
Number of Inputs:
I (locked)
lnput Name:
(locked)
lnput Z lnput Name:
AuxContact
lnput t o PV Map:
(locked)
0: Stopped
1: Running
(locked)
PV override:
Inputto M Map
8
lniiiat W mode: /~~u!:iilu
.-
3-59
3-60

Number of outputs:
I(locked)
Output Name:
(locked)
CrndStart
Stopped:
Unchecked (locked)
Running:
Checked (locked)
Manual (locked)
Control tracking:
(locked)
mwbpJ
Nurnberaf outputs:
Cornrnandablertater:
.. .
.-
d
output name
output~ertinationRefennce
Initial rontral mode:
Control track input souice:
Wondenvare Training
Section Objectives
This section illustrates the concept of containment and how it works with Appication 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:
e
Tagnames
Contained Name
Hierarchical Name
--
:ontained Name
iierarchical Name
Description
. . .. .
. .
... . . ..... . .- - . . ... . - ...
The ~ n i q name
~ e of tne individ~alobect. For example, Valvel
The name of the object within the context of its container object. For
example, the object whose Tagname is Valvel may also be referred to
as Tankl .Outlet, if Tankl contains it and it has the contained name
"Outlet".
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:
"Reactorl" contains Tankl (also known within Reactorl by its contained
name "SurgeTank").
"Tankl" contains Valvel (also known within Tankl by its contained
name "Outlet").
Valvel could be referred to as:
"Valvel"
"Reactorl .SurgeTank.Outlet".
Wonderware System Platform 3.0 Course -Pail 1
3-61

For example, an instance of a $Tank is named TankOl. An instance of $Valve called ValveOl is
contained within the instance of $Tank.
Change the contained name of ValveOl to Inletvalve. Now ValveOl can also be referred to by its
hierarchical name Reactorl.In1etValve. 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 bv other AoolicationObiects. Areas can onlv contain other Areas.
Applicationobject Containment
ApplicationObjects can be contained by other ApplicationObjects. This provides context for the
contained object and a naming hierarchy that provides a powerful tool for referencing objects.
Note: Base templates cannot be contained by another template, either as the container or as the
template being contained. You can only use containment with derived templates.
--
An example of a containment h~erarchyis a tank that contains the following objects:

e
Inlet Valve
Agitator
e
Outlet Valve
.
r
Level
Wondeware System Platform 3.0 Course -Pati 1
3-63
3-64

To enable referencing and flexibility within scripting, these objects can be referenced in several
different ways. Each object has a unique Tagname, such as:
e
Inlet Valve = InletValveOl
e
Agitator = Agitator01
Outlet Valve = OutletValveOl
Level = Level01
Wondenvare Training
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 TankOl. the contained names are:
e
TankOl.lnlet
TankOl .Agitator
e
Tank01.0utlet
e
TankOl .Level
Additionally, you can use containment references in scripts such as:

Me.Outlet: Allows a script running within the parent object to generically reference its child
outlet instance.
MyContainer.lnlet: Allows a script running in any of the children instances to reference
another child instance named Inlet that belongs to the same parent.
Wondeware System Plalform 3.0 Course -Part I
3-65
3-66

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.
~ z e 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.
Obiects with broken references receive bad quality data at run-time.
To rename an object's contained name
1. Select the object in an Application view.

2. On the Edit menu, click Rename Contained Name.
3. Type a new contained name.

All IDES connected to the Galaxy show the object's new contained name
Containment and the Derivation View

The Derivation View does not show containment relationships. It shows templates and instances
with regard to containment in the follow ways:
* Non-contained instances show their tagnames.
e
Contained instances show their tagnames and hierarchical names.
e
Non-contained templates show their object name.
Contained templates show their hierarchical name.
Containment of instances is limited to Areas containing other Areas and AppObjects containing
other AppObjects.
Renaming can be done on an instance's tagname and contained name. A template only has a
template name.
Wondenvare Training
Lab II- Mixer
Lab 11 - 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
e
Create and configure a containment relationship between objects.
vour obiects in a common galaxy later in the course.

Create t h e Mixer template
1. Derived a new template from the $UserDefined object, name it $ABMixer, and assign it to the
A B Training template toolset.
Create t h e Mixer's Contained Templates

2.
Derived three new templates from the $ABValve object, name them $Inletl, $Inlet2 and
$Outlet, and assign them to the $ABMixer template.
3. Derived two new ternplates from the $ABPump object, name them $Pump1 and $Pump2, and
assign them to the $ABMixer template.
4.
Derived a new templates from the $ABMotor object, name it $Agitator, and assign it to the
$ABMixer template.
Wonderware Sysfem Plafform 3.0 Course -Pad 1
3-67
3-68

5. Derived a new template from the $ABMeter object, name it $LIT, and assign it to the
$ABMixer template. Configure the object as follows:
6.
Engineering units:
Liters (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
100.0 (locked)
-5.0 (locked)
EU range value Maximum:
105.0 (locked)
Derived a new template from the $ABMeter object, name it $TT, and assign it to the $ABMixer
template. Configure the object as follows:
Engineering units:
Celsius (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
250.0 (locked)
-5.0 (locked)
255.0 (locked)
Create a Mixer Instance

7. Create an instance of the $ABMixer template (leave the default name) and assign it to the
ABLinel area.
Wondeware Training
Lab 11 - Mixer
8. Configure the input and output references for the contained objects as follows
where XXis your student number.
For Agitator-001
AuxContact.lnputSource:
CmdStart.OutputDestination:
For lnletl-001
CLS.lnputSource:
0LS.lnputSource:
CmdOpen.OutputDestination:
For lnlet2-001
CLS.lnputSource:
0LS.lnputSource:
For LIT-001
PV.lnput.lnputSource:
For Outlet-001
CLS.lnputSource:
0LS.lnputSource:
For Pumpl-001
F1owSwitch.lnputSource:
CmdStart.OutputDestination:
For Pump2-001
FlowSwitch.lnputSource:
CmdStart.0utputDestination:
For TT-001
PV.1nput.lnputSource:
Deploy the Object

9.
. Deploy the object.
Wonderware Syslem Plaliorm 3.0 Course Part 1
3-69
3-70

View the Mixer Data in Runtime
10. Open Object Viewer from within the ArchestrA IDE,
11. Using the watch list created in Lab 5, add a new watch window called Mixer and add the
Agitator-001 .PV
Agitator-001 .Crnd
lnletl-001 .PV
lnletl-001 .Cmd
lnlet2-001 .PV
lnlet2-001.Crnd
LIT-001 .PV
Outlet-001 .PV
Outlet-001 .Cmd
Purnpl-001 .PV
Purnpl-001 .Crnd
Pump2-001 .PV
Pump2-001 .Cmd
TT-001 .PV
12. Save the watch list.
Wondeware Training
Lab 11 - Mixer

Create the Mixer Template

1. Create a derived template of the $UserDefined object by right-clicking the template and
selecting New IDerived Template.
2. Use $ABMixer for the name of the template and move it to your template toolset.
Create the Mixer's Contained Templates

Create t h e Mixer's Valves Templates
3. Create a derived template of the SABValve object by right-clicking the template and selecting
New IDerived Template.
4.
Use $Inlet1 for the name of the template (Notice that you will not use your initials for this
object) and assign it to the $ABMixer template to contain it within the $ABMixer object.
i .gTeniplate Toolbox
......
-.- - . - - .................................
Wondeware System Platform 3.0 Course - Part I
3-71
3-72
5.
Create a derived template of the $ABValve object by right-clicking the template and selecting
6. Use $Inlet2 for the name of the template (Notice that you will not use your initials for this
i iSTemplate
Toolbox
.
-. .
.-
- V X
ABGalaxy
8.@JAB Training
. .
;. ;--@ $ABAppEnqine
.
; ;----. & $ABArea
.
.
.i
.
;.
7.
..
I"
+-
. @$BDDESuiteLinkClient
.
.?-- @ $ABHeatEx
.
. @ SBMeter
;.....
15@ SABMixer
Create a derived template of the $ABValve object by right-clicking the template and selecting
New 1 Derived Template.
8. Use $Outlet for the name of the template (Notice that you will not use your initials for this
Wondewwe Training
Lab II - Mixer
Create t h e Mixer's P u m p s a n d Agitator templates
9. Create a derived template of the $ABPump object by right-clicking the template and selecting
New / Derived Template.
10. Use $Pump1 for the name of the template (Notice that you will not use your initials for this
i QTemplate Toolbox
...- .
o...
.........
ABGalax,
- P X
-- ......
e -@ AB Training
;
a~
@ $ABAppEngine
;. ;..
/$ SABArea
.
:
.~.
i.
:
.
;.
..
.i:.
.
"
!:.
i.
.$
a.
SABDDESuiteLinkClient
SBHeatEx
$ABMeter
SBMixer
..
..i..... 0 Inlet1
. O Inlet2
0
0
0
9
..
..i
>
:.
11. Create a derived template of the $ABPump object by right-clicking the template and selecting
New I Derived Template.
12. Use $Pump2 for the name of the template (Notice that you will not use your initials for this
3-73
3-74
13. Create a derived template of the $ABMotor object by right-clicking the template and selecting
14. Use $Agitator for the name of the template (Notice that you will not use your initials for this
-tgjTemplate Toolbox
- .- .- .-....... .
- 9 X
. . .. .. ..
...
Create t h e Level a n d Temperature Meter Templates

15. Create a derived template of the $ABMeter object by right-clicking the template and selecting
Wondenvare Training
Lab 11 - Mixer
16. Use $LIT for the name of the template (Notice that you will not use your initials for this object)
and assign it to the $ABMixer template to contain it within the $ABMixer object.
-...
: &Ternplate
Toolbox
4 X
. ~ .. . ~
17. Double-click on the $ABMixer.LIT template to open its configuration editor.
Wondenvare Svstern Platform 3.0 Course -Pad 1
3-75
3-76

Engineering units:
Liters (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
100.0 (locked)
-5.0 (locked)
105.0 (locked)
20. Create a derived template of the $ABMeter object by right-clicking the template and selecting
New I Derived Template.
Wonderware Training
Lab II- Mixer

21. Use $TT for the name of the template (Notice that you will not use your initials for this object)
and assign it to the $ABMixer template to contain it within the $ABMixer object.
22. Double-click on the $ABMixer.TT template to open its configuration editor
Wondenvare Svstem Platform 3.0 Course - Parf I
3-77
3-78

Engineering units:
Celsius (locked)
EU value Minimum:
0.0 (locked)
EU value Maximum:
250.0 (locked)
-5.0 (locked)
255.0 (locked)
Wonderware Training
Lab 11 - Mixer
Create a Mixer Instance
25. Using the Template Toolbox and the Model view, create an instance of the $ABMixer
template using the default name of ABMixer-001.
Assign the instance to the ABLinel area
Configure the Agitator

26. Double-click on the Agitator-001 instance to open its configuration editor.
27. Select the Inputs tab and configure the Input Source Reference as follows:
AuxContact: InControl.tagnarne.TXXOOAGGAuxContact
where XX is your student number.
3-79
3-80

28. Select the Outputs tab and configure the Output Destination Reference as follows:
CmdStart: InControl.tagnarne.TXXO~AG~CmdStart
Configure Inlet1
30. Double-click on the lnletl-001 instance to open its configuration editor.
CLS:
InControI.tagname.TXX0-IVI-CLS
OLS:
InControl.tagnarne.TXX0-IVI-OLS
CmdOpen: InControl.tagnarne.TXX0-IVI-CmdOpen
Lab 11 - Mixer
Configure Inlet2
34. Double-click on the lnlet2-001 instance to open its configuration editor.
CLS:
InControl.tagnarne.TXX0-IV2-CLS
OLS:
InControl.tagnarne.TXXO-IV2-0LS
inputSourreRefeirorc
-- j
/as .$
/I.~~~...TWIV~C
CmdOpen: InControl.tagname.TXX0-IV2-CmdOpen
37. Cl~ckthe Save and Close button and check in the object.
Configure the LIT

38. Double-click on the LIT-001 instance to open its configuration editor.
39. Select the I10 tab and configure the PV input source as InControl.tagname.TXXO_LT-PV.
Wondeware System Platform 3.0 Course - Part 1
3-81
3-82

Configure Outlet
41. Double-click on the Outlet-001 instance to open its configuration editor.
CLS:
InControl.tagname.TXXL-OV-CLS
OLS:
InControl.tagname.TXXO~OV~0LS
CmdOpen: InControl.tagnarne.TXXO-OV-CrndOpen
--
Wonderware Training
Lab II- Mixer

Configure P u m p 1
45. Double-click on the Pumpl-001 instance to open its configuration editor.
FlowSwitch: lnControl.tagnarne.TXXO_TP1~FlowSwitch
CmdStart: InControl.tagname.TXXOOTP1-CmdStart
Configure P u m p 2
49. Double-click on the Pump2-001 instance to open its configuration editor
Wondeware System Platform 3.0 Course - Part l
3-83
3-84

Flowswitch: InControl.tagname.TXX0~TP2~FlowSwitch
CmdStart: InControl.tagname.TXXO-TP2-CmdStart
Configure t h e TT
53. Double-clickon the TT-001 instance to open its configuration editor.
54. Select the 110 tab and configure the PV input source as lnControl.tagname.TXXO-TT-PV.
Wondeware Training
Lab 11 - Mixer
Deploy the Object

Select the Deployment view, right-click the ABMixer-001 instance and select Deploy.
The Deploy dialog box displays. By default the system will do a Cascade Deploy of all 9
objects in the containment relationship and set all instances On Scan as soon as the objects
are deployed. Leave the default settings and click OK.
A second Deploy dialog box displays indicating the progress on deploying all 9 objects. As
soon as the process is complete, the Close button will be enabled. Click Close.
Deploy complete
Wondeware Sysfem Platform 3.0 Course - Pad 1
3-85
3-86

View the Mixer Data in Runtime
59. Open Object Viewer by right-clicking the ABMixer-001 instance and selecting View i n
Object Viewer. If you closed Object Viewer before, you can use File I Load Watch List to
open the file you saved earlier.
rename the watch list to Mixer.
Wonderware Training
Lab 11 - Mixer
62. Using the Object List (lefl 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 rightclicking on each attribute and selecting A d d t o Watch:
For Agitator-001
PV
Crnd
For lnletl-001
PV
Crnd
For lnlet2-001
PV
Crnd
For LIT-001
PV
For Outlet-001
PV
Cmd
For P u m p l ~ O O l
PV
Cmd
For Pump2-001
PV
Cmd
For TT-001
Agitator-0Ol.PV
Agitator-001.Crnd
Inletl-001.PV
Inletl-001.Crnd
Inlet2-001.PV
Inlet2-001.Crnd
Lrr-001.PV
Outlet-001.PV
Outlet 001.Crnd
PV
Stopped
Stopped
Closed
Closed
Closed
Closed
100.0
Traveling
Closed
watch list to disk.
3-87
3-88
- lnfentionally
Wondeware Training
left blank -
xtending the Objects

Section 1 - UDAs
- Motor Speed
Section 3 - Introduction to Quickscript .NET
Lab 12

Lab 14 - Automatic Reference Configuration
4-2

. .
Module objectives
Be able to work with extending the objects and configurhg them for addytional
functional~ty.
Wonderware Training
Section 1 - UDAs
Section I- 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:
Add a new attribute to an object.
Configure its data type.
e
Specify the attribute category.

Set initial values and locks on the new attribute.
Set whether the new attribute is an array and how many elements comprise it.
Set alarms and historization for the new attribute (done on the Extensions page).
Define security and references to other objects (done on the Extensions page).
Note: After you add an attribute to an instance, it appears in the Attribute Browser list for use with
the scriotina 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.
4-3
4-4

The UDAs page is comprised of three main functional areas and a set of function buttons. These
are described below.
..- .--, . . . ...:,. . .-.- Scr pts - D A r :.Extensions
..
.-.
Grapncs .
I . . . .. .-.. . .- .. - - -
-.
Geners
I Object Inforrnatlon
.-- . -..
Data type:
Category:
i?This ~can air*!

D-As Name List
Iwrnber of elements
Data Type Group
The main areas of the UDAs page include:

e
UDAs list: Lists all UDAs currently associated with the object. Click the Add button to add
a new UDA.
e
Inherited UDAs list: Lists all UDAs associated with the object's parent. The object
automatically includes these UDAs. They can only be edited by modifying the parent
template.
Data type list: Shows the data type options for configuring the selected UDA.
Select from the data types Boolean, Integer, Float, Double, String, Time, ElapsedTime or
InternationalizedString.
Allowed categories are Calculated, Calculated retentive,Object writable and User writeable.
You can lock writable attributes. If you select Calculated for an attribute, only scripts running on the
same object can write to the attribute.
Wondenvare Training
Section 1 - UDAs
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 TrueIFalse check
box to use a True value. Clear the check box to use a False value. For an arrayed Boolean, select
the desired element and provide a default value by typing either true or false.
When using UDAs in scripting, note the following:
0
When using Calculated and Calculated Retentive UDAs as counters, they must be
manually initialized. For instance, if you use me.UDA=me.UDA+l as a counter in a script,
you must also initialize the UDA with something like me.UDA=l or me.UDA=<some
attribute value>.
Calculated UDAs can be initialized in OnScan and Execute scripts (that is, scripts with
those types of Execution Type triggers), but not Startup scripts.
Calculated Retentive UDAs must be initialized in Startup scripts, and can be initialized in
OnScan and Execute scripts. The main purpose of a Calculated Retentive UDA is to
retain the attribute's current value afler 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.
Wondeware System Plafform 3.0 Course -Pad l
4-5
4-6
Module 4 - Extending t h e Objects
Wonderware Training
Section Objective
This section descr:bes 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 five main functional areas. These are described below.
v&bedc-
The main functional areas of the Extensions page include:

r
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.
e
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
attribup'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.
Wonderware System Platform 3.0Course -Pad 1
4-7
4-8

e
lnput Extension Group: Use to configure an attribute to be a reference source for

another object. In other words, the extended attribute acquires the update value of the
Source attribute.
Output Extension Group: Use to configure an attribute to be writeable to an external
object's attribute. In other words, when the value or quality (from Bad or lnitializing to
Good or Uncertain) of the extended attribute is modified, the value of the Destination
attribute is updated.
Alarm Extension Group: Use to create an alarm condition when a Boolean attribute's
value is set to TRUE.
History Extension Group: Use to historize the value of an attribute that does not already
have history capabilities.
Boolean Label Extension: Specify custom text strings for the False state and the True
state. These custom text strings appear in the Active alarm state list in the Alarm
extension area for you to select. If you are using the InTouch HMI, you can see these
custom text strings in InTouch.
To create and associate an extension with an object
1. On the Extensions page of the object's editor, select an attribute in the Extendable Attributes
List. The four extension groups dynamically change according to allowed extension rules for
the selected attribute type.
2. Select the check box of the kind of extension you want to apply to the selected attribute. The
associated parameters for each kind of extension are then made available.
3. For InputOutput Extension, enter a Source attribute by either typing in the reference string or
clicking the attribute browser button at right. Use the Attribute Browser dialog box to search
for the desired reference string in an object. Then if Destination is different from Source, click
Output Destination Differs from lnput 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 lnput 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 lnput
Source check box.
4.
For lnput Extension, enter a Source attribute by either typing in the reference string or
for the desired reference string in an object. An X is placed in the lnput column of the selected
attribute.
5. For Output Extension, enter a Destination attribute by either typing in the reference string or
for the desired reference string in an object. Select the Output Every Scan check box if you
want the extended attribute to write to the Destination attribute every scan period of the
object (otherwise, the write executes only when the value is modified or when quality changes
from Bad or Initializing to Good or Uncertain). An X is placed in the Output column of the
selected attribute.
6.
For Alarm Extension, select a Category from the list: Discrete, Value LoLo, Value Lo,
Value Hi, Value HiHi, DeviationMinor, DeviationMajor, ROC Lo, ROC Hi, SPC, Process,
System, Batch or Software. Type a Priority level for the alarm (default is 500). Also, choose
between Use Object Description for Alarm Message or typing in another alarm message in
the Message box. An X is placed in the Alarm column of the selected attribute.
Wondeware Training
7. For History Extension, enter values for the remaining parameters: Force Storage Period,
Engineering Units, Value Deadband, Trend High and Trend Low, if available (depends on
the data type of the selected attribute). An X is placed in the History column of the selected
attribute.
8.
Lock the value if desired. The lock symbol is available only when you are extending a
template. Otherwise, it indicates the lock condition of the value in the parent object.
9.
Set the security classification for the attribute if available. See "Security Icons" in "Working
with Object Editors" for more information.
10. Save and close the object editor to include the new attribute extensions in the configured
object.
Output Functionality
The following information applies to the functionality of Inputoutput and Output extensions as well
as the output function of the Field Reference. Switch and Analog Device objects.
If a single set request is made to a destination attribute during a single scan cycle, that value is
sent to the destination. During a single scan cycle, though, more than one set request to the same
destination is possible. In that case, folding occurs and the last value is sent to the destination.
The following occurs during a single scan cycle: Only the last value requested during a scan cycle
will be sent to its destination when the object executes. Its status is marked as Pending as it waits
for write confirmation from the destination object. All other set requests during that scan cycle are
marked as successfully completed.
If one or more new sets are requested during the next scan cycle, then the second scan cycle's
value is determined in the same way as described above. It is then sent to the destination when
the object executes again and the value sent to the destination during the previous scan cycle is
marked with successful completion status even if write confirmation had not been received.
In other words, within a single scan cycle, data is folded and only the last set requested is sent to
the destination. For instance, an {11,24,35,35,22,36,40) sequence of set requests will result in a
value of 40 being sent to the destination object. All other values result in successful completion
status.
The exception to the above-described functionality is for Boolean data types used in User sets
(sets from InTouch or FactorySuite Gateway). This functionality accounts for an unknown user
input rate (for instance, repeated button pushes) with a consistent object scan rate for outputs, and
therefore creates reproducible results. In this case, a combination of folding as described above
plus maintenance of a queue of one element deep in order to better meet the expectation of users.
To begin with, the first value set after the object is deployed (the default True or False) is always
written to its destination.
Subsequently, the following occurs during a single scan cycle: A two-tiered caching scheme of a
Value to be Sent and a Next Value to be Sent is implemented. The Value to be Sent is based on
data change as compared to the last value sent to the destination object. The Next Value to be
Sent is based on data change as compared to the Value to be Sent value. When the first data
change occurs, the new value is cached in the Value to be Sent queue. Folding occurs if the same
value is requested again. If another value change occurs, this second value is cached in the Next
Value to be Sent queue. Again, folding occurs if the same value is requested again.
zf
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.
Wondeware System Plafform 3.0 Course - Parf 1
4-9
4-10
In other words, for Boolean data types and User sets, the following examples apply:
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.
Wondemare Training

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 $ABMotor 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
e
Add and configure UDAs to your objects
Extend attributes with input and output functionality

A d d and Extend the UDAs
1. Add to the $ABMotor template two Float UDAs: one Object writeable named Speed, and
another one User writeable named SpeedSP.
2.
Extend the Speed attribute with an Input extension and configure its Source as
3.
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 t h e Agitator Instance

4.
Configure the newly added UDAs in the Agitator-001 object as follows:

Speed.lnputSource:
~n~ontrol.tagname.~~~~~~-Speed
SpeedSP.lnputSource:
InControl.tagname.TXX0-AG-SpeedSP
Wonderware System Plafform 3.0 Course -Pad 1
4-1 I
4-12

View the Agitator Speed Data in R u n t i m e
5. Deploy the object and open Object Viewer from within the ArchestrA IDE.
6.
Using the watch list created in Lab 5, add a new watch window called Extensions and add the
Agitator-001 .PV
e
Agitator-001 .Cmd
e
Agitator-001 Speed
e
Agitator-001SpeedSP
7. With the Agitator Running, set the SpeedSP attribute to any valid float value to test it.
Wondeware Training
Lab 12 -Motor Speed

Following are Detailed Lab Instructions for completing this lab. For a summav of instructions,
Add and Extend the UDAs

1. Double-click the 5ABMotor template to open its configuration editor.
Select the UDAs tab.
2. Click the plus icon button

configure it as follows:
3.
to add a UDA to the object. Name the UDA Speed and
Data type:
Float
Category:
Object writeable
Click the plus icon button

configure it as follows:
Data type:
Float
Category:
User writeable
to add a UDA to the object. Name the UDA SpeedSP and
Wondeware Svstem Plafform 3.0 Course -Pad 1
4-14

4. Select the Extensions tab
5. Select the Speed attribute and configure its extensions as follows:

Input extension:
checked
Source:
-.-.
Wondeware Training

6. Select the SpeedSP attribute and configure its extensions as follows:
Inputoutput extension:
checked
Source:
--- ---
Output destination differs

from input source:
unchecked (locked)
Wondeware System Plafform 3.0 Course -Pad 1
4-15
4-16

Configure the Agitator Instance
8. Double-click on the Agitator-001 instance to open its configuration editor.
Select the Extensions tab.
9. Select the Speed attribute and configure its Input extension as follows:
Source: InControl.tagname.TXXO_AG-Speed
where =is
the student number.
Attribute name:
Wondeware Training
*ed
II
Lab 12 - Motor Sweed
4-17
10. Select the SpeedSP attribute and configure its Inputoutput extension as follows:
Source: InControl.tagname.TXXO_AG-SpeedSP
where XXis the student number.
I/
Attribute name:
SpeedSP
Wondeware System Platform 3.0 Course - Parl 1
II
4-18

View the Agitator Speed Data in Runtime
12. Deploy the Agitator-001 object.
13. Open Object Viewer by right-clicking the Agitator-001 instance and selecting View i n Object
Viewer. If you closed Object Viewer before, you can use File ILoad Watch List to open the file
you saved earlier.
rename the watch list to Extensions.
16. Add the following Agitator-001 attributes to the watch list:
.
e
PV
Cmd
Speed
SpeedSP
17. With the Agitator Running, set the SpeedSP attribute to any valid float value (e.g. 50).
Aaitator 001.PV
A&ator~001.~rnd
Agitator-001.Speed
Agitator-00 1.SpeedSP
18. Save the watch list
Wandeware Training
Runnina
Running
50.56385
50.0
C0:Good
C0:Good
C0:Good
C0:Good
Ok
Ok
Ok
Ok
Section 3 - lntroduction to QuickScript .NET
Section 3 - lntroduction to QuickScript .NET

Section Objective
Tnis section introduces and explains the scripting environment and the various script~ng
configuration attributes of the ApplicationObject.
This section introduces and explains the scripting environment and the various scripting
configuration attributes of the ApplicationObject
UDAs and Scripting

When using UDAs in scripting, keep the following list in mind
If you use Calculated and Calculated retentive UDAs as counters, they must be
manually initialized. For example, if you use rne.uDA=rne.uOA+l as a counter in a script,
you must also initialize the UDA with something like me.uDA=l o r rne.UDA=<some
a t t r i b u t e value>.
Calculated UDAs can be initialized in scripts with Execution type triggers of On Scan and
Execute, but not initialized in Startup scripts.
You must initialize Calculated retentive UDAs in Startup scripts and you can initialize
these UDAs in On Scan and Execute scripts. A Calculated retentive UDA retains the
attribute's current value after a computer restart, redundancy-relatedfailover, 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.
The ApplicationObject Script

An ApplicationObject script is developed for the purpose of adding behavior to a specific
ApplicationObject. It will execute only when a deployed object containing the script is on scan.
The script isn't directly callable from other scripts (although changing the value of an object
attribute may allow the script's execution trigger conditions to command script execution). A script
doesn't have the concept of returning a specific value upon execution completion.
An ApplicationObject script is added to an ApplicationObject (template or instance) using the
ArchestrA IDE. The script related information is edited via the script editor. The editor exposes five
script types:
If the user selects an Execute type script, the script editor exposes one edit field for an expression
and another edit field for the script code.
The script expression acts as a filter for the invocation of Execute script execution. The expression
is evaluated every time the object that the script is attached to is executed. Dependent on the
evaluation the actual script is triggered or not.
4-19
4-20
~oduie
4 - Extending the Objects
This model is fine for simple scripts that just do some simple calculations. However, as soon as it is
necessary to instantiate external objects and keep them alive across multiple executions of the
script, the simple model falls apart. In order to support those more complex scenarios the script
writer can fill in script code for the Startup() and Shutdown() methods. External objects would be
instantiated in the Startup() method and destroyed in the Shutdown() method. If finer granularity is
needed the Onscan() and Offscan() methods can be used respectively. Onscan() and Offscan()
are invoked whenever the scan state of the object changes to OnScan and OffScan, respectively.
In order to support the just described scenarios the script offers a way to mimic static variables
(e.g., variables holding an instance of an object alive across different execution cycles). This is
accomplished by using a Dim statement in the upper Declarations section of the script editor.
Variables so dimensioned stay alive for the lifetime of the object.
In contrast, Variables dimensioned in the script section are destroyed between calls to the Object's
script. In either case, dimensioned variables are only accessible from within the script. Other
scripts cannot access those variables. Also, there is no means to expose those variables as
attributes of the associated object (e.g., for debugging purposes). To expose these member
variables, they can be set to a UDA.
Due to this tight link between scripts and UDAs, a script has more open access to UDAs (of the
object that the script is attached to) than to any other attribute on the object. It could be said that
UDAs are owned by a script
A script can also leverage UDAs to persist values across different script runs. Therefore, UDAs
allow users that do not want to get exposed to the complexity of script member variables to still
mimic static variables for data types that fit into Application Server attributes.
Reference Strings
Reference strings refer to an object or to data within an object's attributes. A reference string
consists of an object's reference string plus an attribute's reference string.
Automationobject Reference + Attribute Reference
A reference string is the object name plus the attribute name: ObjectName .AttributeName.
T I C ~ is
O the
~ Automationobject reference and PV is the attribute reference.
In T I C ~ O IPV
.
The AttributeName can be omitted in a reference string, PV being assumed in such cases.
Note: Some obiects have a PV attribute, while others do not.
Reference strings are concatenated substrings, each no more than 32 characters separated by
periods. A substring cannot contain a period. Mathematical operator characters are not allowed. At
least one character in each substring must be non-numeric.
Note: The Galaxy resolves reference strings. If the GR is not available, resolution is done on a
peer-to-peer level. Afler initial resolution, an object is provided an alias that handles references to
its location across your network. If an object is relocated or renamed, the reference string
resolution is repeated and a new alias provided.
Wondeware Training
Section 3 -Introduction to QuickScriwt .NET

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 ihat refer to the current object:
e
Me
MyContainer
Myplatform
MyEngine
MyArea
Relative references are especially useful in templates because absolute references typically do
not apply or make sense.
When you use relative references, like MyContainer, you can refer to contained objects within that
container. For example, a reference to MyContainer. Inletvalue. PV is equivalent to
~ a n k .lInletvalve. 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
Wondeware System Plafform 3.0 Course -Par! 1
4-21
4-22

Scripts Page
The Scripts page has six areas.
n data5omrce
taSonrcr
Wonderware Training
lu String:
~~lnConsrol.raenaxc.I"i Srrmgiiigbr(We.Ta'~'~'~'J,
3):
Section 3 - Introduction to QuickScriwt .NET

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

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

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

For internal attributes the syntax: me. + <fully qualified local part of the attribute reference> needs
to be specified.
Example:
If me. PV=="Open" Then
[ D o something]
Endif;
Script Examples
The following script examples may be used for reference,
Wondeware Training
Section 3
- Introduction to Quickscript .NET
Note: Many aadjr ona scr pr examples may be localeo in me ArchesrrA IDE He p files under
Enhancing an Object's FunctionalitylQuickScript .NET Scripting LanguageISample 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/bo0k[@isbn=~O44023722X']/title'~);
LogMessage(node.InnerText);
' find all titles written by Grisham

for each node in doc.SelectNodes("/catalog/book~author/lastName=~G~isham'l/
title")
LogMessage(node.InnerText);
next;
Query a SQL Server Database

dim connection as System.Data.SqlClient.Sq1Connection;
dim command as System.Data.SqlClient.SqlComand;
dim reader as System.Data.SqlClient.Sq1DataReader;
connection = new
System.Data.SqlClient.SqlConnection("server=(local);uid=sa;database=northwin
d") ;
connection .Open ( ) ;
command = new System.Data.SqlClient.SqlCornand("select * from customers",
connection);
reader = command.ExecuteReader0;
while reader.Read0
LogMessage (reader("CompanyNameee
) ) ;
endwhile;
reader.Close 0 ;
cannectian.Close 0 ;
Create a Look-up Table, Then Do a Look-up on it

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

WWPoke("excel", "sheetl", "rlcl", "Hello");
WRequest ("excel", "sheetl", "rlcl", me.Greeting) ;
Note: use " " to embed double quotes in strings
WWExecute("excel", "sheetl",
"[SELECT (""RlCl"")I [FONT.PROPERTIES(, ""Bold"")I");
Specifying External Attributes
..-
The script developer can specify external attributes in two distinct ways:
Wondeware Sysfem Plafform 3.0 Course -Pad 1
4-25
4-26

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

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

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

First the user has to specify an alias for an external reference (e.g., PVoflnletValve) 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
..........
..
PVof nletvalve
.
.
.
-. .... -. .
7-
Reference
. . .
Va ve101 PV
.
The Alias field is filled in automatically as the script text is parsed

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

So far you mainly focused on the typical case when access to the Value property of an attribute is
needed: i.e.. the property part of a reference can be omitted. In the rare case when the script
developer needs to access properties other than the value property, a dedicated reference is
needed for every property.
Example: Let's assume you need to read the Value property and the UpperBoundDimensionl
property of the external attribute ValvelOl.PV. Let's further assume that you want to use inline
references. The corresponding code snippet is:
A = ValvelOl.PV; [reads the Value property)
B = ValvelOl.PV~.UpperBoundDimensionl
[reads the UpperBoundDimensionl property]
The two references valve101 . Pv and Valvel0l. pv.upperBoundDimension1 are treated

as two completely different references.
Note: Even though the two references valvel01. PV and valvel01. 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:
To get an entire array, either of the following syntaxes works:
Wondenvare System Plafform 3.0 Course -Pad ?
4-27
4-28
Script Execution Configuration

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

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

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

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

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

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

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

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

Script Trigger - While False
While a user configured expression evaluates FALSE.
A time interval is also specified. If non-zero, then at the time interval specified, the configured
expression is evaluated to determine if the script is to be executed. A time interval of zero
renders the time interval unused and causes the expression to be evaluated at the AppEngine
scan period.
Execution Mode
OnExecute() mode scripts can be configured to execute in one of two execution modes,
synchronous or asynchronous. All other script types are always synchronous and cannot be
configured otherwise.
Synchronous Execution
The synchronous mode is the default choice and represents serial script execution by the
ApplicationEngine in the course of calling the Execute method of all Applicationobjects that are
on-scan in the ApplicationEngine. For satisfactory determinism, this mode requires that all scripts
execute deterministically and quickly enough to prevent an ApplicationEngine over-scan condition.
Asynchronous Execution
The asynchronous mode is used for the class of scripts that perform operations that 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 ArchestrATUattributes via normal
geffset 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 geffset request. This is OK since
asynchronous thread is usually slower and background in nature.
Asynchronous Scripts Only Apply to Execute()

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

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

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

The hosting engine creates a pool of worker threads at startup time. These threads are used for
processing asynchronous scripts simultaneously when they are due and their trigger condition is
4-29
4-30
Module 4
- Extending the Objects
true. Only one script can execute on one thread at a time. If an asynchronous script comes due
and no worker thread is available, it is immediately queued for execution and awaits a free worker
thread. As soon as the worker thread is free from its previous script, it executes the newly queue
script.
A default number of worker threads is to be provided. This is a configurable attribute of the Engine.
Taking an Object w/ Asynchronous Scripts OffScan

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

Asynchronous scripts require some additional attributes within the script to provide the following
behavior:
Kill attribute -terminates the asynchronous script when written to.
Shutdown attribute - simply a Boolean flag that requests the asynchronous script to shut
down on its own. A well-written script will check this command before and after timeconsuming operations.
Running indicator attribute - indicates whether the asynchronous script is currently
executing.
e
Elapsed time attribute - indicates the amount of time the asynchronous script has been
executing (if RunningFlag is true).
e
Asynchronous scripts also have the following diagnostic attribute within the engine:
e
Count of asynchronous scripts running - indicates the number of asynchronous scripts
currently executing.
Count of asynchronous scripts waiting - indicates the number of asynchronous scripts
currently queued to execute.
Watchdog Timeout
The execution time of both synchronous as well as asynchronous mode scripts is monitored
against a timeout period. All synchronous scripts on an AppEngine share the same timeout period
which is exposed as a configurable attribute of the AppEngine.
In the case of asynchronous scripts a timeout period that is shared for all asynchronous scripts
does not make sense since the needed execution time can vary by orders of magnitude between
different asynchronous scripts. In order to account for this, the timeout period can be separately
configured for each asynchronous script. It is exposed as an attribute of the script.
Attribute Access Support

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

PID.SetPoint=50
PIO.Mode=Cascade
This script will work independent of whether the PID object resides on the same AppEngine that
the script is executing on (on-engine) or not (off-engine). Each set operation is immediately
executed. If the PID object is on-engine then the set operation changes the value of the
corresponding attribute right away.
If the PID object is off-engine then all set operations are queued up in exactly the order they were
issued and are executed at the end of the scan cycle of the AppEngine (asynchronous set).
'Get' operations work accordingly. Let's consider the following script code snippet:
(For t h i s example
you assume t h a t
If PID.SetPoint==30
PID,SetPoint==30
at
the s t a r t of the
script)
then
PIO.Mode=Auto
PID.SetPoint=SO
PID.Mode=Cascade
Endif;
IfPID.SetPoint==50 then
(Do s o m e t h i n g else1
Endif;
If the PID object exists and its SetPoint can be set to 50 then the second 'if' statement will always
evaluate to true if the PID object is on-engine. However, in the off-engine case both 'if' statements
will never evaluate to true in the same execution cycle of the script.
In other words, when a script performs an attribute set (write) operation followed, at a later point in
the script, by a read of the Same attribute, the value written will not be read back if the attribute is
off-engine, rather the attribute value existing when the script commenced execution is returned
instead. In this case, the value written to the attribute will not be returned by a get (read) operation
until succeeding execution scans of the script.
Notes:
As described above a script performing read Iwrite operations on the same attribute will
behave differently depending on whether the attribute is on-engine or off-engine. If
necessary, the script developer can avoid this situation by using a local script variable to
manage the attribute's value in the course of the script's execution. At the end of the
script, the value of the local variable is then written to the attribute.
Scripts attached to an ApplicationObject are part of the supervisory control logic. Le., read
and write operations performed by the script are treated as S ~ p e ~ i s o r y G eI
t sSets.
On-Engine Attribute Access

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

When a script accesses an off-engine AutomationObject attribute, the Local Message Exchange1
Network Message Exchange (LMXINMX) sub-system is the provider of the attribute data. In this
case, LMXINMX establishes a subscription forthe attribute's value and maintains the most
recently published value in an on-engine read-only.cache. When a script reads an off-engine
Automationobject attribute, the LMX cache's most recently published value is provided to the
script. This value will not change during the execution scan of the script.
Wondenvare System Platform 3.0 Course - Part 1
4-31
4-32

When a script performs a write to an off-engine AutomationObject attribute, LMXINMX performs
the operation asynchronously to the script's operation. If a script reads the same attribute that it
wrote to at a previous point in the script, the script will not see the value previously written until a
succeeding script execution scan cycle. Any errors encountered by LMXINMX during the
asynchronous write operation are not available to the script during the same execution scan but
will be reported in the attribute's WriteStatus field upon status receipt from LMNNMX. Until this
status is received from LMXINMX, the WriteStatus field will report a pending status.
Access to Hosting Object's Attributes

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

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

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

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

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

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

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

Only referenced attributes expose quality. Local variables do not have a quality assigned. I.e.,
when assigning the value of an attribute to a local variable the quality information is lost.
Example: The following code snippet assumes that A and B are local variables of appropriate data
type.
A = ValvelOl.PV
( T h e value of A is now the value o f ValvelOl.PV.Value. The actual name of the
Value property i s spelled out for clarity purposes. The variable A just holds
the value, not the quality.)
B = ValvelOl.PV.Quality
[Another variable can be used t o hold t h e quality information but no local
variable i s able t o hold the value and the quality information.)
Wonderware System Platform 3.0 Course Parf I
4-33
4-34

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

For Script Functions the in and out parameters as well as a potential return value have no
associated quality information. E.g., a Script Function for calculating the square root of a float
value might have a signature like this:
float Sqrt(float Invalue)
If an attribute reference is passedin 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
(ValvelOl.PV.Quality == 192) Or
ValvelOl.PV.Quality == 0) Then ...
Or to use the quality check functions as follows:

I f IsGood(ValvelOl.PV) O r
IsBad(ValvelO1 .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 (ValvelOl.PV
== "Closed") And
(Valve102.PV == "Closed") Then
Set Valvel03.Cmd = "Open"
Else
Set Valvel03.Cmd = "Close"
(This should be the fail safe mode)
Endif;
If the quality of ValvelOl.PV and Valvel02.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.
Wondeware Training
.-

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

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(TanklOl.Leve1)
PID4.SP = PID2.SP
A
( A is a l o c a l v a r i a b l e )
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.
Numerical Comparisons and NaNs (>, <=, >, >=)

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

When the script execution engine experiences a script execution error the 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:
e
When a script execution abort occurs, the script just stops. Sometimes it might be
necessary to set the quality of some UDAs that are controlled by the aborted script to bad.
The user can accomplish this by exercising a second script that monitors the abortion of
the first script.
Failed writes constitute a normal behavior that does not constitute an alarm.
Example: A script constantly tunes the parameters of a PID loop which is typically in
control mode. However, every time when a shift changes, the PID object is set to manual
mode for a short period of time. Now the writes fail but the script just keeps going and
eventually a script run will again successfully be able to set the PID parameters.
Of course it is also possible to check the Writestatus from within the script and react accordingly.
Alarm Type Errors
Watchdog T i m e o u t Error
To prevent the possibility that a script can cause an overrun of the ApplicationEngine scan cycle
(e.g., by running in an infinite loop), a script is aborted after the timeout period for the script has
elapsed. The script execution infrastructure will clean up after the aborted script as best as
possible. E.g., the script infrastructure must attempt to release external objects or data base
4-35

connections that were created by the script. However, it can never be guaranteed that an aborted
script has no negative side effects. E.g., the script could have started to manipulate data base
entries and could leave some table entries in an inconsistent state.
All synchronous mode scripts will be subject to the same timeout period, which is exposed as an
attribute on the AppEngine.
The script developer will be required to configure the timeout period for each Asynchronous mode
script in order to provide flexibility in accommodating the potentially time consuming operations
that these scripts are intended for.
O v e r f l o w Error
A script experiences an overflow condition. Overflow conditions not only apply to analog data
types (integer float) but also other data types (e.g., string length overflow).
D i v i s i o n b y 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 + m and - m and also NaN (Not a Number).
Net Call Execution E r r o r s
If a script encounters an exception during call of a .NET function call, the error will be caught and
an error message (in red) will be logged to the logger. In addition, the execution alarm Boolean
condition is raised in this case.
Pre-Installed Binary Libraries

As part of the scripting environment a single binary library is shipped. This library provides
functionality to support both generic scripting tasks and tasks requiring access to specialized
portions of Application Server
e
Math functions: Includes functions like Abs, Sin, Sqrt, etc.

String functions: StringLen, etc.
System functions: LogMessage, etc.
I m p o r t i n g Additional B i n a r y Libraries
Script Library Packages can be added to the system and made available to the user like preinstalled script libraries.
Note: Script libraries developed with the InTouch 32-bit Extensibility toolkit can be imported and
converted to Script function Libraries.
E x p o r t i n g B i n a r y 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 6, the script libraries that the object
depends upon need to be manually copied to Galaxy 6.
Wondenvare Training
Section 3 - Introduction to QuickScript .NET

Script Locking
Locking Scripts in Templates
From an implementation point of view it is much easier to lock both the expression controlling the
execution of an Applicationobject script and the actual script at the same time; i.e., treat both as
one entity. This allows the system to compile both the expression and the script into only one dl1
which makes deployment easier and decreases the overhead carried in each dll.
Typically an expression uses attribute references. If the user wants to lock the expression and the
associated script expression in a template then it is crucial that aliases are used in both the
expression and the script. This allows the user to specify the attributes that the aliases point to on
a per instance basis while the code is locked.
Rules on Locking of Scripts:
e
e
e
e
Script text can be lockedlunlocked in a Template.

When a Script is locked in a Template, the Alias names are automatically locked also. The
Alias References are never locked. Locking of Aliases is not specified separately (it is only
done when the script itself is lockedlunlocked).
The Script expression, trigger type and trigger period are group locked and can be locked
separately from the script text.
When a Script is added to a Template, all properties of the Script are editable.
When a Script is added to an lnstance, all properties of the Script are editable except for
the Lock property (since lock is never editable in an instance).
For a Script added in an lnstance, all properties of the Aliases can be edited except the
Lock (since locks are never editable for instances).
Support for .NET Constructs

QuickScript .NET is built on top of .NET and supports the following .NET constructions in its
syntax:
e
Declaring variables of .NET types.
Calling public constructors (with and without parameters) of .NET types.
e
e
e
e
Calling public instance methods (with and without parameters) of .NET types.
Calling public static methods (with and without parameters) of .NET types.
Calling public indexers (with one or more parameters) of .NET types.
Using .NET enumerations.
Language Definition
QSll Case Sensitivity
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the
case is p r e s e ~ e dthroughout editor sessions.
QSll Comments
Both single line and multi-line comments are supported. Single line comments start at a ' in a
source code line that has no matching ending ' in the line. Multi-line comments start with a (and
end with a ) and can span multiple lines as the name sugge&s.
Wondeware System Plafiorm 3.0 Course - Par/ f
4-37
4-38

Examples:
Dim A; 'This is a single line comment
Dim B; {This is an example of a multiline comment1
QSll White Space

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

Operation
MOD
Description
Muittpl~cat~on
D~v~s~on
Addlt~onand Concatenation
Subtractm
Assignment
Modulo
/ SHL
/ Lefl Shifl
SHR
/ Right Shift
&
I Bitwise AND
/ Exclusive OR
inclusive OR
Pnwer
1 Less than
>
<=
1 :1
--
<>
AND
OR
/ Greater than
/ Less than or Equal to
1 Greater than or Equal to

/ Equivalencv. Cis
. equivalent to")
/ Not Equal to
/ Logical AND
I Logical OR
QSll Precedence of Operators

The following list shows the order of precedence for evaluation of operators. The rirst 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.
..-
Wondeware Training

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

Each variable must be declared within the script by a separate DIM statement followed by a
semicolon The DIM statement syntax is as follows:
DIM <variable-name>
1 [ A S <data-type>
<upper-bound>
1, <upper-bound >I, < upper-bound
>I1
I;
where
variable-name : : = <letter> I <letter> I <digit> i <special-character> )
letter : : = A-Z I a-z
digit ::= 0-9
special-character : : = upper-bound : : = 1-2,147,483,647
data-type : : = Boolean I Discrete I Integer I Float I Real i Double I String
Message I Time I Object
The variable name is limited to 255 Unicode characters. Note that, in contrast to attribute names,
variable names must not contain dots. Variable names and the data type identifiers are not case
sensitive. If there is a naming conflict between a declared variable and another named entity in the
script (attribute name, alias, name of an object leveraged by the script), the variable name takes
precedence over the other named entities.
For example, let's assume that your script accesses the hosting object's PV attribute in the script
text and you declare 'DIM PV AS Integer;'. Within the declaring script, expressions using 'PV' in a
Wonderware Syslem Plafform 3.0 Course - Pad I
4-39
4-40

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
lnteger (as in QuickScript).
The following table shows how the QuickScript .NET data types map to C++ data types. The
default value column defines which value the variable takes on when it is defined (before another
value is assigned).
Integer
long (4 bytes)
Float. Real
*__
float (4 bytes)
7
Double
String, Message
NaN
I
,,,,
Double (8 bytes)
BSTR
Based on .NET'S
SystemDateTime
(8 bytes)
.-
Object
Nothing
Based on .NET'S
System.TimeSpan
structure (8 bytes)
Dispatch pointer
Discrete is still supported for migration

from InTouch.
True=l, False=O
Signed
-2147483648to2147483647
Float and Real are synonymous. Real is
still supported for migration from InTouch.
For range information please refer to
Appendix
For range information please refer to
Appendix
Maximum length defined by BSTR
(2147483647)
Resolution is 100 nanoseconds, used to
reflect an absolute date / time the content
reflects the number of 100-nanosecond
intervals since 00:OO January 1.0001.
100 nanosecond ticks represents a time
span.
Leveraged for accessing OLE
Automation servers.
Mapping of Application Server Attribute Data Types to QuickScript .NET

Data Types
Application Sewer data types are mapped to QuickScript .NET variable data types according to
the following table.
Wondeware Training

.........
.....
.....
QuickScript
Application Sewer Data Type
.NET Data
Type
.................
Boolean or
Discrete
Mxlnteger
Integer
MxFloat
Float or Real
MxDouble
Double
MxString
String or
Message
.........
......
Comments
.-
---
In Application Server, there is no fixed upper limit

on string length.
These strings are read-only at runtime. If script
tries to write at runtime the write will fail at
runtime with appropriate status.
The filetime content of MxTime is mapped to
Time.DateTime of the QuickScript .NET data
type. The Application Server internal
representation is based on 1601, whereas the
Script internal representation is based on 0001
(consistent with .NET system).
The time zone offset of MxTime is mapped to
Time.TimeZoneOffset.
TimeDateTime is a .NET DateTime.
Time.TimeZone0ffset is an integer.
Same definition
Onlv the strina content of the attribute is used.
y pre-oo~ndDs are throun away
Tne
potent al.
...
-
MxStatusType
Integer
One of tne nleger valJes I sted in secuon hole,

that only the status category is exposed. The
status detail is not accessible form within a script.
One of the integer values listed in section.
One of the integer values listed in section.
One of the integer values listed in the OPC Spec.
'Data Access Custom Interface Standard'. The
user can also write this (but only my attributes.
not external attributes). For example, to set the
quality of MyAttr to Good
Object.MyAttr.Quality=192. Note that access to
Quality is purely an OPC quality operation.
To access Application Server's 4 basic quality
states (Good, Bad, Uncertain, Initializing), the
user can use functions lsGood(). M a d ( ) ,
Isuncertain(), Islnitializing(). This will allow tests
like
if (IsGood(Obj.Attr.Qstring)
Additionally, the user can set the quality using
functions SetGood(). SetBad(), Setuncertain(),
Setlnitializing(); for example:
SetBad(TIC101. P V l
Wonderware Syslem Plalform 3.0 Course - Par/ l
4-41
4-42

..
..
Quickscript
, .NET Data
Zpplication Server Data Type

. ..
dxQ~al~fiedEn~m
. ..
i
. ..
...
/ Comments
Type. . . . .'-Iintegcr
or
String
.
.-.
.
.. Anroutcs of type m x Q a ftedEn-m can bc read I
set as an integer or a string.
Example:
Dim intV1-PV as Integer;
Dim strVl_PV as String;
intV1-PV = Valve101.PV:
( Now intV1-PV holds the ordinal value of the
qualified enumeration )
strV1-PV = ValvelOl.PV:
I Now strVl PV holds the strino value of the
qualified enumeration )
The data type MxQualifiedStruct is not directly

maooed
to a QuickScriot .NET variable data
,
type. Instead, functionsare provided that allow
the script developer to map parts of the qualified
struct to native script data types.
Example (the actual name and siqnature
rniaht
.
change):
Tolnteger(<QualifiedStruct>,StartByte)
which expects an attribute of data type
mx~ualified~truct
and a number of-thefirst byte
that makes uo a 4 bvte inteoer. It returns a
regular integer.
QSll Numbers and String

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

lntegers constants in decimal defined as
Integerconst ::=
[sign] won-zero-digit>
I
sign ::=
<digit>*
+I-
non-zero-digit ::= 1-9

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

Prepending either Ox or OX causes a literal integer constant to be interpreted as being in
hexadecimal notation. In this case the sign is not supported.
Wondenvare Training

IntegerHexConst ::=
<O><x I X> <hexdigit>'
hexdigit ::= 0-9, A-F, a-f
When entering a hexadecimal number, only 8 hexdigits (32-bits) are allowed.
Floats
Float constants are applicable as values for variables of type float 1 real or double. I.e., float
constants do not take the number of bytes into account. It is up the validation step of the script
(lexer 1 parser) to detect an overflow when too big a float constant is assigned to either a variable
of type float I real or double.
sign ::= + I
digit ::= 0 - 9
exponent ::= exponent-character [sign] <digits>+
exponent-character ::= e 1 E
Sign is either plus (+) or minus (-); and digits are one or more decimal digits. If no digits appear
before the radix character (.), at least one must appear after the radix character. The decimal digits
can be followed by an exponent, which consists of an introductory letter (e or E) and an optionally
signed integer. If neither an exponent part nor a radix character appears, a radix character is
assumed to follow the last digit in the string.
Please note that the allowed range depends on the data type (4 byte float I real versus 8 byte
double) of the variable that the value is assigned to.
String Literals
String literals need to be surrounded by double quotes. They are referred to as quoted strings
Within the quoted string the character 'Y can be used as an escape character. The following
escape characters are supported:
..............
....1 Escape
-Sequence
/ \n
\r
\t
--
............
Description
.....
I New line
..............
.....
I Carriage return
Horizontal tab
Sinale atiotation mark. Sinale Quotes can
alsodirktly be used in a siring' without
using the escape sequence.
I Double auotation mark
/
\"
--
I formed bv the hexadecimal number xxxx. /

E.g. '\u0d6~'is the letter 'f. 4 digits a&
required.
Wondenvare Svslem Platform 3.0 Course -Par/ I
4-43
4-44

.. ~ .
r---
, Escapesequence
. . . . - --.
/ \Uxxxxxxxx
....-- -
..
/Descnpiion
...
I Represents single Unicode character
formed by the hexadecimal number
xxxxxxxx. E.g. '\u00000066' is the letter'f'.
-1I
QSll Control Structures

Quickscript .NET provides four primary control structures in the scripting environment:
e
IF ... THEN ... ELSEIF ... ELSE ... ENDlF

FOR ... TO ... STEP ... NEXT Loop
FOR EACH ... IN ... NEXT
WHILE Loop
IF ... THEN ... ELSEIF ... ELSE ... ENDIF

The IF-THEN-ELSE-ENDIF statement is used to conditionally execute various instructions based
on the state of an expression. The syntax is as follows:
IF <boolean-expression>
THEN
[statements]
[ { ELSEIF
[statements] } ]
[ ELSE
[statements] ]
ENDIF;
Where
boolean-expression is an expression that can be evaluated as a Boolean. Dependent on
the data type returned by the expression the expression is evaluated to constitute a True
or False state according to the following table:
........
1 Z X Z w-c r e t e
.
---.
........
. . . . . . . l Mapping
. . .-.-..-- ....
.
D red .y used
(no. mappang
needed)
.
Integer
Float, Real
String. Message
I
Time
/
Wondeware Training
Value = 0 evaluated as False

Value != 0 evaluated as True
Value = 0 evaluated as False
Cannot be mapped. Using an expression
that results in a string type as the
boolean expression results in a scriDt
validation eiror.
Cannot be mapped. Using an expression
that results in a time type
.. as the
boolean expression results in a script
validation error.
/ Mapping
I Cannot be mapped Usmg an expression
Data Type
Object
that results in an object type as the

boolean~expression
results in a script
validation error.
The first block of statements is executed if boolean-expression evaluates to True. Optionally a
second block of statements can be defined after the keyword ELSE. This block is executed if the
boolean-expression evaluates to False. In order to facilitate deciding between multiple
alternatives an optional ELSEIF clause can be used as often as needed. The ELSEIF clause
allows for easy mimicking of switch statements offered by some other programming languages.
Example:
If
value = 0
Message =
Then
"Value
i s zero";
E l s e I f v a l u e > 0 Then
Message = " V a l u e is p o s i t i v e " ;
value < 0 t h e n
Message = " V a l u e i s negative";
ElseIf
Else
( D e f a u l t . Should never
occur
in t h i s example)
For consistency with InTouch Scripting, the following syntax is also supported:
IF <boolean-expression> THEN
[statements]
[ { ELSE IF
[statements] ) ]
ELSE
[statements] ]
ENDIF;
ENDIF;
This approach basically nests a brand new IF compound statement within a previous one and
requires an additional ENDIF.
FOR ... TO
... STEP ... NEXT Loop
A FOR-NEXT loop is used to perform a function (or set of functions) within a script several times
during a single execution of a script. The general format of the FOR-NEXT loop is as follows:
FOR <analog-var> = <start-expression> TO <end-expression> [STEP
<change-expression>]
[statements]
[EXIT FOR;]
[statements]
NEXT
Wonderware Syslem Plalform 3.0 Course -Pad 1
4-45
4-46
Where:
e
analog-var is a variable of type Integer, Float, Real, or Double.

startexpression is a valid expression, to initialize analog-var to a value for execution of
the loop.
end-expression is a valid expression. If analog-var is greater than end-expression,
execution of the script jumps to the statement immediately following the NEXT statement.
(This holds true if loop is incrementing up, otherwise, if loop is decrementing, loop
termination will occur if analog-var is less than end-expression.)
change-expression is an expression, to define the increment or decrement value of
analog-var after execution of the NEXT statement. The change-expression can be either
positive or negative. If change-expression is positive, start-expression must be less than
or equal to end-expression or the statements in the loop will not execute. If
change-expression is negative, start-expression must be greater than or equal to
end-expression for the body of the loop to be executed. If STEP is not set, then
change-expression defaults to 1.
It is possible to exit the loop from within the body of the loop via the EXlT FOR statement.
The FOR loop is executed as follows:
1.
analog-var is set equal to sta~expression
2. The system tests to see if analog-var is greater than end-expression. If so, the loop exits. (If
change-expression is negative, the system tests to see if analog-var is less than
end-expression.)
3. The statements in the body of the loop are executed. Here the loop can potentially be exited
via the EXlT FOR statement.
4. analog-var is incremented by 1 - o r by change-expression if it is specified

5.
Steps 2 through 4 are repeated,
Note: FOR-NEXT loops may be nested. The number of levels of nesting possible depends on the
memory and resource availability.
FOR EACH
... IN ... NEXT
The FOR EACH loop can only be used with collections exposed by OLE Automation servers .A
FOR-NEXT loop is used to perform a function (or set of functions) within a script several times
during a single execution of a script. The general format of the FOR-NEXT loop is as follows:
FOR EACH <object-variable> IN <collection-object >
[statements]
[EXIT FOR;]
[statements]
NEXT;
Where:
e
object-variable is a variable of type <some COM interface>

collection-object is a variable holding a collection object.
As in the case of the FOR ... TO loop it is again possible to exit the execution of the loop via the
statement 'EXIT FOR;' from within the loop.
Wondeware Training
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
Windowsa system via collections.
Example:
Dim
Dim
Dim
Dim
Dim
fso As IFileSystem;
folder As IFolder;
fileCollectian As IFileCollection;
file As IFile;
fileName as String;
so = new FileSystemObject;
folder = fso.GetFalder("C:\Temp");
fileCollection = folder.Files;
For Each file In fileCollection
fileName = file.name;
Next;
FOR EACH will allow for looping through arrays
WHlLE Loop
A WHlLE 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 WHlLE loop is as
follows:
WHlLE <boolean-expression>
[statements]
[EXIT WHILE;]
[statements]
ENDWHILE;
Where:
e
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 EXlT WHlLE 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 EXlT WHlLE statement.
3.
Steps 1 through 2 are repeated,
Note: WHlLE loops may be nested. The number of levels of nesting possible depends on the
memory and resource availability.
Support for Script Functions

n
I,
order to follow the naming syntax of InTouch QuickScript, binary shared functions are referred to
as script functions. Functions written in QuickScript are named QuickFunctions.
Wonderware System Platform 3.0Course -Part 7
4-47
4-48

Accessing Script Functions
Script functions can be directly accessed from within the script code. The syntax is exactly like in
Quickscript.
Example:
PumpState
StringRight("The Pump is On", 2 ) ;
Where StringRight is a binary script function as described in the Scripting DFS. After executing the
script snippet PumpState holds the value "On".
Any of the script functions provided by The Application Server can be invoked this way.
Syntax:
ScriptFunction ::= <FunctionName> ( {cParamater>) {"." <Paramater>) );
OLE Automation Support

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

e
Support for GeVSet Property
Support for method invocation on COM sewer
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 t o the variables. Use
Add methods t o 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.
Wondenvare Training

1. New keyword -this keyword instructs the script to create a new .NET object. ActiveX
components that have been imported into the Galaxy Repository explicitly end up with .NET
wrappers that allow them to be created using this technique. In the example below, earlybound methods on
Dim app as Excel.Application;
App = new Excel.Application;
2. Createobject method -this method instructs the script to specifically create a named COM
object that is installed on the system upon which the script is to be deployed. These are latebound objects. Late-bound methods on app can be called after the object is created.
dim app as object;
app = CreateObject("Excel.Application");
Scripting Key Words and Reserved Words

This section identifies key words and reserved words that are used in scripting.
... -.....
Keywords
,.........
and
as
attribute
boolean
din
discrete
double
each
/ elaosedtime
else
elseif
endif
kdwhile
/
/
/
/
exit
false
float
for
if
in
indirect
integer
messaae
mod
new
next
not
.............................
---
null
object
or
real
shl
shr
/ step
string
/ then
/time
to
/ true
/w e
Wondewwe System Platform 3.0 Course - Pad 1
4-49
4-50

lndirect Keyword
The lndirect keyword supports dynamically binding a variable to an arbitrary reference string for
getlset 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;
...
Note: The Attribute() keyword does not accept values as a parameter. If you need to use dynamic
references to an attribute value, use lndirect instead.
Quickscript .NET also reserves for future use the following words:
call
case
catch
class
continue
default
delegate
do
end
I endsub
endswitch
enum
error
/ function
/ goto
this
namespace
/ nothing
implicit
1 throw
on
triger
private
protected
public
raiseevent
readonly
ref
return
select
sizeof
typeof
until
using
virtual
void
when
with
Wondeware Training
imports
include
inherits
interface
internal
1 is
like
Me
MyArea
Lab 13 -
uiteLinkCIient Auto
econnect
Introduction
Since the $DDESuiteLinkClient object lacks the capability to automatically reconnect to the data
source if the connection is lost, you are to extend the object with UDAs and scripts to add such
functionality.
Note: Your instructor will demonstrate the scrid.
Objectives
Use the QuickScript.NET scripting engine to extend your objects with extra functionality
e
Use attributes, including UDAs, within scripts
e
Create scripts with different execution types
e
Reconnect whenever the Incontrol object gets disconnected

Add the auto-reconnect functionality

1. Add a script called Reconnect (locked) to the $ABDDESuiteLinkClient 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;
2. Add a Calculated Integer UDA named DisconnectCnt.
Wondeware System Plafform 3.0 Course - Part 1
4-51
4-52

3. 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;
4. Deploy the Incontrol object,
Wonderware Training

Add the Auto-reconnect Functionality

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

and configure it as follows:
to add a new script to the object. Name the script Reconnect
Aliases section:
(locked)
Declarations section:
(locked)
Scripts section:
Execution type:
Execute (locked)
Basics section:
(locked)
Expression:
Me.ConnectionStatus o 2
Trigger type:
WhileTrue
Trigger period:
00:00:05.0000000
Script body section:

Me.Reconnect = True;
3.
Select the UDAs tab
.*-
Wondenvare System Platlorm 3.0 Course - Pail 1
4-53
4-54

Data type:
Integer
Category:
Calculated
to add a UDA to the object. Name the UDA DisconnectCnt
5. Select the Scripts tab

to add a new script to the object. Name the script
DisconnectMonitor and configure it as follows:
Aliases section:
(locked)
(locked)
Scripts section:
Execution type:
Execute (locked)
Basics section:
(locked)
Expression:
Me.ConnectionStatus o 2
Trigger type:
OnTrue

Me.DisconnectCnt = Me.DisconnectCnt
Wondemare Training
1;

With the DisconnectMonitor script selected, specify an Execution type of OnScan to add a
second section to the script. Configure it as follows:
Me.DisconnectCnt = 0;
Deploy the Incontrol instance

Note: Your instructor will demonstrate new attributes in Object Viewer.
Wonderware System Platform 3.0 Course - Pati 1
4-55
4-56
Wonderware Training
Lab 14 - A u t o m a t i c Reference Configuration
Lab 14 - Automatic
eference
onfiguration
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 $ABMixer template
is named with the valid three-digit mixer identification number at the end as identified in Lab 2.
Objectives

Use the QuickScript.NET scripting engine to automatically configure on runtime the input
and output references of instances

Add t h e auto-configuration functionality

1. Add a Boolean User writeable UDA to the $ABMixer template, name it AssignlOCmd and
set its initial value to True.
2. Add a script called Assign10 (locked) with an Execute execution type configured as follows:
Expression:
Me.AssignlOCmd
Trigger type:
WhileTrue
Trigger period:
00:00:00.0000000
Script body:
(provided as a text file as part of the training material)
Wonderware Sysfem Plafiorm 3.0 Course - PaIi 1
4-57
4-58

Create and deploy a Mixer instance
3. Create a new instance of the $ABMixer template, name it A B M i x e r - W a n d assign it to the

ABLine2 area.
4. Deploy both, the new mixer instance and ABMixer-001
Wondeware Training

Following are Detailed Lab lnstructions for completing this lab. For a summaw of instructions,
Add the Auto-configuration Functionality

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


to add a UDA to the object. Name the UDA AssignlOCmd
Data type:
Boolean
Category:
User writeable
TruelFalse:
checked
iiLjllij UDA name:
3.
AnbnIOCmd
Select the Scripts tab
Wonderware Syslem Plalform 3.0 Course - Pail1
4-59
4-60
to add a new script to the object. Name the script Assign10

Aliases section:
(locked)
(locked)
Scripts section:
Execution type:
Execute (locked)
Basics section:
(locked)
Expression:
Me.AssignlOCmd
Trigger type:
WhileTrue
Trigger period:
OO:OO:OO.OOOOOOO

'Get the common part for the references.
Dim dataSource As String;
datasource = "1nControl.tagname.T" + StringRight(Me.Tagname, 31;
'Configure inlet valve 1.
Me.Inletl.CLS.1np~tSource = datasource + "-IV1-CLS";
Me.Inletl.OLS.1nputSource = datasource t "-IV1-OLS";
Me.Inletl.CmdOpen.OutputDest = datasource + "-IV1-CmdOpen";
'Configure inlet valve 2.
Me.Inlet2.CLS.InputSource = datasource + "-IV2-CLS";
Me.Inlet2.OLS.InputSource = datasource t "_IV2_0LS";
Me.Inlet2.CmdOpen.OutputDest = datasource t "-IV2-CmdOpen";
'Configure outlet valve.
Me.Outlet.CLS.1nputSource = datasource + "-OV-CLS";
Me.Outlet.OLS.InputSource = datasource + "-OV-OLS";
Me.Outlet.CmdOpen.0utputDest = datasource + "-OV-CmdOpen";
'Configure transfer pump 1.
Me.Pumpl.FlowSwitch.InputSource = datasource + "-TP1-FlowSwitch";
Me.Pumpl.CmdStart.OutputDest = datasource + "-TP1-CmdStart";
'Configure transfer pump 2.
Me.Pump2.FlowSwitch.InputSource = datasource t " TP2-FlowSwitch";
Me.Pump2.CmdStart.OutputDest = datasource + " - ~ ~ ? ~ m d ~ t a r t " ;
'Configure level meter.
Me.LIT.PV.1np~t.InputSource = datasource
'Configure temperature transmitter.

= datasource
Me.TT.PV.Input.InputSource
+ "-LT-PV";
+ "-TT-PV";
'Configure agitator.
Me.Agitator.AuxContact.1nputSource = datasource t "-AG-AuxContact";
Me.Agitator.CmdStart.0utputDest = datasource t "-AG-Cmdstart";
Me.Agitator.Speed.1nputSource = datasource + "-AG-Speed";
Me.Agitator.SpeedSP.1nputSource = datasource + "-AG-SpeedSP";
'Reset trigger.
Me.AssignIOCmd = False;
Wondemaare Training
Wondenvare Svstern Plafforrn 3.0 Course - Pad 1
4-61
4-62

Create and Deploy a Mixer Instance
6. Using the Template Toolbox and the Model view, create an instance of the $ABMixer
template and name it ABMixer-XXY
Assign the instance to the ABLine2 area.

Note: When the mixer instance is renamed, a dialoq box with a warninq is displayed
Click the Yes button.
Note: The new instance of the SABMixer template will display the warning icon on all
contained objects. This is OK. These warnings can be cleared by setting the default
references from ---.---to ---.
I m ~ o r t a n t If
! there is a warnina icon on the mixer instance itself, notifv Your instructor.
& ABoischarpe
8..
& ABlntake
:
&
'
Q aanwto;_ool
& ABProduction
AgitatorJol [Asitat
hletl..OOl [ I n l e t i l
hletZ.OD1 [inlet21
outlet_ool [outlet I
Pump1_001 [Pump1
P"mp2_001 [PompZ:
l"let1_002 [Inlet1 1
l"lti2_002 [Inlet2 1
o"!l~!_oo2 [outlet I
Pump1_002[Pumpl:
Pump2-002 [Pump2
7. Deploy the newly created instance.

8.
Deploy the ABMixer-001 instance.
.*
9. Use Object Viewer to verify that both mixers, and their contained objects, are working.
Wonderware
Training
Alarms and
Section 1 - Alarms
- Historization
Lab 16 - Configuring History
Section 2
5-2
Module 5 -Alarms and History

Module Objective
Obtain an overview and understanding of the concepts of Alarms, Events and
Hislorizat~onand how ArchestrA handles each.
Wondenvare Training
Section 1 -Alarms
Section 1 -Alarms
Section Objectives
Famll~arlzeyou w ~ t hthe concept of alarms and events, and
Enable you to understand how ArchestrA handles alarms and events
This section provides familiarization of the concept of alarms and events and how ArchestrA
handles them.
What is an AlarmlEvent
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 system1
s o h a r e alarms events. Alarms and events are things that occur in the runtime system. Events
and alarms are different and the system distinguishes between the two. An event is simply an
occurrence of a condition at a certain point in time. The system can detect events, store them
historically and report them to various clients. Alarms, on the other hand, represent the
occurrence of a condition that is considered abnormal (generally bad) in nature and requiring
immediate attention from a user. Alarms are a special type of event that indicate something
abnormal has happened. The system handles the real-time reporting of alarms in a special
manner and provides special clients for their viewing.
Examples of alarms include:
A process measurement has exceeded a predefined limit, such as a high temperature
alarm.
e
A process device is not in the desired state, such as a pump that should be running has
stopped.
..
e
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:
e
A plant process has started; for example, a new batch or campaign starts.
The operator has changed a plant operator parameter; for example, a setpoint on a
temperature controller.
e
The system engineer has changed the runtime system configuration; for example,
deployment of a new Automationobject.
* The system engineer has started or stopped a system component; for example, stopping
an engine.
e
A platform has come back online after it had a failure or shutdown.
e
A user has logged into the system.
e
Detection of a severe software problem; such as a failed Application Object component.
The following items are not considered alarms or events:

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

How does ArchestrA handle alarms?
The Platform as an Alarm Provider
A Platform can act as a single Alarm Provider that provides alarms to the InTouch Distributed
Alarm subsystem. A boolean checkbox is provided in the Platform AutornationObject 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
AlarmIEvent Notification Distributors that are running in the subscribed Areas throughout the
Galaxy (inside every Area, Platform, Engine, Dl 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:
1 Timestamp of alarm event

Common message text string.
/ Time
1 Comment
1 Area
I Alarm a r o u ~
1 Common name for alarm primitive I Alarm Type
.. (string)
.
..
(e.g. "PV.HiAlarm")
New alarm state lack. rtn. etc.l
Value MxReference
Limit MxReference
Units MxReference
Category
Category
/ Nla
1
1
1 State
1 Nla
/ Nla
1 Class
/ 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
Wondenvare Training
Section I-Alarms
AutomationObject's acknowledge attribute for the alarm. Security is used as part of this set (it is a
Userseattribute). 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 EnablelDisable
The InTouch Alarm Client can enableldisable 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 Sewer. 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.
Svstem Events:
.............
Distributed Alarm subsystem

Mapping
.. - .
---.
-Calegoryl = Syslem
Type = SYS
. Typc (or
.................
Timestamp
-.-Time
Tagname
Name
Comment
Tag description
Area
Event Type - if string, or use
System event description
Comment field
("started. "stopped)
N/a
Lies,,
fie,,
Priority = 1
N/a
N/A
N/A
Provider = Galaxy
Event Class = EVENT
---
Securitv Audit (includes User Data Change)

--. . ..Events:
.....
. . . . . . . . . . .
ArchestrA field
.
Type = Operator Change

Timestamp
Tag.primitive.attribute
Tag description
Area
View engine name

Mapping
-...
Type = OPR
Time
Name
Comment
Alarm group
-. . . . . . . .
5-5
5-6

Securitv Audit (includes User Data Change)
- . Events: (continued)
..
-.
..
I Operator 1 name
.........
1 Distributed Alarm subsystem
Mapping
... -!..
. . . . . --
Limit
/ value
New value
Nla
State = none (preferred) or

"UNACK R T N
Nla
Priority = 999
NIA
Provider = Galaxy
NIA
Event Class = EVENT
Awwlication Data Change

- Events:
--
.............
........
..
...

Mapping
.......
-
1 .
Type = LGC
Timestamp
Time
Tag.primitive.attribute
Name? Or name+comment?
.....
I old value
..
Nla
Nla
NIA
Wondeware Training
Comment
P!a~m.92Jp
Platform (!he PC's node n
-. -. .
Limit
/ Value
/ State = none (preferred)or
New value
/
--
.-
Type = Data Change
Tag description
. . . .
/ RequestingEngineName+
"UNACK-R T N
Priority = 999
Provider = Galaxy
1
1
Section 1 -Alarms
Alarm Queries
Alarm queries provide alarm information and event reports coming from the galaxy.
Use the following syntax for querying alarms from a Galaxy. This syntax gets alarms from a
specific attribute of an object in a specific area on a specific computer.
\\NodeName\Galaxy!Area+Blyestff#n8ate
The following syntax gets all alarms from a specific area:

$Galaxy!Area
The following syntax gets alarms from two areas:

\\Galaxy!Areal \\Galaxy!Area2
The following syntax gets all alarms from the Platform on computer node (by default):
-+
You can also use a wildcard. The following syntax gets all alarms from Areal, Area2, Area3, and
SO on:
The following syntax gets all alarms from all objects starting with the characters "Tank" in the area
"Area":
Displaying alarmslevents in InTouch

The Current Alarm Display is an ActiveX Control delivered with InTouch. The primary purpose of
the control is to allow an InTouch Operator to view and acknowledge active alarms at runtime that
are generated by alarm providers. Alarm providers can include local providers and providers on
the network. Application Server (ArchestrA) is a key alarm provider. Key functions include:
e
Configuration at design time for subscription to specific alarm providers on the network for
alarm reports. One or more Application Server platforms can be an alarm providers (and
can be local or remote).
Configuration at design time for subscription to specific alarm groups (or areas) in a
provider. Groups (or areas) can be hierarchical, meaning sub-groups are automatically
subscribed to.
e
Display of key alarm information.
e
Acknowledgment of selected alarms with a comment.
Suppression of alarms (local filter only).
5-7
5-8

Event History Display in InTouch
The InTouch AlarmDBView ActiveX is used to display historical alarm and event information that
has been logged by the InTouch Alarm Logger. The InTouch Alarm Logger can be configured to
log alarms from any provider, including Application Server.
Wondewwe Training

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
e
Configure the $Winpiatform object as an alarm provider for the galaxy
e
Configure alarms within objects including using the Alarm Extension
e
Configure and use the Alarm DB Logger Manager
e
Use alarm queries to request real-time alarms from alarm providers

Following is a summaw of the general steps you will complete for this lab. For detailed
Configure t h e WinPlatform object a s a n A l a r m Provider
1. Configure the ABGRPlatForm instance to be an InTouch alarm provider for ail areas in the
galaxy.
Configure t h e $ABMixer.LIT template for alarms

2.
Configure the $ABMixer.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.
.-
3. Lock all level alarms attributes but the Hi Limit
5-9
Module 5 - A l a r m s and History

Configure t h e A l a r m extension
4. Add a Boolean Object writeable UDA to the $ABMixer.Agitator template named
Malfunction.
5. Extend the Malfunction attribute with an Input extension and configure its Source as
6.
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 s c r i p t o n $ABMixer
7. Modify the Assign10 script of the $ABMixer template by adding the following line of code to
the Configure agitator section of the code:
Me.Agitator.Malfunction.1nputSource
datasource
"_AGMalfunction";
View t h e alarm data on R u n t i m e

8.
Deploy the ABGRPlalform object on cascade.
9.
Using the watch list created in Lab 5, add a new watch window called Alarms and add the
e
LIT-001.PV
LIT-001 .lnAlarm
0
.
e
e
e
e
LIT-001 .Hi.lnAlarm
LIT-001.Hi.Limit
LIT~001.Hi.TimeAlarmOn
LIT-001.Hi.TirneAlarmOff
Agitator-001.lnAlarm
Agitator-001 .Malfunction
Agitator-001 .Malfunction.lnAlarm
Agitator~OO1.Malfunction.TimeAlarmOn
Agitator~OO1.Malfunction.TimeAlarmOff
Wondeware Training
Lab 15 -Configuring Alarms

Configure and Start the Alarm DB Logger Manager
11. 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]
12. Configure the Alarm DB Logger Manager to query all priorities from the following alarm
query:
13. Leave the defaults advanced settings and start Alarm DB Logger Manager.
View the Alarm History data

14. Use SQL Sewer Management Studio to query all data from the v-AlarmHistory view,
5-12

Following are Detailed Lab lnstructions for completing this lab. For a summary of instructions,
please refer to the Summary Lab lnstructions on the previous page(+
Configure the WinPlatform Object as an Alarm Provider

1. Double-click the ABGRPlatform 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, "Areal 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.
Wonderware Training

Configure the $ABMixer.LIT Template for Alarms
4.
Double-click the $ABMixer.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.
Wonderware System Platform 3.0Course - P a d 1
5-13
5-14

Configure the Alarm Extension
7. Double-click the $ABMixer.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
urnname:
m:
9.
Naiiuntbon
~~t~
We"
Categoq:
I0bjert.a~iteab:e
id
.-14
10. Select the Malfunction attribute and configure its extensions as follows:
Input extension:
Source:
Alarm extension:
checked
-..
checked (locked)
Category:
Process
Priority:
500
Alarm message:
me.ShortDesc
Active alarm state:
True
Wondeware Training

Update Auto-configuration Script on $ABMixer

12. Double-click the SABMixer template to open its configuration editor.
Select the Scripts tab.
13. Select the Assign10 tab and add the following line of code to the Configure agitator section of
the code:
Me.Agitator.Malfunction.InputSource
datasource +"-AG-~alfunction";
Wondeware System Plalform 3.0 Course Pad 1
5-15

View the Alarm Data in Runtime
15. Deploy the ABGRPlalform object on cascade.
16. Open Object Viewer by right-clicking the LIT-001 instance and selecting View in Object
Viewer. If you closed Object Viewer before, you can use File I Load Watch List to open the
file you saved earlier.
Note: If you had Object Viewer opened, you will need to switch to it first and click the OK
button to close before trying to re-opened again from the ArchestrA IDE.
rename the watch list to Alarms.
Wonderware Training
Lab 15 - Confiaurina Alarms

19. Add the following attributes to the watch list:
For the LIT-001 object:
For the Agitator-001 object:
Malfunction
For the ABLinel object:
bue
bue
30.0
8/13/2007 2:08:17.741..
8/13/2007 2:07:17.743
bue
.
...
CO:Good
C0:Good
C0:Good
CO:Good
CO:Good
C0:Good
C0:Good
C0:Good
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
C0:Good
Ok
Wondeware Syslem Platform 3.0 Course - Part 1
5-17
5-18

Configure and Start the Alarm DB Logger Manager.
21. Launch the Alarm DB Logger Manager by selecting Start 1All Programs IWondeware I
InTouch IAlarm DB Logger Manager.
22. In the Alarm DB Logger Manager window, click the Settings button
23. Configure the Alarm DB Logger Manager - Configuration dialog box as follows and then
click the Create button:
Server Name:
(local)
Database:
WWALMDB
User Info:
User Name:
sa
Password:
[Check with your instructor for the correct password]
Logging Mode:
Wonderware Training
Detailed

24. The Success dialog box is displays indicating that the tables were created. 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.
25. Back at the Alarm DB Logger Manager - Configuration dialog box click the Next button to
continue.
Wonderware System Plafform 3.0 Course -Part 1
5-19

26. Configure the Alarm DB Logger Manager- Query Selection dialog box as follows and then
click the Next button to continue:
From Priority:
To Priority:
999
Alarm Query:
\Galaxy!ABControlSystern
\Galaxy!ABDischarge
\Galaxy!ABlntake
\Galaxy!ABProductio
Wonderware Training

27. At the Alarm DB Logger Manager - Advanced Settings dialog box, leave the default
settings and click the Finish button to accept the changes.
28. Back at the Alarm DB Logger Manager window, click the Start button to start the Alarm
Database Logger.
5-21
5-22
View the Alarm History Data

29. Launch the SQL Sewer Management Studio by selecting Start 1 All Programs 1 Microsoft
SQL Sewer 2005 1 SQL Sewer Management Studio.
30. Configure the Connect to Sewer dialog box as follows and then click the Connect button to
continue:
Sewer type:
Database Engine
Sewer name:
localhost
Authentication:
Windows Authentication
Wondenvare Training

31. In the Object Explorer (lefl pane) navigate to localhost / Databases I WWALMDB I Views to
get a list of all the database's Views in the Object Explorer Details (right pane).
32. On 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.
8/13/2007 2:57:... UNACK-Rlh
.... WACXRTh
Lli.00l.h
8/13/2007 2 5 7
A~btm~00Zt4,..The DiroeteDev... liBLine2
8/13/2OO725 ?... UNACV-NM
Agitalw_W2.M
/l3/2007 257:..,
WACKPLM
12007257:
...
/ZOO7 256:
... WACVUlt.I
12007 2%:
...
...
ThemroeieDev..
M x e i Hi level al...
ABLine2
liBUne2
WA
WACK-rVM
Wonderware Syslem Plafform 3.0 Course - Pad 1
5-24
- lnfenfionally left blank -
Wonderware Training
Section Objectives
Familiarize you with the background concept of historization, and
Enable you to understand details of historizable configuration.
This section provides familiarization with the background concept of historization and the details of
historizable configuration.
Historization Background
The history system supports historization of process data in distributed history architecture.
One or more Historian products can be installed on the same network as the Application Sewer
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 Sewer (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.
Note: Alarms are stored at the Platform, history is stored at the Engine.
History Configuration
Historizable Data Types for Attributes
Attributes of the following data types support historization:
Float (numerical)
Double (numerical)
Integer (numerical)
Boolean (non-numerical)
Wonderware Svslem Plafform 3.0 Course Pad 1
5-25
5-26

String - Unicode (non-numerical)
CustomEnum (non-numerical)
maps to Historian Integer
ElapsedTime (numerical)
Maps to Historian Float, converted to seconds
Entire arrays or portions of arrays are not supported.
All numerical attributes are sent to the Historian in the engineering units form exposed by the
attribute, and Historian does not scale the value. Additionally, the historized object does all
change detection and value deadbanding. All update packets sent to the Historian are stored to
disk.
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 historizedlstored.
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:
e
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 - s~ecifiesthe 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
Wonderware Training
product automatically. For example, if the engineering units string for the tag changes from "Deg
F to "Deg C upon a redeploy, the Historian configuration database must reflect this change.
Reconfiguration of Historian at Object Undeploy Time

When an AutomationObject is undeployed that has been historized, object does not cause any
dynamic reconfiguration of the Historian product. In other words, the Historian tag and all its
history is lefl 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 representationjust 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 ~istorian.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 o r d e ~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 (e.g. 24) and null value in the
database when certain situations such as disconnects occur. It does this in cooperation with the
ActiveFactory clients to project the right information on the cliecrt.
Wondeware Syslem Plalform 3.0 Course Pad 1
5-27
5-28

Historian Timestamp mapping
The timestamp to be sent to Historian for each attribute valuelquality update is sent by the object
in the VTQ packet. Both Application Server and Historian use UTC time.
Application Server History Storage Performance

The link from the Application Server to Historian may fail or be down for any of a number of
reasons:
e
The network connection to Historian goes down unexpectedly.
The Historian storage node goes down or fails unexpectedly.
e
The Galaxy Platform and its Engines which are generating history startup prior to Historian
node startup in a recovery situation.
e
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 storelforward. 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 storelforward must be
configurable in the Platform. Also, whether storelforward is enabledldisabled can be
configured.
When storelfotward capacity is consumed, the oldest data is.discarded in preference to

newer data.
Wondeware Training

Introduction
In this lab you are to configure your galaxy for historization to your local Wonderware Historian
software. 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.
Even when it is not part of the current class, ActiveFactory Trend can be used to quickly retrieve
history data from the history database.
Objectives
e
Configure the $AppEngine object to store history data to a Wondeiware Historian
e
Configure attributes within objects for historization including the History Extension

Configure the WinPlatForm object

1. Configure the ABGRPlatform instance to use C:\S&F as the Store & Forward folder
Configure the AppEngine object for History

2.
Enable the ABAppEngine instance for storage to the historian in your local computer.
Configure the $ABMixer.LIT template for History

3.
Configure the $ABMixer.LIT template to historize the PV attribute using the default values for
the history attributes.
4. Lock all history-related attributes
Wondeware System Plalform 3.0 Course -Pail 1
5-29
5-30

Configure the $ABMixer.lnletl template for History
5. Configure the $ABMixer.lnletl template to historize the PV attribute using the default values
for the history attributes.

6.
Lock all history-related attributes for the PV attribute.
Configure the History extension

7 . Extend the Speed attribute of the $ABMixer.Agitator template for historization using RPM as
the engineering units.
8.
Lock the history extension.
View the History data with ActiveFactory Trend

9.
Deploy the ABGRPlatforrn object on cascade.
10. Use ActiveFactory Trend to connect to the local Wonderware Historian using Integrated
security.
11. Visualize the trend for the following tags:
e
e
Agitator-001.Speed
Inlet1.PV
LIT-001.PV
See the next page for Detailed Lab instructions
Wanderware Training

please refer to the Summary Lab Instructions on the previous page(s).
Configure the WinPlatform Object

1. Double-click the ABGRPlatForm instance to open its configuration editor.

History storeforward directory:
C:\S&F
Configure the AppEngine Object for History

4. Double-click the ABAppEngine instance to open its configuration editor.
5.
Configure the History section as follows:

Enable storage t o historian:
checked
Historian:
[Name of the local computer]
Leave the default values for the rest of the attributes.
Wonderware System Platform 3.0 Course Parf I
5-31
5-32

Configure the $ABMixer.LIT Template for History
7. Double-click the $ABMixer.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 $ABMixer.lnletl Template for History

10. Double-click the $ABMixer.lnletl template to open its configuration editor.
11. On the General tab, PV section, configure the object as follows:

Historize PV:
checked (locked)
Force storage period:
0 (locked)
Wondeware Training

Configure the History extension
13. Double-click the $ABMixer.Agitator template to open its configuration editor.
14. Select the Speed attribute, check and lock the History extension and configure it as follows:
Engineering units:
RPM
Leave the default values for the rest of the attributes.
seed
ANriLwte name:
I1r~uiommicimS:n
!-[I-/
B
&
&
9,,,,:
~ j ~ ~ ! ~ ~ t ~tifferr
~ t +omirp~iiarcc
. - s t i l
~
w
..
....................
63l
~-
"
..............................rf-.
.............
Alarm message:
Engineering units:
value dcadband:
Trend high:
/ O g j
TI
EU
14
EU
Trend tour:
Label for Trud state:
7-
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-34

View the History Data with ActiveFactory Trend
16. Deploy the ABGRPlatform object on cascade.
17. Launch ActiveFactory Trend by selecting Start IAll Programs I Wonderware I

ActiveFactory I Trend.
18. Configure the Sewer List Configuration as follows and click the Add button:
Sewer:
LOCALHOST
Authentication information:
Use Integrated security:
checked

19. After the server has being added to the Sewer list click the Close button.
20. With LOCALHOST selected on the Sewers pane (top-left pane), you will see the attribute
references configured for historization in the Tags pane (bottom-left pane).
5-35
5-36

21. On the Tags pane (Bottom-left pane) double-click the following tags to add them to the trend:
22. Click on the Live Mode icon
Wondeware Training
to configure the Trend to update automatically
Module 6
Security
- Security Overview
Lab 17 - Security
Section 1
6-2
Module 6 - Security
Module Objective
Configure, deploy, and test securtty w ~ t hAppllcatlon Server
Wonderware Training

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

See the image below for a visual hierarchical overview of the ArchestrA security model. This
shows the relationships of the objects in the Security Model to each other and to the rest of the
ArchestrA System.
6-3
6-4
Module 6 - Security
Security
Access Map
...............................................
\ .....................................I i:
Each Object Attribute has a

: ,I
security;lassification.
Based
i
on the Roles granted access to
the security group, the user
i
will be allowed to or stopped
from writinq to the attribute.
!
q;up objects together that

the
-. user wants to treat in a
s~mtlarway.
'
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 Soflware 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 offscanlonscan 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.
..-
Wondenvare Tra~n~ng

The final aspect ofthe 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 Edit Security dialog box by:
1. Enabling Security
2.
Defining your Security Model
3. Mapping Users to the Security Model

4.
Mapping AutornationObjects to the Security Model
If the Security is not enabled then Authentication mode is disabled.
Authentication Mode
Wondewere System Platform 3.0 Course -Par/ 1
6-6
Module 6 - Security
On the Authentication Mode page, choose the mode of Galaxy security:

None: The default setting for new Galaxies, this mode is considered Open Security. It
leaves all functions open to all users. No authentication is provided for any operations in
the ArchestrA configuration or runtime environment. No login dialog boxes are displayed
for operating Application Sewer utilities or runtime processes.
e
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.
e
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.
e
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:
a
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 storedl
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 disolaved in the Note box.
Wonderware Training
Section 1 -Security Overview

Authentication Mode selections provide the following general results:
e
Open security gives all users the Defaultuser credentials. No login dialog boxes are
presented to users during configuration, administration or runtime operations. Login dialog
boxes are presented for all other Authentication Modes.
If you have previously configured security under one Authentication Mode and then you
switch authentication modes, only those users created while configuring the new mode
are enabled. Other users are not deleted, just disabled in the new mode.
When you close the Configure Security dialog box after selecting any Authentication
Mode other than None, you must login. This action ensures that the new security model
can be enforced. If you select Cancel on the login dialog box, the ArchestrA IDE closes.
When you switch to None from another Authentication Mode and click OK, the
ArchestrA IDE is shut down.
When Galaxy authentication is selected, each user must provide a user name and
password in a login dialog box. The security system authenticates the user's credentials
against Galaxy user data. Access to all operations in the ArchestrA IDE and anywhere in
the ArchestrA environment are granted based on the logged in user's associated roles
and permissions. The ArchestrA IDE customizes the user interface to the user's previous
preferences (for instance, which Application Views are shown). The logged in user's
name is shown in the status bar of the ArchestrA IDE.
When OS User Based authentication is selected, each user must provide a domain, user
name and password in a login dialog box. The security system ensures that the OS user is
authorized to use the ArchestrA ID.
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.
e
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.
6-7
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:
e
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.
e
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 usernamel
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
Wondeware Training
Section 1 -Security Overview

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

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

The following list of OS security configurations will be supported:
e
Machines and users participating in a domain.
Users being drawn from multiple domains.
Wondenvare Svstern Platform 3.0 Course Pad 1
6-9
6-10
Module 6 - Security
Machines and users defined witnln a Workgro~pNore the userslgro~pshave been

defined on each machfne and lmported tnro the Galaxy Reposllory (GR) and defineo as
Local Host.
Minimal Operating System Permissions Required for Launching OS User

The OS user account must not be required to have any special privileges to enable it to utilize the
client utilities. Specifically it must not require the user to be an Administrator on the host machine.
The user will be able to change their own OS password from within the ArchestrA utility.
Logon Dialog
If security is enabled within the Galaxy, a client utility Logon dialog will be displayed. Application
Sewer provides a standard login dialog.
The login appears:
The user explicitly chooses a Log On option from within the UI. It is not necessary to
explicitly Log Off before logging on using a different User Profile. The previous user will
be implicitly logged off.
Username and Password are entered onto this dialog.
If OS Authorization is being used then the user will also be required to select from a list of
accessible domain name for the user being logged in.
Logon Object
A Logon COM object is provided for use by any OS client utilities that need to log on to Application
Server. This COM object either provides a Log-on Dialog or is driven silently by an automation
interface. OS authentication and log on dialogs may be leveraged.
InTouch Access Level within Roles

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

Operators interact with AutomationObjects by accessing their Attributes. For example, a Valve is
opened by setting its object's Command Attribute to OPEN.
Attribute SecurityClassifications classify Attributes of AutomationObjects (like the above
Command attribute) from a security perspective. They are:
FreeAccess -Any User can write to these attributes to perform safety or time critical
tasks that could be hampered by an untimely logon request (e.g. halting a failing process).
This does not require the user to have any privileges.
Operate- Operators write to these attributes during normal day-to-day operations. These
include Attributes such as Setpoint. Output and Control Mode for a PID Object, Command
for a Discrete Device Object, etc. This requires the user to be assigned to the Security
Group of this AutomationObject, to allow the write.
Secured Write - Operators write to these attributes for normal interaction with a highly
secured object forces re-authentication. This requires the user to be assigned to the
Security Group of this Automationobject, to allow the write. The AutomationObject will
reject the write requested via the return status and the user must re-enter the login details.
Verified Write - Operators write to these attributes for normal interaction with a very
highly secured object. This is similar to Secured Write, however it also requires a second
user authentication. The second user must also be assigned to the Security Group of this
AutomationObject, to allow the write.
Tune -Writing to these attributes is considered a tuning activity. Examples are attributes
that adjust alarm setpoints, PID sensitivity, etc. This requires the user to be assigned to
the Security Group of this AutomationObject, to allow the write.
Configure - Writing to these attributes is considered a significant configuration change.
For example, a PLC register that defines a Discrete Device input. This requires the user to
be assigned to the Security Group of this AutomationObject, to allow the write. It also
requires that the Object is currently OffScan.
View-Only - The attributes are never written to at runtime, regardless of the user's
permissions.
There are two other situations where an Attribute's Security Classifications are specified:
0
When a User-Defined Attribute is configured.
When an Engineer overrides the Attribute Security Classification within a Template editor.
Note: Overriding Security Classifications is not permitted within Instances
Security Across Multiple Galaxies

The ability for user profiles to span multiple galaxies will be supported in future versions.
Wondenvare System Platform 3.0 Course - Parl 1
6-11
6-12
Module 6 - Security
Wondenvare Training
Lab 17 - Security
Lab 17 - Security
Introduction
As you work with the security settings within the ArchestrA ID 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 it with a sample automation
object that has been partially pre-configured for you.
Note: Importing objects will be discussed in detail, including the options in this dialog box, in the
following module.
Objectives
e
e
Configure the security classifications for individual attributes within automation objects
Configure the security settings for a galaxy
Record and view the security audit trail for a galaxy
the user is Ann Brown, Valve would be ABValve) This will eliminate problems when deploying your
objects in a common galaxy later in the course.

Import t h e SecurityTest Object

1. import the object in the $SecurityTest.aaPKG file located in the C:\Wonderware Training
folder.
2.
Rename the object $ABSecurityTest and assign it to your toolset.
Wondenvare System Platform 3.0 Course Part 1
6-14
Module 6 - Security
Configure t h e SecurityTest Object
3.
Configure the Security Classifications for each UDA in the object as follows:
Attl-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 a n d Deploy a n Instance of SecurityTest

4.
Create an instance of $ABSecurityTest named ABSecurityTest-001 and leave the default

name.
5. Assign the new instance to the ABDischarge area and deploy it.
Configure Security f o r t h e Galaxy

6. Configure the galaxy's security Authentication Mode to Galaxy.
7. Add a security group named TestGroup and assign the ABSecurityTest-001 instance to it.
8.
Configure the Default role with the following permissions:

On the General permissions section:
IDE Permissions:
unchecked
SMC Permissions:
unchecked
Can Write t o GObject Attribute using Objectviewer:
checked
On the Operational permissions section:

Default:
checked
TestGroup:
unchecked
Wondenvare Training
Lab 17 - Securitv
6-15
9. Add a new role named Operators with an access level of 500 and with the following
permissions:
No General permissions
No Operational permissions for the Default security group
Configure the Operational permissions section for the TestGroup security group as follows:
Can acknowledge Alarms:
checked
Can modify "Configure" attributes:
unchecked
Can modify "Operate" attributes:
checked
Can modify "Tune" attributes:
unchecked
10. Add a new role named Supervisors with an access level of 1000 and with the following
permissions:
No General permissions.
No Operational permissions for the Default security group.
Configure the Operational permissions section for the TestGroup security group as follows:
unchecked
unchecked
unchecked
checked
11. Add a new role named Engineers with an access level of 2000 and with the following
permissions:
Configure the General permissions as follows:
IDE Permissions: checked (this will check every box within the node)
Framework Configuration:
unchecked
SMC Permissions: checked (this will check every box within the node)
Configure the Operational permissions for the TestGroup security group as follows:
unchecked
checked
unchecked
unchecked
.-
6-16
Module 6 - Security
12. Configure the Administrator role with all Operational permissions.
13. 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.
14. Add a new user named JSup with a full name of Joe Supervisor and make it part of the
Operators and Supewisors role. Assign ww as the password.
15. Add a new user named WEng with a full name of William Engineer and make it part of the
Engineers role. Assign ww as the password.
Test General P e r m i s s i o n s
16. Verify that the WEng user cannot modify the security configuration through the ArchestrA IDE
Test Operational P e r m i s s i o n s
17. Login as Administrator and deploy the ABSecurityTest-001 object,
18. Using the watch list created in Lab 5, add a new watch window called Security and add the
20. Test the different security classifications and the security permissions by modifying the value
of the attributes under the different user accounts created before.
Wondemare Training
Lab 17 - Security
View the Security Audit Trail
21. Use SQL Sewer Management Studio to query all data from the v-EventHistory view
Wonderware System Platform 3.0 Course -Pad I
6-17
6-18
Module 6 - Security

Import the SecurityTest Object

1.
From the Galaxy menu, select Import1 Object@) to import an automation object
2. On the lmport Automation Object(s) dialog box, navigate to C:\Wonderware Training and
select the $SecurityTest.aaPKG file. Click the Open button.
Wondenvare Training
Lab 17 - Securitv
3. On the Import Preferences dialog box, leave the default options and click OK to continue
Note: Importing objects will be discussed in detail, including the options in this dialog box, in
the followina module.
You can find the imported object in the Application toolset
e.
ABGala?
$ @ A6 Training
.
i:
.
i..
:
:.
.i
.
,.,,
@ Application
.
:
(J SAnalogDevim
:
.
. (9 SBoolean
.i
:
;- g SDiscreteDevice
.
.i 9 $Double
.
yO
SFieldReference
6-19
6-20
Module 6 -Security
4.
Rename the object $ABSecurityTest and move it your toolset.

...
. . -.- ....
..-.....
-.
.-
pjTemplate Toolbox
.
. .. .
. . . .. ..
Configure the SecurityTest object

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

Wondeware Training
Lab 17 - Security
6. Select the Attl-FreeAccess UDA and click the Shield icon to select the security
classification for the attribute. Select the Free Access security classification from the popup
menu.
Datatype:
category:
7.
Repeat step 6 to configure the security classifications for the following attributes:
~tt2-operate:
Att3-SecuredWrite:
Att4-VerifiedWrite:
I
@
rq
AM-Tune:
[
-
Att6-Configure:
8.
Operate
Secured Wr~te
-
Ver~f~ed
Wr~te
Tune
Configure
Click the Save and Close button and check in the object
6-22
Module 6 - Security
Create and deploy an instance of SecurityTest
9.
Using the Template Toolbox and the Model view, create an instance of the $ABSecurityTest
template. Leave the default name and assign the instance to the ABDischarge area.
10. Deploy the newly created instance
Configure Security for the Galaxy

11. From the Galaxy menu, select Configure I Security to enable and configure security for the
galaxy.
Wondenvare Training
Lab 17 -Security
12. Select Galaxy for the Authentication Mode.
6-23
6-24
Module 6 - Security
13. Select the Security Groups tab.
Wonderware Training
Lab 17 - Security

TestGroup.
to add a new security group. Name the new security group
15. Select the Default security group and locate the ABSecurityTest-001 instance in the objects
list (right pane).
Wondeware System Platform 3.0 Course Parf 1
6-25
6-26
Module 6 - Security
16. Drag-and-drop the ABSecurityTest-001 instance to the TestGroup in the security group list
(left pane).
Select the TestGroup security group.
Important! Make sure that you are moving the object's instance and NOT the object's
template.
Wonderware Training
Lab 17 -Security
17. Select the Roles tab.
Ei
Ei
E
rncan St21t the IDE

rnImpcrbng and Expoibng
General Configuiabm
rnsystem Configurabon
Wondenvare System Platform 3.0 Course Pad l
6-27
6-28
Module 6 - Security
18. From the Roles available list, select the Default role and configure the permissions as
follows:
On 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 t o GObject Attribute using Objectviewer: checked

On the Operational permissions section:
Default:
checked
TestGroup:
unchecked
Wonderware Training
Lab 17 -Security
to add a new role and name it Operators.
Double-click on the Access level fieid and enter 500.

checked
unchecked
checked
unchecked
Wondeware Svslern Platform 3.0 Course - Parf 1
6-29
6-30
Module 6 - Security
to add a new role and name it Supervisors.
Double-click on the Access level field and enter 1000.

unchecked
unchecked
unchecked
checked
Can Start the iDE

Importing and Exporting
General Configuration
System Configuration
DeviceIntegration Objects
Application Configuration
[? Framework Configuration
User Configuration
[? Deployment Permi~sions
C] Graphic Management Peimirsions
SMC Permissions
'
C] c a n Startfitop EngineiPiatbrm
[?can Write t o GObject Atbibutes using 0
[?can
acknowledge Alarms
- [ ? Can modify 'Configure-amibutes

--- [? Can modify Uperate'amibuter
Can modify Tune'atVibutes
Wonderware Training
Lab 17 - Security
to add a new role and name it Engineers.
Double-click on the Access level field and enter 2000.

Configure the General permissions as follows:
IDE Permissions: checked (this will check every box within the node)
Framework Configuration:
SMC Permissions:
unchecked
checked (this will check every box within the node)
unchecked
checked
unchecked
unchecked
............
'
Can Mo&fy Tune' Amhtes
Wondeware System Plafform 3.0 C o m e - Parif
6-31
6-32
Module 6 - Security
22. 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)
SMC Permissions
'.. -mCan Siart k SMC

'i
..
Can start/Stop En@ne/Flatfom

Can Write to GObject Attributes udng 0
Can acbowledge Alarms

O C a n modify Toofigure"attributes
.
Can modify "Operate'atbbutes
.
..
Wondenvare Training
-m
Can modify Tune'amiwtes
Lab 17 - Security
23. Select the Users tab.
Wondenvare Svsfem Platform 3.0 Course - Pad 1
6-33
6-34
Module 6 - Security
to add a new user and name it Hoper.
Double-click on the Full name field and enter Homer Operator.

Assign the user to the Operators role.
Wonderware Training
Lab 17 - Security
With Hoper selected, click on the Change Password button, enter the following information
in the Change Password dialog box, and then click the OK button to continue.
Old Password:
[blank]
New Password:
ww
Confirm New Password:
ww
Click the plus icon button
to add a new user and name it JSup.
Double-click on the Full name field and enter Joe Supervisor.

Assign the user to the Operators and Supervisors roles.
Wonderware System Platform 3.0 Course - Pafi l
6-35
6-36
Module 6 -Security
27. With JSup selected, click on the Change Password button, enter the following information in
the Change Password dialog box, and then click the OK button to continue.
Old Password:
[blank]
New Password:
ww
ww
to add a new user and name it WEng
Double-click on the Full name field and enter Will Engineer.

Assign the user to the Engineers role.
Wondenvare Training
Lab 17 - Security
29. With WEng selected, click on the Change Password button, enter the following information in
the Change Password dialog box, and then click the OK button to continue.
Old Password:
[blank]
New Password:
ww
ww
30. Back on the Configure Security dialog box, click OK to accept the security configuration
31. On the Change User dialog box, enter the following information and then click the OK button
to log in:
User name:
WEng
Password:
ww
Test General permissions

32. Logged in as WEng, 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.
Click No to dismiss the dialog box.
Wondenvare System Platform 3.0Course Pad 1
6-37
6-38
Module 6 - Security
33. From the Galaxy menu, select Change User to log in as the Administrator.
34. Enter Administrator for the User name and click the OK button to log in as the Administrator.
Note: Bv default the Administrator account DOES NOT have a
Wondeware Training
D ~ S S W O
assianed.
~ ~
Lab 17 - Securitv
Test Operational permissions

35. Deploy the ABSecurityTest-001 object.
36. Open Object Viewer by right-clicking the ABSecurityTest-001 instance and selecting View
in Object Viewer. If you closed Object Viewer before, you can use File I Load Watch List to
38. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab ... to
rename the watch list to Security.
39. Add the following ABSecurityTest-001 attributes to the watch list:
Scanstate
ScanStateCmd
ABSecurityTest-ODl.Att2-Operaie
ABSecurityTest_001.At1313SecuredWriie false
ABsecurityTest-ODl.A~4-Verified\fiIrite false
ABSecurityTest-001.AE5-Tune
false
ABSecurityTest-00l.Am-Configure
false
ABSecurityTest-001.Att7-ReadOnly
false
ABSecurityTest-00l.ScanState
true
ABSecurib,Test-001,SmnSiateCmd
hue
C0:Good
C0:Good
C0:Good
C0:Good
C0:Good
C0:Good
Ok
Ok
Ok
Ok
Ok
Ok
Wondenvare System Platform 3.0Course -Part 1
6-39
6-40
Module 6 - Security
41. Test the different security classifications and the security permissions by modifying the value
of the attributes under the different user accounts created before.
To log in to Object Viewer with a different user account, select Change User from the
Options menu.
42. Enter the user's credentials in the Change User dialog box and then click the OK button.
You can verify the current logged in user on the lefl side of the status bar.
.
--. -.-- ....
.. . .. . ..-.
.. ...-. ....
-..
FILE: C:\.?ona~r,;,areTrain~ng'fily
Watch rnr~ndc;,!
..
. . User: hoper
Wondeware Training
- -.. .. . -. ..
.!.lode:
.
U S E T I
.p4
Lab 17 - Security
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
Loaaer Manaaer utilitv.
43. Launch the SQL Sewer Management Studio by selecting Start / A l l Programs IMicrosoft
SQL Server 2005 1 SQL Server Management Studio.
44. Configure the Connect to Server dialog box as follows and then click the Connect button to
continue:
Server type:
Database Engine
Server name:
localhost
Authentication:
Windows Authentication
Wondenvare Svstem Plafform 3.0 Course -Pad 7
6-41
6-42
Module 6 - Security
45. In the Object Explorer (left pane) navigate to localhost IDatabases IWWALMDB [Views to
get a list of all the database's Views in the Object Explorer Details (right pane).
dbo
dbo
dbo
dbo
dbo
dbo
dba
dba
dba
dba
dbo
ot
l Mampement
o CI NobficaPan Sernces
o @ SQi server agent
46. On the Views list (right pane), right-click on the v-EventHistory view and select Open View
to display the current list of alarms logged in the database.
-T... LBDerharge
OPR
false
bue
hue
hue
Closed
Stopwd
false
Wondeware Training
Galaxy Maintenance
Section 1 - Exporting and Importing Objects
Section 2 - Configuring Instances Through a .CSV File
Section 3 - System Management Console (SMC)
Section 4
- Network Account Utility
7-2
Module 7 -Galaxy Maintenance

.
Module Objectives
Obtain an overview and understanding of:
Exporting and Importing Objects
Configuring Instances Through a .csv File Using Galaxy Dump and Load
Using the System Management Console to manage platforms
Using the Network Account Ut:lity
Wonderware Training
Section Objective
T h ~ ssection discusses some fundamental funct~onsdealing with Galaxy Maintenance.
Specifically, it illustrates how to Export for future use and how to Import a galaxy created
previously.

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

To export an object
1. Select an object in the Template Toolbox or Application Views pane.
2.
From the Galaxy menu, select Export/AutomationObject(s).
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 AutornationObjects.
Wondenrare Training

3. 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.
I/
Export completed
7-6

4. When the export process is finished, click Close. The resulting .aaPKG file can be used to
import the chosen objects into another existing Galaxy.
. . ..
. .
1.' Name
'
ABAulur~~al~unOblecI~~aPKG
Size Type
6.61 3 KP M P G F e
..
.-
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 IDES export function to share objects with other users or to recreate them in
other Galaxies. The resulting file (.aaPKG extension) contains the selected objects, their
associated templates and the configuration state of those objects. The export file can later be
imported into the same or another Galaxy.
Subsequent exports retain the default folder as last used for the duration of the 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 s c r i ~function
t
libraries are transferred se~aratelv.
Wondenvare Training

To export all automation objects
1. From the Galaxy menu, select ExportIAll Object(s).
7-7
7-8

2. 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.
Export completed
I[
BTest: Exported successfully.

k t r ~ n oExoorted
:
successfullv.
Wondeware Training
I 4
Section 1 -Exporting and lmporting Objects

3. When the export process is finished, click Close. The resulting .aaPKG file can be used to
import the objects into another existing Galaxy.
..
' Name
~~ABAulomalion0b:ecl
aaP(&
B
-
..
Sic] Type
6.613 <B
12.788 <I3
M P < G F It
PAFG F
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.
lmporting 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.
lmporting 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.
7-9
7-10

To import Automation objects
1. On the Galaxy menu, select lrnport/Object(s)
Wondeware Training
Section I -Exporting and Importing Objects

2. 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.
7-11
7-12

3.
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 i s 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 Industrial Application Server Installation Guide
In the Objects from different toolkits andlor 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
Wondeware Training
Section 2 - Configuring lnstances Through a .CSV File
Section 2 - Configuring lnstances Through a .CSV File

Section Objective
This section discusses some fundamental functions dealkg with Galaxy Maintenance.
Specifically, it illustrates how to Export a galaxy for future use and how to Import a galaxy
created previously.
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).
Note: This function only dumps instances. Templates cannot be dumped. The .csv file contains
the configuration for the checked in versions of the selected objects as well as the checked-out
objects of the user who initiates the Galaxy dump. The file contains only those attributes that are
unlocked and configuration time-writeable, one column per attribute. Attributes that are locked,
calculated or runtime writeable only are not saved to the file. Attributes that are not text based (for
example, type QualifiedStruct) are not dumped. Object Help files are not dumped.
To export objects to a Galaxy dump file
1. Select an object in the Application Views pane. You can export more than one instance with
this function by first multi-selecting objects (Shift+Click). Also, you can dump all instances
derived from a template by selecting just the template.
2)
Wonderware System Pleliorm 3.0 Course - Par/ 1
7-13
7-14

2. Select Export on the Galaxy menu and then click Galaxy Dump.
The Galaxy Dump dialog box is displayed
Wondeware Training
Section 2 -Configuring Instances Through a .CSV File

3.
Browse to the name and location of the .csv file to which you want to dump the selected
instances. Click Save to continue or Cancel to end the export function. The Galaxy Dump
progress box is displayed.
4. After the Galaxy dump process is finished, click Close. A .csv file has been created containing
the selected objects and configuration data.
I/
Dump completed
7-15
7-16

The actual .csv file has been created.
Galaxy Dump File (.csv) Structure

Dumped objects are organized in the resulting .csv file based on the template from which each is
derived. A header row per template indicates the instance's columns' reference. Comments can
be added in the resulting .csv file by adding a line preceded by a semi-colon.
~~~
Note: Carriage returns in scripts associated with dumped objects are replaced with "\nu 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 "\nu 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 "\\nu if you want to
include the character "\" followed by the character "n" in a script. This character set is not
converted to a carriaoe return in a Galaxv Load function.
Wondeware Training

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

2. In the Galaxy Load dialog box, browse to locate the .csv file that contains the objects and
configuration data you want to import.
Select the file and click Open to continue or Cancel to end the import function
Wondeware Training

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:
e
Replace entire instance if an instance of an object with the same name already
exists and you want to replace it entirely with the object in the import file.
Only update changed attributes if an instance with the same name already exists
and you want to replace only the attributes of the object where the values are
different.
e
Skip if an instance with the same name already exists and you want to keep the
version already in the Galaxy.
Stop Galaxy Load if an instance with the same name already exists and you want to
cancel the Galaxy Load.
3.
Choose the preferred conflict resolution and click OK. A progress box is displayed during the
Galaxy load process. Click Cancel to terminate the Galaxy load process.
A Galaxy Load dialog box appears indicating that the Load was successful
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.
-v*
7-19
7-20
- lnfentionally left blank -
Wondenvare Training
Section Objectives
Understand the role of the System Management Console, and;
Have an understandmg of how it can be configwed
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 ArchestrATMapplication. 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 Microsofl Management
Console (MMC) Snap-in, its interface is integrated into the MMC environment and it appears as a
single interface.
Features of the Platform Manager
.
..
.
Some of the key features of the Platform Manager are that it:
Runs with minimal ArchestrA and operating system requirements, equivalent to "Safe
mode"
Uses the local platform as the gateway to the ArchestrA application
Does not rely on the Galaxy Repository to exist
Allows viewing of the layout of the Galaxy Repository, Platforms, and Engines
.
e
Provides the ability to set Platforms and Engines OnScan or OffScan

Provides the ability to start and stop Platforms and Engines
Starting Platform Manager

Platform Manager is a common component of an Application Server application and it is available
from any PC node in the application that has a deployed platform: therefore, you do not need to
install it onto each node. This ensures that all nodes used within a galaxy have access to Platform
Manager.
When you use Platform Manager, you can access the platforms and engines deployed to the local
PC node and to any other PC node in the Galaxy. Platform Manager does not require the
GalaxyRepository to be installed on the PC node.
7-21

After highlighting a platform, you can use the Action menu to start or stop a platform, or set it
OnScanIOffScan. If the platform has security implemented, you must be logged on as a user
configured with the proper SMC permissions to start SMC. Start/Stop engines and platforms, or
write from the Object Viewer.
To Star! Platform Manager

Ensure your Application Sewer application is running. Start Windows and click Start to start your
programs. Select ProgramsNVonderwarelSystem Management Console.
If Platform Manager has security enabled, the Platform Manager Login dialog box appears.
....
"- .. -- -... ".
....................
iug!! .
User name'
! -
Passv:ord:
Darnan:
OK
Cancel
I-~
' -J
...............
. . . . . . . . . . . . . . . . . . .
..
. w~ .. " .... ..
. . . . . . .
...-....
.
Change Password
From the Platform Manager Login dialog box, enter your User Name and Password. If the
configured security is OS User Based, then select the domain from the Domain list box. Click OK.
Wonderware Training
Section 3 - System M a n a g e m e n t Console ( S M C )

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

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 utilities.
There are four authentication modes for security that can be enabled for Platform Manager:
No authentication
e
Galaxy authentication mode
e
OS User Based authentication mode
e
OS Group authentication mode
When no security is enabled from the ArchestrA IDE, the user is automatically logged into Platform
Manager as "DefaultUser." Without security, the logon dialog box does not display when Platform
Manager is launched and the user is granted all permissions.
If the security configured from the ArchestrA IDE requires Galaxy authentication, OS User Based
authentication, or OS Group authentication, then some of the existing users and roles are not valid
and the user may not be able to perform some operations.
Galaxy Authentication
Galaxy authentication requires the user to log into Platform Manager every time the utility is
started.
OS User Based Authentication

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

Upon opening the System Management Console there are a wide selection of options available
from the menu and icon bar:
The following commands are available from the Platform Manager Action menu when you select
a platform or engine in either the console tree or the details pane.
Wonderware Training
Command j .
Configure
Log Flags
Open Log File
Connect
Messages
Refresh
Help
.,)<'
'',:
,,
i 'i
' ;'
,, ,, ,<,
2pIIir,.<p,y,rr.o,,
.,.,
i.,,:.,
,
~
e
t
~
, , : .,,, ,
Allows configuration of the Log Viewer and Storage
Opens the Log Flag editor
Allows the opening of a Log File
Allows either local or remote connections configuration
Allows Messages to be exported, purged, or printed
Refreshed the database
Access to the System Management Console Help files
, . ,, ,i
, , ,,<'.:'
These commands are also available by right-clicking an item in either the console tree or the
details pane. The available commands are dependant o n the current state of the object and your
security permissions. If you do not have permission to perform a particular command, then that
command is grayed out.
The following commands are available from the Platform Manager View menu when you select a
platform or engine in either the console tree or the details pane.
.....
Command
Filter
Find
...
.........
......
- - .------
Description
-..- . . . . ................
- - .-,
Allows filtering of Messages. Time Range, or Terminal Sessions
Search capability on Process ID, Thread ID, Log Flag, Component, or
Message
7-25
7-26
>':
,,.,
,~.,*
,
, ' , ,:.>
,$,,, ~
, ,<,
dommana,~$~""":,',';:,',,
,:'.,,/'..~ ~1 +'~ c ~ ,,,:,~7,,,.<,
t i,,;:-;,:'
~ n , .:A?$$;;,,,,,,
,,,,..,,,. ,,.,. ,.3/?i
5 . ,, ,,
Allows redirection to a Bookmarked location
Go To
Allows Adding or removing of a Bookmark
Bookmarks
Allows the entry of a Marker Message to the log
Mark
Select specific columns to show or hide
Choose Columns
Change the appearance of the view
Customize
,',-.C
,,,;,, :,>.,,
,,2,
>,, >,
~y>,.,,,<c"**,.c,
,:;~,,~9:;;'s;~L~~$>',7?:8~~<~j~~
>#,,
,,,,:,~:~.,,,,
.
, ,
Platform Manager Toolbar Buttons

The following toolbar buttons may appear on the console toolbar, but vary depending on the object
that you select in the console tree and its current state.
Forward
Up one level
ShowIHide Console TreelFavorites
Refresh
Help
Filter
EnableIDisable Message Filte~
Find
Fast Mark
Print
Print Preview
Wondeware Trammg

Log Viewer
The Logger is an ArchestrA utility that records information regarding the activity occurring on the
Computer. For example, it records start-up data, error conditions, and DAServer information.
The Log Viewer can:
e
Monitor messages on any machine in the system
Send a portion of the log to notepad or E-mail

Filter messages on a flag
Security for the log viewer is set at the galaxy level

When running an ArchestrATM application, the Logger runs as a system service. The Log Viewer
is a Microsoft Management Console (MMC) snap-in that provides a user interface for viewing
messages reported to the Logger. The MMC is a host or container utility for the Log Viewer with its
own generic functions.
Note: If a problem occurs while running an ArchestrA application, always check logged
messages by using the Log Viewer prior to calling Technical Support.
The Logger and Log Viewer are automatically installed when an ArchestrATMcomponent is
installed.
e
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 ArchestrATM component begins functioning.
e
Log Viewer - This utility is used to view error and informational messages that are sent by
ArchestrATMcomponents. The look-and-feel and the format of the user interface can be
customized to suit individual needs.
Typical Log Viewer Usage

The Log Viewer is primarily a troubleshooting tool. After initially installing an ArchestrA-enabled
program and on occasion, you might check logged messages to determine whether all processes
are functioning well. But typically, you would use the Log Viewer to work through problems you
encounter with a DAServer, the ArchestrA IDE or other ArchestrA component.
Note: The Log Viewer displays error messages in red-highlighted stripes. These indicate
malfunctioning processes and should be resolved quickly. Warning messages are displayed in
yellow stripes. These indicate major events in the system.
A good strategy for troubleshooting problems
1. 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.
2. Open the Log Viewer by clicking Start, pointing to Programs and then to Wondeware, and
then clicking System Management Console. In the SMC, select Log Viewer and then the
Wondeware Sysfem Plafform 3.0 Course - Pati 1
7-28

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.
3. Use the Find command on the View menu to single out messages by message text or other
category of data, or use the Filter command on the View menu to reduce the number of
displayed messages based on message, time range or terminal session criteria.
The following chart indicates the key differences in Log Viewer and WWLogger.
. .Yes
..~
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.
Wondenvare Training
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 a d d a regular b o o k m a r k t o a message
1. Right-click the message and click Add Bookmark on the Bookmark submenu.
2. In the Add Bookmark dialog box, either accept the default name (Bookmarkx where x is a
number in an ascending sequence) or overwrite it with something more descriptive. You can
change the bookmark name in the Bookmarks dialog box at a later time. See "To manage
bookmarks" below.
3.
Click OK to set the bookmark or Cancel to terminate the process.
To s e t a f a s t b o o k m a r k on a message
1. Right-click the message and click Fast Bookmark on the Bookmark submenu. A default
naming sequence is applied to the message (Bookmarkx where x is a number in an ascending
sequence). Alternatively, you can set a fast bookmark by selecting the message and clicking
the Fast Bookmark icon on the toolbar.
2. Change the bookmark name to something more descriptive, if necessary, in the Bookmarks
dialog box at a later time. See "To manage bookmarks" below.
Wonderware System Platform 3.0 Course -Pad I
7-29
7-30

To g o t o a b o o k m a r k e d message
1. On the View menu, click Go To.
2.
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.
3.
Click Go To. The Go To dialog box remains open.
4.
Use the Previous and Next buttons to go to the nearest bookmarked message above and
below, respectively.
5. When you are done searching, click Close

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

Selecting the Galaxy Database Manager on the SMC Menu allows you to view all the galaxies in
the Galaxy Repository, as well as the nodes they reside on.
You must have Administrative privileges to use the Galaxy Database Manager.
DAServer Manager
The QASewer Manager allows local or remote configuration of the DA Sewer and its device
groups and items, and can monitor and perform diagnostics on DASewer communication with
PLCs and other devices.
Wondeware Training

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 DASewer 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.
7-31
7-32
Module 7 - Galaxv Maintenance
Wondenvare Training

Section Objectives
This section discusses the role of changing the network account and how to use the Change
Network Account Ut lhty to accomplish that task. ARer discussing this section you will be able to:
Understand the role of the Change Network Acwunt Utility, and;
Have an understanding of how it can be configured
This section discusses the role of changing the network account and how to use the Change
Network Account and how to configure it.
Change Network Account Utility

The Change Network Account utility is a tool you can use to manage credentials for node-to.
node communications between ArchestrAm"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 utilitv.
To recreate a n ArchestrA u s e r a c c o u n t
1. Start the Change Network Account utility by selecting StartlProgramslWonderwarel
CommonlChange Network Account.
Wondenvare System Plalform 3.0 Course - Pafl I
7-33
7-34
The Change Network Account dialog box appears.
The data shown in this dialog box are those settings entered during the initial installation of an
ArchestrA component on the computer. The password options are shown blank for security
reasons.
Wonderware Training

The Change Network Account utility allows you to change the current data shown in the
dialog box, including:
e
Changing the password of the current account.

Creating a new local user account.
Using an existing local machine or network domain account.
In a single-node ArchestrA system, create any account.

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.
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 ~ ~ c o uutility

n t to create or use an account that is different
from the one originally set up during installation, the old account is maintained (not deleted).
7-35
7-36

WARNING! After you change any data shown in the Change Network Account dialog box,
ensure that ail other computers that have installed ArchestrA-enabled soflware use the same type
of user account with the same user name and password.
Error Messages
When using the Change Network Account utility, you may encounter the following error messages
squired to run this utility.
. .. .
...
fiction
.
.
. Required . .. .. .. .. . - ... .
YUJ m ~ shave
t
Adm~nstrator ~ r leqcs
v
on the compdter to rJn Ihs
~tility.Click OK, login as a uskr with~dministratorrights, and start the
Shange Network Account utility again.
The Password was not correc

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

iialog box. These two passwords must match to ensure the accuracy
>f user
both ass word and confirmation
~~- account data. Click OK.. retvDe
*.
>asswordtext, and then click OK again.
Password cannot be empty.

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

Please enter another user nar
YOJ chose lo creale a local account oy se ecl ng Create Local

Account n me Cnanac Networ< Account JIlhtv Th s account alreaoy
?xists. Click OK, type a new user name in the Change Network
4ccount utility, and click OK.
DomainlLocal Machine name

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

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

Please enter another user nal
You chose to use a local machine or network domain account that does
not exist. Click OK. Ensure the user account you entered in the
DomainlLocal Machine Name box is valid and the user name and
password you typed are valid for that user account, and then click OK.
If this message is displayed again, check with your network
administrator about the existence of the account.
The password policy for this

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

whose password policy allows the password to be changed or to
expire. Click OK if you want to use this account or Cancel to return to
the Change Network Account utility. Then, you can choose to use or
create another user account.
~~~~~
Caution! It is recommend that you do not use a domain account whose

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

account 'a' to use this new
password?
You chose to use a local machine user account, but the password you
typed does not match the accounPs password. Click OK if you want to
change the password for this user account or Cancel to revert to the
original settings. If you click OK, the password for the account is
changed. If you click Cancel, the Change Network Account utility is
displayed, allowing you to correct the password or type another user
name and password.
Invalid ~omaizname'dom'.
Please enter a valid domain
name.
You typed an invalid network domain name in the DomainlLocal

Machine Name box. Click OK, retype the domain name, and click OK
Wondeware Training

< ,
<;'.,
. ,zx.:~
v,,>,
'..\ " 4 < i l : ( . I *
-..(,.*.,. .
,;:;:,:;,f:?,?;?;l;&&i@";~~~~,~~d'~
:,3>k
:;j@$$c3;::2:iy$>z:;,::,?,
,,
,,,, ':,:- :
.:
invalid Password for user account You chose to use a network domain user account, but the password
'a'. Please enter the correct
I vou twed does not match the account's oassword. Click OK.correct
password.
ihe piisword, confirm the password, and click OK.
The system will now reboot.
You changed account information in the Change Network Account
Please close all your open
utility. The computer must be restarted to implement those changes.
applications and press " O K when Close open applications, and click OK.
you are done.
grroi Message':".'
,.\,.X.<' -.
>';:,,,:r,/e:;,
\
User name cannot contain these

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

of periods [.I or spaces.
You must type a user name in the Change Network Account utility.
Click OK,type a user name in the dialog box, and then click O K 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
exceot the su~ervisorvnetwork.
For any multiple NIC ArchestrA node to communicate successfully with all other Galaxy nodes,
you must define the correct order of network connections in the network services of the computer.
Open the Network a n d Dial-up Connections dialog box (see image below) and rename each
card with a clearly identifiable function (for instance, "Supervisory Net" and "PLC net"). Different
operating systems provide unique access to the Network a n d Dial-up Connections dialog box
(in Windows 2000 Professional, click Start; point to Programs, Accessories and
Communications; and then click Network a n d Dial-up Connections).
fm Network and Dial-uo Connections
1I'~ddress
IFli
@GO
I!
7-37
7-38

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

in the ArchestrA environment. You must configure the IP address and DNS settings as follows for
each network card to function properly.
Do the following for each network connection
1. In the Network and Dial-up Connections dialog box, right-click the network connection and
click Properties in the shortcut menu. The connection's Properties dialog box (see image
below) is displayed.
Wondeware Training
2.
Select lnternet Protocol (TCPIIP) in the list of components used by this connection, and click
Properties. The lnternet Protocol (TCPIIP) Properties dialog box (see image below) is
displayed.
Wonderware System Platform 3.0 Course - Parf 1
7-39
7-40
3.
For the supewisory network, select Obtain an IP address automatically. For the other
network connections, select Use the following IP address. Consult your network
administrator for the proper settings for the remainder of the parameters in this group.
4.
Click Advanced. The Advanced TCPIIP Settings dialog box (see image below) is displayed.
Click the DNS tab.
Wondeware Training
5.
Forthe supervisory network, select Register this connection's addresses in DNS. For the
other network connections, clear this check box.
6.
Click OK.
.-
Wondeware Sysfem Platform 3.0 Course -Part I
7-41
7-42
- Infentionally
Wonderware Training
left blank -
evice Integration
Section 1 - Wondeware 110 Servers
Section 3
- Device Integration Objects
8-2
Module 8
- Device Integration Products

.. .
Module Objectives
DAServers and Dl Objects and how they relate to the connectivity of your application to
external data.
FactorySuire Gateway and how it can enhance the connectivity of your applcalion.
Wondeware Training
Section 1 - Wondeware 110 Servers
Section 1 - Wonderware 110 Servers
Section Objective
Configure a Wonderware I10 Server (Modbus)
This section will describe the configuration of a Wonderware I10 Server (Modbus).
Introduction
Wonderware 110 Servers are Microsoft Windows application programs that enable other DDEaware 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 110 Server.
Because Wonderware's I10 servers are Windows applications, they will all have the same basic
appearance and capabilities. Keep in mind that depending on server required, additional hardware
(network, and so on) may be necessary and the configuration screens may require additional
information.
The following information references the Modbus I10 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 I10 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 0 5 PLC via its programming port.
Configuring 110 Servers

Once the 110 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 110 Server is installed
unless a different directory is specified via the Configure I110 Sewer Settings command.
a.
Select Start IPrograms IWonderware 1 IOSewers IModicon MODBUS

The MODBUS dialog box appears:
b. Click Configure ICom Port Settings.
Wondenuare System Platform 3.0 Course - Pail I
8-3
8-4

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.
Corn 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 I10 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 second should be sufficient for
most confiaurations.
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,
Bits, Data Bits and Baud Rate.
Paritv. S t o ~
Wonderware Training

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

Creating Topic Definitions
The Configure I Topic Definition command is used to create, modify, or delete topic definitions
One or more topic definitions must exist for each PLC that the 110 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 ITopic Definition.

The Topic Definition dialog box appears:
Note: Once topics have been defined, their names will be listed in the Topics pane of this
dialoa 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.
Wondewwe Training

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 110 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.
I.
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 110 Server will read (poll) the
itemslpoints associated with this topic. Different itemslpoints 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.
8-7
8-8
- lntenfionally left blank -
Wondeware Training
Section Objective
Become familiar with DAServer and its use with Wondeware Application Server.
This section provides familiarization with DAServer and its use with Wonderware Application
Server.
Introduction
Wonderware's DAServer is designed to provide simultaneous connectivity between client
applications based on Wondeware@SuiteLinkN, OPC and DDE protocols that run on Microsoft's
Windows@2000 and Windows XP operating systems and the data devices supported by the
specific protocol being translated.
Wonderware's DAServers also come with an exclusive new user interface called the DAServer
Manager, which is installed as a Microsoft@Management Console snap-in. Its end-user benefits
include simple remote server activation, configuration and operation, and extensive protocol
diagnostic troubleshooting.
Several standard features are available with each DAServer, including:
e
Compliance with OPC version 2.05
e
Stand-alone operation mode
e
Support for hot configuration, device additions and device- and server-specific parameter
modifications
A wide range of DAServers support connectivity to numerous protocols and products
Wonderware's current DAServers offering also includes support for:
Allen-Bradley's CIP protocol for ControlLogix
e
Allen-Bradley's TCP protocol
e
e
e
Allen-Bradley's DH Plus protocol

Siemens' Simatic Net 57
Modbus@Serial protocol
Configuration
DAServers can be configured using the DAServer Manager utility. The DAServer Manager is an
MMC shell capable of displaying specific configuration pages for each configuration node. This
utility allows browsing and editing of servers on different nodes.
DAServers are hot configurable. In other words, they are configurable while the server is running
or even acquiring data. Certain restrictions imposed by the underlying networklprotocol/hardware
might apply. For instance, if you uncheck System ltems on the global parameters configuration
dialog of the DAServer Manager and select Apply, and then re-check System ltems and Apply,
System ltems data is valid only to newly connected clients.
The configuration data format for DAServers is XML. Any XML-enabled program (for example, I
and XML Notepad) can read this format.
Wonderware System Plafform 3.0 Course - Pae I
8-9
8-10

Component Architecture
A DAServer is comprised of three physical parts:
e
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 DASewer.
DAS Engine: common component used by all DASewers.
The DAS Engine is a middleware component that exposes two sets of unique interfaces,
one for communicating with Plug-ins and one for communicating with Device Protocol
Layer components. It encapsulates common tasks for the DAServer, like handling the item
database, distributing data to clients, propagating clients' requests to the protocol, and
providing diagnostics.
Device Protocol Layer: Server specific (responsible for communicating with hardware and
specific to the DAServer). The Device Protocol Layer provides translation between the
hardware- specific protocol such as ModBus and CIP and the DAS Engine interface:
Data Access Sewer
Components
DAS ENGINE
DEVICE PROTOCOL LAYER

SERVER-SPECIFIC
DEVICE
eel
Data Access Sewer

Camponent (Created
wlth DASewer Toolkit)
C-
HARDWARE
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.
Wondeware Training

You must create the Device Protocol Layer (server specific) modules with the DAServer, and all
three sets of modules are required for a fully functioning DAServer.
Plug-ins
Plug-ins provide protocol translation functionality for device integration clients. Typical Plug-ins
communicate in DDE, SuiteLink or OPC protocol, and serve as interfaces between their clients
and the DAS Engine. You can disable a protocol when customizing the installation for your
DAServer.
DAS Engine
The DAS Engine is a middleware component that exposes two sets of unique interfaces, one for
communicating with Plug-ins and one for communicating with Device Protocol Layer components.
It encapsulates common tasks for the DAServer, like handling the item database, distributing data
to clients, propagating clients' requests to the protocol, and providing diagnostics.
Device Protocol Layer

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

Diagnostics
The DASewer Manager diagnostic tool displays generic diagnostic objects common to all sewers
as well as server-specificlsewer 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 DASewer
Manager and configure each hierarchy. Any changes she makes that addldeletelupdate a
hierarchy are sent immediately to the running DAServer.
Sewer-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 sewerspecific code.
Here is a complete list of notifications to the sewer about changes in the configuration:
Add configuration hierarchy.
Delete contiguration hierarchy.
Rename configuration hierarchy.
Update parameters of configuration hierarchy.
Add device group.
Delete device group.
Rename device group.
Update parameters of device group.
Clear the current configuration set.
Switch to a new configuration set.
Wondeware Training

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 training@wonderware.com.
A primary purpose of 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-patty clients except through InTouch. Excel, Visual Basic, and other thirdparty 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.
Other Connectivity Tools

Wonderware Application Server can access device data by using client application objects. These
Dl Objects ($DDESuiteLinkClient, $InTouch proxy, $OPCClient) enable the server to interface with
110 devices that use DDE, SuiteLink, InTouch tags, or OPC protocol.
Other protocol connectivity tools include third-party OPC servers, the Archestra DAS Toolkit, the
Rapid Protocol Modeler Kit, the ActiveX SECS-IIIGEM kits, and the InTouch Tag Creator.
110 servers provide connectivity for devices using DDE, FastDDE, and SuiteLink protocols. I10
servers can connect every Wonderware A2 component, as well as PLC, RTU, DCS, and ESD
systems.
8-13
8-14
Module 8 - Device lntegration Products

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

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

FS Gateway behaves like a DAServer and is therefore installed from the Wonderware Device
lntegration Products CD.
Wondenvare Training

3) How is FS Gateway Licensed?
FS Gateway is available for use with any Wonderware Product, at no additional charge. The
only stipulation is that it must be always used in conjunction with a Wonderware product, eithe~
in a server or client connection capacity.
4) What product client protocols are supported?

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

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

To remove NetDDE dependency
To provide connectivity to earlier versions of InTouch
e
To provide NT support which will allow connections to classic products that have not been
migrated to later Operating Systems.
To provide OPC connectivity to FS products (e.g. InTouch and Wonderware Application
Server)
To replace the OPCLink product used when connecting InTouch to OPC Servers.
e
To provide Wonderware Application Server data for 3rd party clients
e
To provide a mechanism for the transport of IAS data between two different Galaxies.
7) Does FS Gateway provide Galaxy to Galaxy communications with ArchestrA and the
Wonderware Application Server?
FS Gateway does provide the means for data access from an ArchestrA Object Attribute in
Galaxy A to an ArchestrA Object Attribute in Galaxy 6, in the same fashion that an Object
Attribute in Galaxy A could receive data from any OPC Server. The plan is that a future release
of the Wonderware Application Sewer will have built-in "Intergalactic Communications". FS
Gateway can still be used for this in the interim, but an even better solution is forth coming.
8) How is security controlled with FS Gateway?
..-
When used with the Wonderware Application Server, Role-based security is employed. That
means that a User is defined on the node where the FS Gateway is installed. That User
account is linked to an ArchestrA Role, which is linked to a Security Group, which is linked to
individual Object Attributes. Therefore, the defined user can only access those attributes
which it is assigned within the Galaxy. This needs to be managed carefully as any program
that utilizes that user account on the FS Gateway node, either locally or remotely can access
the associated attributes, with no specific knowledge of which external application is
accessing the Galaxy.
8-15
8-16
9) What are the common uses for FS Gateway?
Exposes InTouch as an OPC Sewer

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

The FS gateway is configured like any other DASewer, by using the ArchestrA System
Management Console or SMC.
12) What data is accessible in the Wonderware Application Sewer Galaxy via the FS Gateway?
The FS Gateway exposes 4 basic data types in a Galaxy. They are Boolean, String, Float and
Integer.
Wondeware Training

13) What is FS Gateway compatible with?
Client Products
e
DDE Clients [including FASTDDE V2 (pre-FactorySuite2000) and FASTDDE V3

(FactorySuite2000 Plus)]
SuiteLink Clients
OPC Clients (DA v2.05)
Server Products
e
DDE Servers
e
InTouch Data Source

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

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

Windows XP
e
Windows NT 4.0
e
Windows 2000
e
Windows 2003
For additional information or details on how to access and configure Factory Suite Gateway please
refer to the Wondeware FactorySuite Gateway User's Guide.
.-
8-17
8-18
Wondenware Training
Section 3 - Device lntegration Objects
Section 3 - Device lntegration Objects
Section Objective
Become more familiar with Dl Objects and their use with Wonderware Application Sewer.
This section provides familiarization with Dl Objects and their use with Wonderware Application
Server.
Introduction
Device lntegration (Dl) Objects are designed for applications that connect to Application Server.
They represent the application's network and devices, and mirror the actual device hierarchy. In
Application Server, Device lntegration (Dl) Objects are a subset of Automation Objects available in
the Template Toolset of the Integrated Development Environment (IDE). As a subset of these
Automation Objects, Device lntegration Objects consist of two parts:
e
Dl Network Object, which represents the communications port and are thus associated
with DA Sewers.
Dl Device Object, which represents the physical devices that make up a network.
Examples of Dl 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 lntegration objects are used to represent communications channels and field controllers.
As such, they are most oflen arranged in a hierarchy that models the physical hierarchy of the
network and devices on that network.
Device lntegration objects are designed to make it very easy to integrate DAServers into the
ArchestrA environment.
Therefore, deploying a Dl Network actually deploys the DASewer and its associated components
within the ArchestrA IDEIGalaxy. This facilitates the DAServer installation process for end-users.
Dl Object Advantages
Device lntegration Objects (Dl Objects) represent communication with external devices. Dl
Objects may be DlNetwork Objects (for example, the Redundant Dl Object) or Dl Device Objects.
Dl Objects (and their associated AppEngine) can reside on any 110, DA, or Automation Object
Server node in the Galaxy. Dl Objects allow connectivity to data sources such as DDE servers,
SuiteLink servers, OPC servers, and existing InTouch applications.
The advantages of using Dl Objects are as follows:
e
When ArchestrA IDE soflware is installed on a Wonderware Application Server, Dl objects
allow you to configure, deploy, and monitor DAServers from one centralized location.
o
Dl 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.
e
Dl 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.).
8-19
8-20
Dl 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.
Dl Objects in the ArchestrA IDE

Dl 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 lntegration area of
the Template Toolbox:
Device Integration
:.--
$InTouchProxy
$OPCClient
Cp $RedundantDIObject
The differences between the Application and Dl Objects are listed below:
e
Dl Objects are associated with a DAServer.
e
Dl Objects include some extra primitives in addition to the common Primitive (also hidden
by default. A special dialog provides access to the attributes developers might need to
override.).
e
Dl Objects include extra dependency files.
Dl Network Objects are hosted by an AppEngine, not an Area.
This impacts the Deployment view within the ArchestrA IDE.
rn
The Host must be deployed before the object can be deployed.
e
Dl Objects can be hosted by each other or by Dl Networks.
m
GUlDs tie the host and the hosted object together.
Dl Devices and Dl Network objects have extra tabs within their editors to configure
ScanGroups, BlockReads, and BlockWrites.
Wonderware Training
Multi-Node Applications
Section 1 - Application Redundancy
Lab 18 - Configuring Application Redundancy
Lab 19 - Configuring the Redundant Dl Object
Lab 20
- Convert to Network Environment
9-2

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

Section Objective
This section covers the concept of redundancy, how it can be configured and key points
to more effeclively implement this feature.
Understand the concept and functionality of Redundant Dl 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 Dl Objects
Redundant Configuration
Redundancy is important in processes that rely on continuous availability of information. There are
two basic types or topologies of redundant configuration:
Redundant Application Engines
Redundant Dl Objects
Redundant Application Engines

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

Maximumcheckpoint deitar buffered:
Maximum alarmstatec!mnger buffered:
Standby engine heartbeat period:
Active engine heartbeat period:
Maximum consecutive heartbeats missed from Active engine:
Maiimum lonrecutive heartbeats missed fronlstandby engine:
Maximum time t o maintaingood quality after failure:
Maximumtime to dlrrover partner:
Forced failover timeout:

Maximum checkpoint deitar buffered:
Maximum alarm state changes buffered:
Standby engine heartbeat period:
Adive engine heartbeat period:
Maximum conremtive heartbeats missed from Active engine:
Maximum canrel-utive heartbeats missed from Standby engine:
Maximum time to maintain good quality after failure:
Maximum time to discover partner:
Force failover command:
B R e r t a r t engine process when tranritioning from Active to Standby
Wondeware Training
Section I - Application Redundancy

The Application Engine that is enabled is considered the Primary engine of the redundant pair;
when you enable this engine, an additional (Backup) engine is automatically created.
Since an engine is required to run under a platform, the platform objects that sponsor the Primary
and Backup application engines need to be configured to use the dedicated NIC. This NIC
provides a high speed inter-connection link or Redundant Message Channel between the
platforms. The Message Channel is vital to keep both engines synchronized with alarms, history,
and checkpoint items from the engine that is in the Active Role. Each engine also uses this
Message Channel to provide its health, along with status information, to the other.
The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of
Application engines determines which of these in the pair will take the Active Role. The first engine
deployed takes the Active role while the other one takes the Standby role. The engines maintain
their current roles until a failure occurs. (A failure might consist of computer hardware lost or failed,
or a network card failure.) If a failure occurs, the engine with the Standby role assumes the Active
role and the engine that was in the Active role is given the role of Standby - Not Ready. When the
cause of the failure has been remedied, this engine assumes the Standby - Ready role.
Terminology
Two sets of terms are critical to understanding the functions of redundant objects. These are
described below.
During Configuration
Primary object: The object intended as the main or central provider of the functionality in the
run-time. For AppEngines, it is the object you enable for redundancy. For data acquisition, it is
the DlObject 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 DlObject 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 RedundantDlObject.
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 RedundantDlObject.
The PrimarylBackup and ActivelStandby 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 PrimaryIBackup DlObjects (the
data sources) must be separately created, configured and deployed. Also, you must create,
configure and deploy a RedundantDlObject to control failovers between the two data source
objects.
Wandeware System Platform 3.0 Course - Part 1
9-5

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

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

There are two types of redundant engine configuration: Dedicated and Shared load
Note: Depending on the order of deployment, the Primary or Backup engine may take the role of
Active Enaine. 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.
..Wondeware System Platform 3.0 Course - PaIi 1
9-7
9-8
Supervisory Network
AutomationObiect Server
AutomationObiect Server
Redundancy Message Channel
Control Network
In a Share
dun
lo 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,
throuohout for the aoolication can be ~ 0 m ~ r o m i S e d
Wonderware Training
Section 1 -Application Redundancy
Visualization Nodes
I
Automationobject S e w e r
Supewisorv Network
I
AutomationObject S e w e r
Redundancy Message Channel
Control Network
What Happens in Run-time

During initial deployment to its assigned WinPlatform, first code modules and other files for the
Primary AppEngine are deployed, followed by those files for its assigned ApplicationObjects.All of
these files are then deployed to the Standby AppEngine by the Active 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.
Wondeware Svstem Plalform 3.0 Course - Pati 1
9-9
9-10

AutomationObjects are always assigned to the Primary AppEngine in the configuration
environment. But in the run-time, AutomationObjects are always deployed to the Active
AppEngine whether or not it was initially configured as the Primary object. All files are then
deployed by the Active 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:
e
Active: The state of an AppEngine when it has communication with its partner object, its
partner is in Standby-Not Ready, Standby-Sync'ing with Active, or Standby-Ready state. A
Standby AppEngine transitions into this state when a failover condition has been detected.
In this state, an AppEngine schedules and executes deployed objects, sends checkpoint
data and sends subscriber list updates to the Standby AppEngine.
Active Standby not Available: The state of an Active AppEngine when it determines it
cannot achieve communications with its partner object. This could mean that checkpoint,
subscription and alarm state changes have not been successfully transmitted to the
Standby object, a heartbeat ping has not been received from the Standby object, or
notification is received that the Standby AppEngine has shutdown or is not running. If an
AppEngine is in this state, it 1) continues normal execution of hosted objects, 2 ) cannot be
manually switched to Standby state, and 3) while continuing to attempt communicate with
the Standby, does not attempt to send data to the Standby object.
Determining Failover Status: The initial state of a redundancy-enabled AppEngine when
it is first started. It has not determined yet whether it is the Active or Standby AppEngine.
Communication between the two AppEngines is attempted first over the RMC and then
over the primary network to make this determination. If communication cannot be made
after a certain timeout period, an AppEngine assumes the Active role if it has all of the
code modules and checkpoint file data to do so. Continued attempts are made at
communicating with its partner.
Standby Missed Heartbeats: The state of an AppEngine when 1) a heartbeat ping has
not been received from its Active partner within a configured timeout period, 2) the Active
AppEngine fails or hangs up, or 3) the Active AppEngine is shutdown on purpose. When in
this state, the Standby object attempts to determine whether or not the Active object has
failed. If a manual failover is initiated (by using the ForceFailoverCmd attribute), it will be
processed only if the heartbeats were missed over the primary network and not missed
over the RMC.
Standby - N o t Ready: The state of an AppEngine when one.pf several conditions occurs:
1) its has lost communications with its partner object or it maintains communications with
its partner but has missed checkpoint updates or alarm state changes from the Active
Wonderware Tra~nmg

AppEngine, 2) new objects are deployed to the Active AppEngine and necessary files
have not been installed on the Standby AppEngine yet, or 3) the Standby AppEngine has
lost communications over the RMC before it could complete synchronizing data. Typically,
the AppEngine's partner is in one of the following states: Active-Standby not Available,
Active, or Standby- Missed Heartbeats.
Standby Ready: The state of an AppEngine when is has completed synchronizing code
modules and checkpoint data with the Active AppEngine. In this state, the AppEngine
monitors for Active AppEngine failure by verifying heartbeat pings received from the
Active engine, checks that all files required for execution are in sync with the Active
engine, and receives the following from the Active AppEngine: checkpoint change data,
subscription-related notifications, alarm state changes, and history blocks.
Standby Sync'ng with Active: The state of an AppEngine when it is synchronizing code
modules with the Active object. If code modules exist on the Standby computer that do not
exist on the Active node, they are uninstalled, and likewise, any code modules that exist
on the Active node but not on the Standby node are installed. Once all code modules are
synchronized, the AppEngine transitions to Standby-Sync'd Code state.
Standby Sync'd Code: The state of a Standby AppEngine that has successfully
synchronized all code modules with the Active object.
Standby - Sync'd Data: The state of a Standby AppEngine when all object-related data,
including checkpoint and subscriber information, are synchronized with the Active object.
An object in this state typically transitions to Standby-Ready state.
Switching t o Active: A temporaiy, transitional state when a Standby AppEngine is
commanded to become Active.
Switching t o Standby: A temporary, transitional state when an Active AppEngine is
commanded to become Standby.
Unknown: The state of a redundant partner when a communication loss occurs between
AppEngines or when the partner AppEngine is not running.
Alarm Generation
When failover conditions occur, the ArchestrA system reports alarms to the Logger. These alarms
contain the following information:
e
The name of the AppEngine reporting the alarm.
e
The node name of the AppEngine reporting the alarm.
e
The state of the AppEngine.
e
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:
Wonderware System Platform 3.0 Course - P a d 1
9-1 1
9-12

-.. ...
Previous
! State
State
. . --.--.
Ready
'
Available
. .
....
Standby - Not
Ready
Active Standby Not
Available
Standby - Not
Ready
Entering Standby Ready
Active - Standby Not EnteringActive

Available
Standby Becomes
Active
During the next scan

of the Active Engine
Engine
--
Active
Engine
Active
Engine
Legend:
The Active A~oEnaine

monitors the status of the Standbv throuah 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:
e
Out of alarm
Unacknowledged
r
Unacknowledged-Return to normal
Acknowledged-Return to normal
e
Acknowledged
Timestamps are also preserved for alarms, including when:
The alarm was acknowledged
e
e
The alarm condition went true

The alarm condition went false
Finally, the following information is preserved for alarms:

e
An alarm was acknowledged
e
The message input by the operator when the alarm was acknowledged
Note: All alarm state information is collected and sent to the Standby AppEngine at the end of a
scan cycleand 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.
Wondenvare Training

When failover conditions occur, no more than 30 seconds of history data should be lost in the
transition from Standby to Active status. This is done through a combination of store-forward
operations when the historian is unavailable and normal reporting operations when it is available
Forced Failover
Failover can be forced to occur. Do this through the ForceFailoverCmd attribute of the AppEngine.
For instance, you can link multiple conditions in a script or use the Object Viewer utility to trigger a
forced failover.
Deployment
Primary and Backup AppEngines can be deployed together or individually. When they are
deployed together (no matter which object is actually selected for deployment), the Primary always
becomes the Active and the Backup becomes the Standby. When they are deployed individually,
the first one deployed becomes the Active.
Hosted ApplicationObjects are always deployed to the Active AppEngine. When deploying the first
of a redundantpair 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 AppEng~nef~rstand then deploy hosted objects to that
AppEng~ne,ensure that network communications to both target computers is good before
deDl0vinCl the Pr~mawADDEnaine. Otherwise, errors mav occur.
In the run-time environment, either the Primary or Backup AppEngine can become the Active or
Standby depending upon failure conditions on either computer.
Before deploying the Primary and Backup AppEngines, all configuration requirements must be
met. Each AppEngine must be assigned to a separate WinPlatform. A valid redundancy message
channel (RMC) must be configured for each WinPlatform. To deploy the Primary and Backup
together, select Include Redundant Partner in the Deploy dialog box. This option is not available
when doing the following operations:
Cascade deploy from the Galaxy
e
Multiple object selection deploy
e
Deployment of the WinPlatform that hosts the Primary or Backup AppEngine
sP
Wondenvare System Plafform 3.0 Course - Part 1
9-13
9-14

See the following table for a matrix of allowed operations based o n specific conditions.
.
~.
-. ..
-. . --- .
Deploy Both Primary
, Cascade Deploy
I and Backup Objects
Allowed
. . -.,-.
.
,
. . .--.
Yes
Yes
... .. . , .
Condition
-.
..
..
Backup AppEngine's host Winplatform configured for
failover and deployed.
Backup AppEngine in error state.
... .-.
Yes
Yes
No
Yes
Yes
Yes
Deploy from Galaxy node.

Deploy from Winplatform hosting Primary AppEngine.
No
Yes
No
Yes
Multiple object selection deploy.

Backup AppEngine's host Winplatform not configured for
failover and not deployed.
No
No
No
Yes
Deploy from Backup AppEngine.
Yes
Yes
Deploy from Primaly AppEngine.
Yes
Yes
Backup AppEngine's host Winplatform not deployed.

Backup AppEngine's host Winplatform not configuredfor
failover and deployed.
Undeploying redundancy pairs of AppEngines is similar to any regular object undeployment. The
Active and Backup AppEngines can b e 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: Undeployrnent of any AutomationObjects, including redundant AppEngine pairs, does not
uninstall code modules for that object from the hosting computer. Code modules are uninstalled
onlv when the WinPlatform is undedoved.
Wondeware Training
>

Errors and Warnings
Certain requirements (for instance, the order you configure an object pair for redundancy) are
validated by the system infrastructure. If a requirement is not met, you may see error messages
that describe the following:
You can configure an AppEngine for redundancy before its associated WinPlatform, but if
you do, you will get an error message that the Platform (specifically, the RMC) is not
configured yet.
If the RMC IP Address parameter is not configured in both hosting WinPlatforms, then the
configuration state of both Primary and Backup AppEngines changes to Error, with a
message indicating that the host WinPlatform is not configured with the network adapter
required for redundant communications. When the RMC IP Address is configured and the
WinPlatforms are checked in, the hosted AppEngines are automatically revalidated and
the Error state is resolved. If hosted AppEngines are checked out, they are not
revalidated.
If both Primary and Backup AppEngines are assigned to the same WinPlatform and an
attempt is made to deploy both engines, both the Primary and Backup will fail to deploy
with a message noting that the Primary and Backup objects must be hosted by different
WinPlatforms. Reassign the Backup object to another WinPlatform and deploy it
separately.
If both the Network Address and RMC IP Address parameters in the WinPlatform's
editor address the same network card, you will get a warning message when you save the
configuration. These two parameters must address different network cards.
Wondenvare System Platform 3.0 Course - Pad I
9-15
9-16
Wondenvare Training
lnfenfionally left blank -
Lab 18 - Configuring Application

edundancy
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 reauired second network card is alreadv installed in both comouters.
Note: Because of the additional hardware and network requirements necessary, this lab is usually
executed as an Instructor demonstration only.
Objectives
Configure a second network connection in Windows as the redundant message channel
e
Configure the $Winplatform and $AppEngine object for redundancy
e
Create a deployment model for redundant engines
e
Force a failover on a redundant system

Configure Windows network connections

Note: The followina confiauration needs to be done on BOTH cornDuters.
1. Rename the network connections as follows:
Local Area Connection
to ArchestrA
Local Area Connection 2
to RMC
2. Use the network connections Advanced Settings to make sure that the ArchestrA
connection is access before the RMC connection.
Wondeware System Platform 3.0 Course - Pafl 1
9-17

3. Assign an IP address to the RMC in a different subnet than the ArchestrA connection.
Important! The IP address for the RMC connection on both computers must be different but in
the same subnet.
4. On the Advanced setting for TCPIIP, configure the RMC connection to @ Register this
connection's addresses in DNS.
Configure the Galaxy for Redundancy

5. Undeploy the galaxy.
6.
Configure the ABGRPlatform object's Redundancy message chann~

own RMC IP address.
ddress with its
7. Create a new instance of the $ABPlatform template using the default name and assign it to
the ABControlSystem area.
8. Configure the ABPlatform-001 object with the name of the second computer and its own
RMC IP address for the Redundancy message channel IP address.
9.
Configure the ABAppEngine object for Redundancy and assign its backup to the
ABPlatform-001 object.
Test Redundancy
10. Deploy the galaxy.
11. Using the watch list created in Lab 5, add a new watch window called Redundancy and add
the following attribute references:
e
ABAppEngine.Host
Wondenvare Training

13. Force a failover in the system and monitor the data using Object Viewer and the different
watch windows created during the class.
Wonderware System Platform 3.0Course - Pad1
9-19
9-20

please refer to the Summary Lab lnstructions on the previous pagefs).
Configure Windows network connections

Note: The following configuration needs to be done on BOTH computers.
1 . Open Windows Network Connections by double-clicking on Start 1Control Panel 1 Network

Connections.
The Network Connections window is displayed.
Wondenvare Training

2.
3.
Rename network connections as follow:

Local Area Connection
to ArchestrA
Local Area Connection 2
to RMC
From the Advanced menu, select Advanced Settings.
LAN or High-speed Internet
ArchesbA
rnnnert;ri
Wondeware System Plafiorm 3.0 Course - Parl 1
9-21
9-22

4. On the Advanced Settings dialog box, Adapters and Bindings tab, make sure that the
ArchestrA connection is access before the RMC connection and then click the OK button to
close the dialog box.
Tip: You can use the
and
buttons to arrange the access order.
Connect~onsare l~stedin the order in wh~chihey are accessed by

netwokservlces
Wonderware Training

5. Right-click on the RMC connection and select Properties
Repir
Bridge Connections
Create s o r t a r t
Qd&
6. At the RMC Properties dialog box, on the General tab, select the Internet Protocol (TCPIIP)
item and click the Properties button.
9-23
9-24

7. At the Internet Protocol (TCPIIP) Properties dialog box select the Use the following IP
address option and assign an IP address in a different subnet than the ArchestrA connection.
Click the Advanced button to continue
Important! The IP address for the RMC connection on &computers
in the same subnet.
must be different but
Note: In this example the first computer will have an IP address of 192.168.1.1 and the
second one will have an IP address of 192.168.1.2. Both will be have a subnet mask of
255.255.255.0
You can getIP setbngs ass~gnedautomabmly if your network supports

i h ~ mpab~hty.
s
Oiherw~e,you need to ask your network adm~n~strator
for the appropriate I P sethngs.
Wondenvare Training

8. On the Advanced TCPIIP Settings dialog box, select the DNS tab and uncheck the Register
this connection's address in DNS box.
D& server addresses, in order o f use:
9.
OK button to close the Advanced TCPllP Settings dialog box.

Click the OK button to close the Internet Protocol (TCPIIP) Properties dialog box,
Click the
Click the Close button to close the RMC Properties dialog box.
Wondenvare System Platform 3.0 Course Parl 1
9-25
9-26

Configure the Galaxy for Redundancy
10. Undeploy the ABGRPlatForrn object.
11. Double-click the ABGRPlalform instance to open its configuration editor.

On the Redundancy section:
Redundancy message channel IP address: 192.168.1.1 [IP address assign to the RMC
connection on the first computer]
Redundanry ptirnaw channel port:
~ e d u o d a n qmessage channel IP address: 192.168.1.1

~ messagedchannel port:
~
1
~ mo1
moo
iff
d4
14. Create a new instance of the $ABPlatForm template.

Leave the default name and assign it to the ABControlSystem area.
Wondeware Training

15. Double-click the ABPlalform-001 instance to open its configuration editor.

Network address: [Name of the second computer]
On the Redundancy section:
Redundancy message channel IP address: 192.168.1.2 [IP address assign to the RMC
connection on the second computer]
Neh.iorkaddrerr:
1
0
802
Hlstoryrtorefonvard dlrebow
1024
-
Mlnlmvm R4M:
Oinrouch alarm lvowdrr

Alarm arcer (blank for all)
/ M E
rg
10000
stabrtlrsaveragepenod:
,.ne*"deacv
,@
Redundanry message channel IPaddiesr:
192.168.1.2
Redundanry message channel pa*
moo1
/ 6
Redundancy primary channel port:
3WW
18. Double-click the ABAppEngine instance to open its configuration editor.
9-28

19. Select the Redundancy tab and configure the object as follows:
Enable redundancy: checked
Forced hilovertimeout:
1 mr
Maximum che&pkpolnt deitan buffered:
j
O
Mm.mum alarm state changes buffcred:
EcIIIzl
q
q
q
Standby engineheartbeat pedod:
]loooms
/
i$l
A N v e engine heartbeat period:
1 7 - 1
'33
ms
Maximum ronsemtiue heartbeats missed from Adive engine:
I$@
Maximum consecutiveheartbeats mirred bomstiiandby engine:
tp
~ a x i m u mtime t o maintain good qualie, afierfaiiure:
(141007rnr
,@
~axjmunitime t o discover partner:
p i o O l ms
'9
';3
Fmefailovci command:
21. On the Deployment view, assign the automatically created ABAppEngine (Backup) object to
the ~ B ~ l a k o ; m - 0 0 1instance:
~l... ABGalaw
1'6
,,- ~.
.&Unassigned Host
@
. @
. ABGRPlaLform
ok @ ABAppEngine
h...@ AB
'..... 'W
Wonderware Training
Test Redundancy
22. Deploy the galaxy by right-clicking the name of the galaxy and selecting Deploy.
23. Open Object Viewer by right-clicking the ABAppEngine instance and selecting View i n
Object Viewer. If you closed Object Viewer before, you can use File I Load Watch List to
24. Right-click in the Watch List (bottom section of Object Viewer) and select A d d Watch
rename the watch list to ~ e d i n d a n c ~ .
26. Add the following attributes to the watch list:
Host
Wondeware System Platform 3.0 Course - Par7 7
9-30

28. Force a failover to the second computer by writing true to the ForceFailoverCrnd attribute of
the AppEngine.
You can use the Mixer watch window to verify that the objects are running properly
29. Failover the system doing any of the following on the second computer:
e
Unplug the power cable
Shut down Windows
e
Disconnect both network cables at the same time.
ABGWlatfoirn
ABAppEngine.Hosi
ABnppEngine.Redundanc/.Identib
Piirnary
ABA~~Enoine.Redunda~~~.Sbhls
Active -Standby not Available
~ ~ k p p ~ ~ i n e . ~ e d u n d a n & . ~ a r t n e r ~ l a t fABPlatfarrn-001
om
ABAppE~ine.Redundancy.PartnerStatus
Unknown
ABAppE~ine.RedundancycyFaiIoverOc~rred 6 l s e
ABAppE~ine.Redundancyc/ForceFailoverCrnd false
C0:Good
C0:Good
CO:Good
C0:Good
CO:Good
CO:Good
Ok
Ok
Ok
Ok
Ok
Ok
You can use the Mixer watch window to verify that the objects are running properly.
Wondeware Training
Section Objective
This section covers the concept of redundancy, how it can be configured and key points
to more effectively implement this feature.
Understand the concept and functionality of Redundant Dl 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 Dl Objects
Redundant Dl Objects
Application Engines can host Redundant Device Integration Objects (Dl Objects). The
RedundantDlObject monitors and controls the redundant DlObject data sources. Unlike redundant
AppEngines, individual DlObject data sources do not have redundancy-related states. For all
intents and purposes, they function as standalone objects.
Only one DlObject data source provides field device data through the RedundantDlObject at a
time. Both data sources must have commonly configured DAGroups which are reflected in and
channeled through the RedundantDlObject, which monitors the two DlObject 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 Dl Object is a DlNetwork Object used to enable continuity of 110 information from
field devices. The Redundant Dl Object provides the ability to configure a single object with
connections to two different data sources. If the primary data source fails, the Redundant Dl
Object automatically switches to the backup data source for its information. There is a one-to-two
relationship between an instance of the Redundant Dl Object and the running instances of the
source Dl objects; that is, for each Redundant Dl Object, a pair of source Dl Objects is deployed.
Wondeware System Platiorm 3.0 Course - Pad 1
9-31
9-32
Workstations
Redundant
Dl Object
Supervisory Network
u,
-7
pplicatibn Server
Configuration
Control Network
:
:
I
:
::
RedundantDlObjects
Configure redundancy in data acquisition objects in the ArchestrA IDE through their editors. Data
acquisition redundancy objects (two DlObjects and the RedundantDlObject) do not have
redundancy-related deployment statuses.
In data acquisition redundancy, you must configure all three components: a Primary DlObject data
source, a Backup one, and a Redundant DlObject.
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
t w o DlObject data sources and the RedundantDlObject.
The main focus of RedundantDIObject configuration is:
Setting the Primary Dl Source and Backup Dl Source on the General tab of the object's
editor.
Setting up the common scan groups, and block read and block write groups on the
respective tabs OF the object's editor.
Wonderware Training
Note: You must configure at least one scan group before you can deploy the RedundantDlObject.
Also, only scan, block read, and block write groups shared by the Primary and Backup DlObjects
should be ~ 0 n f i ~ u r eindthe RedundantDlObiect.
Deployment
Deployment for data acquisition redundancy is the same as individually deploying unrelated
objects. No special conditions apply to each DlObject data source and the RedundantDlObject
What Happens in Run-time

The three objects in the data acquisition redundancy scheme (RedundantDlObject and its two
DlObject 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 RedundantDlObject monitors the status of the DlObject data sources, and
handles the switching from Active to Standby object when failure conditions arise.
Wondenvare Svstem Platform 3.0 Course Pad 1
9-34
Wondeware Training
Infentionally left blank -
Lab 19 - Configuring the Redundant

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 a PLC.
Note: Because of the additional hardware and network requirements necessary, this lab is usually
executed as an Instructor demonstration only.
Objectives
e
Configure and use the $RedundantDlOObject
e
Create a deployment model for redundant Dl object
0
Force a failover on a redundant Dl system

Configure t h e Redundant Dl Object
1. Create two new instances of the $ABAppEngine template, name them ABAppEngineDll
and ABAppEngineDI2 and assign them to the ABControlSystem area.
2. Host ABAppEngineDll on the ABGRPlatform platform and ABAppEngineD12 on
ABPlatform-001 platform.
3.
Rename the Incontrol instance as Dl01 and host it on the ABAppEngineDll engine.
4. Create a copy of the Dl01 object by repeating Lab 6 but naming the object D102. Assign the
new object to the ABControlSystem area and host it on the ABAppEngineDI2 engine.
5.
Derived a new template from the $RedundantDlObject object, name it

$ABRedundantDlObject, and assign it to the A B Training template toolset.
Wonderware System Platform 3.0 Course Pad1
9-35
9-36

6.
Create an instance of the $ABRedundantDlObject template and name it Incontrol
8.
Primary Dl source:
Dl01
Backup Dl source:
Dl02
On the Scan Group tab, copy the common scan groups and attributes from the primary or
backup Dl sources.
9. Host the Incontrol instance on the ABAppEngine object.
Test the Redundant Dl Object

10. Deploy the ABAppEngineDII, ABAppEngineDI2, D101, Dl02 and Incontrol objects.
11. Using the watch list created in Lab 5, add a new watch window called RDlO and add the
* InControl.DISourcePrimary
e
InControl.DISourceBackup
InControl.DISourceActive
e
InControl.DISourceStandby
e
InControl.StatusPrimaryDlSource
InControl.StatusBackupDlSource
.
e
e
InControl.ConnectionStatus
InControl.SwitchReason
InControl.ForceFailoverCmd
13. Force a failover in the system and monitor the objects using Object Viewer and the different
watch windows created during the class.
Wonderware Training

Configure the Redundancy Dl Object

1. Create two new instances of the $ABAppEngine template.
Name them ABAppEngineDll and ABAppEngineDIZ and assign them to the
ABControlSystem area.
2. In the Deployment view, host ABAppEngineDll on the ABGRPlatforrn platform and

ABAppEngineDIZ on ABPlatforrn-001 platform.
@-
I
3.
i& Unassigned Host

ABGRPlatForm
-I F - #
'..... FE)
ABAppEngine (Backup)
Undeploy the Incontrol instance, rename it Dl01 and host it on the ABAppEngineDll
engine.
Wonderware Svslem Plalform 3.0 Course - Pad 1
9-37
9-38
4.
Use Lab 6 -Connecting t o the Field to create another device integration object, but name it
Dl02 instead of Incontrol. Assign it to the ABControlSystem 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.
5. In the Deployment view, host the Dl02 object on the ABAppEngineD12 engine
-;.---- @ ABAppEngine (Backup)
Wonderware Training

6. Create a derived template from the $RedundantDlObject template, name it
$ABRedundantDlObject and assign it to the A B Training template toolset.
&Template Toolbox
..............
........... - ......
J? X
7. Create an instance of the $ABRedundantDlObject template, name them Incontrol and

assign it to the ABControlSystem area
8. Double-click the Incontrol instance to open its configuration editor.
W o n d e w r e Syslern Plafform 3.0 Course - Par/ I
9-39
9-40

Primary Dl source:
Dl01
Backup Dl source:
Dl02
~arkD
~I psource:
AS
0102
'B
10. Select the Scan Group tab and click on the Copy Common Scan Groups button.
On the Copy Common Scan Groups dialog box, click the OK button to accept tagname as
the scan group for the new Incontrol object.
Wondenvare Training

11. Click on the Copy Attributes From Primary button.
Copy CommmScan Groups
Copy Attributes From Primary
Copy AtttibutesFrom Backup
Wondewre Svsfern Platform 3.0 Course -Pad ?
9-42

13. In the Deployment view, host the new Incontrol object on the ABAppEngine engine.
-;-.-..a
I*"
-
UnassignedHost
6.Fiil
ABGRPlafform
Y
8...
ABAppEngine
. @
.
1 1.- & ABControl5ystm
61 ABDischarge
@ $1ABIntake
. Cfl. & ABLinel [ABLinel]
i: @: . & ABLine2 [ABLine2]
;
& ABProduction
I 6.;
'.....p
ABAppEngineDIl
i..... &
I,
I @ ABPlatform-001
;.-- @ ABAppEngine (Sackup)

&.--@ ABAppEngineDI2
i.....
Test the Redundant Dl Object

14. Deploy the ABAppEngineDll object on cascade.
15. Deploy the ABAppEngineDI2 object on cascade,
16. Deploy the Incontrol object
17. 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.
rename the watch list to RDIO.
Wondeware Training

20.
Add the
following attributes to the watch list:
DlSourcePrirnary
SwitchReason
ForceFailoverCrnd
InConbol.ConnecticnStab&
1nCmbol.SwitchReason
Connected
Unhown
22. Force a failover to the second
integration object by writing true to the

Dl Object. You can use the Mixer watch
are running properly.
device
ForceFailoverCmd attribute of the Redundant

window to verify
that the objects
- -
AttnbuteReference
InConb~l.DISwrcePT~mary
1nConbol DISwrceBadmc
1nConbol.DISwrceActive
1nCmbol.DISwrceStandby
~
~~
InCcnbol.StahizPTim~y0ISouice
1nConbol.Sta~sbckupDISource
1nConhol.ConnecbbnStatus
1nConbol.SwitchReason
1nC~bol.For~eFailo~mCmd
] value
DIOl
DIOZ
DIO2
DIOl
Connected
Connected
Connected
ForceFailover
fake
guality
C0:Good
C0:Good
C0:Good
C0:Good
C0:Good
C0:Good
C0:Good
C0:Good
C0:Good
1 stahis I
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Wonderware Sysfem Platform 3.0 Course -Pad 1
9-43
9-44

23. Failover the system doing any of the following on the second computer:
e
Unplug the power cable
0
Shut down Windows
e
Put the D l 0 2 object off scan
1nConbd.DISo~rceActive
1nConbol.DIsourceStandby
1nConbd.Stab~PrimaryDISource
InConbol.StamsBahpDISource
1nConbol.ConnectionStabs
1nConbol.SbMtciResron
1nConbd.ForceFailoverCmd
DI02
DIOl
Dl02
Connected
Unhown: C o r n Error p1Source not accessible)
Connected
Unlnobm: C o r n Enor (DISource not accessble)
ialse
C0:Mod
C0:Good
C0:Good
C0:Goad
C0:Good
C0:Mad
C0:Gwd
C0:Good
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
You can use the Mixer watch window to verify that the objects are running properly.
Wonderware Training

Section Objective
This sect'on deals w:th 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 (Nodel) that will contain the
Bootstrap, the ArchestrA IDE, and a Galaxy Repository. Three other nodes will be connected to
the Galaxy on Nodel. 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:
9-45
9-46

Hardware and Associated SoRware
Application
inTouch 10.0
Galaxy Repositwy (GR)
Coniabbs
Bwlstmp
Galaxy Reposjtory (GR)
COntSinf
Histarian
Present on
each machine
Standalone Configuralion
PLC
The networked environment that you are migrating to is illustrated as follows:
PLC
I
............
G<W3
GfH2
IhTolzh 10.0
InTw3,lO.O
GlNI
InTorsh 30.0
Galaxy R e p i l o t y
InTcuch
Wonderware Training
Section 3 - Multi Node Awwlication

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:
e
Create the Galaxy to which all other nodes will connect.
e
Create Platforms for other galaxy members.
e
Rename the node.
e
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.
.-
Wondeware Sysfem Plafform 3.0 Course - P a d 1
9-47
9-48
Wonderware Training
Intentionally left blank -
Lab 20 - Convert to Network Environment
Lab 20 - Conve
nvironment
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 person1
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:
Configure a galaxy for a multi-node environment.

Following is a summary of the general steps you will complete for this lab.
Note: For this lab there are no detailed steps on the following pages.
Preparation
Note: This section is to be performed by everyone except where noted.
1. Undeploy the galaxy.
2.
Export all your templates to a file called MyTemplates.aaPKG.
3. Galaxy Master: Export the Incontrol instance to a file called InControLaaPKG.

Note: If you did Lab 19, then export both the 110 1 and 110 2.
Wondeware System Plafform 3.0 Course Parl 1
9-49
9-50
Module 9 - ~ulti-
ode A p p l i c a t i o n s
Create a N e w Galaxy
Note: This section is only to be performed by the Galaxy Master.
4.
Create a new galaxy named MultiNodeGalaxy
5. lmpoit the MyTemplates.aaPKG and 1nControl.aaPKG files.

6.
Create an area instance named ControlSystem and assign the Incontrol object to it.
7. Create a platform instance named ABPlatform and assign it to the ControlSystem area.
8.
Create an engine instance named AppEngineDl and assign it to the ControlSystem area.
9. On the Deployment view:
Host AppEngineDl on ABPlatform.

Host Incontrol on AppEngineDI.
Host ControlSystem on AppEngineDI.
10. Deploy the ABPlatform object on cascade.
11. Configure the galaxy's security Authentication Mode to Galaxy.
12. Create a user account that belongs to the Administrator role for each member of the team.
Setup t h e Platforms
Note: This section is not to be Derformed bv the Galaxv Master.
13. Use the ArchestrA IDE to connect to the MultiNodeGalaxy galaxy in the Galaxy Master's
computer using your designated user account.
14. Import the MyTemplates.aaPKG file
15. Create a platiorm instance named ABPlatform and configure it with your local computer's
name. Assign it to the ControlSystem area.
.
16. Deploy the ABPlatform object on cascade.
Wonderware Training
Lab 20 - Convert to Network Environment
Test the Galaxy

Note: This section is to be performed by everyone.
17. Create an engine instance named ABAppEngine, assign it to the controlsystem area and
host it on your ABPlatform object.
18. Create an area instance named ABLine and host it on your ABAppEngine object.
19. Create an instance of your mixer template and name it properly with the valid 3-digit mixer ID
at the end (ABMixer-XXY) as identified in Lab 2. Host it on your ABLine area.
20. Deploy your ABAppEngine object on cascade
21. 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.
Wondeware Syslem Platform 3.0 Course - Pad l
9-51
9-52
Wonderware Training
lntenfionally left blank -
A-2
Appendix A - Wonderware Application Server Glossary
- lnfentionally left blank -
Wondenvare Training
Appendix A
- Wonderware Application Server Glossary
Application
A collection of objects within a Galaxy Repository that performs an automation task. Synonymous
with Galaxy. There may be one or more applications within a Galaxy Repository.
Application Engine (AppEngine)
A scan-based engine that hosts and executes the runtime logic contained within
AutomationObjects.
Applicationobject
An AutornationObject 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 Wondeware 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 Integrated Development Environment (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 lntegration Object
Templates, including their configuration and run-time implementations. Includes a developer tool
used to build Dl Objects and create unique Domain Objects that interact with Dl 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 AutornationObject
Attribute Reference String
A text string that references an attribute of an AutomationObject,
Wondenvare System Platform 3.0 Course Part 1
A-3
A-4

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 Sewer (AOS)
A computer that hosts one or more application engines and associated automation objects. A
Wondeware Application Sewer 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 fol
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 afler 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
soflware 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-inlcheck-out, deployment, and importlexport.
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
.-
Wondeware Training

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 =
Linel.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 lntegration Objects (DlObjects). 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 110 Servers but with more advanced capabilities.
Data Access Server Toolkit (DAS Toolkit)
A developer tool used to build Data Access Servers (DAServers).
Deployment
The operation which instantiates an automation object instance in the ArchestrA runtime. This
action involves installing all the necessary software and instantiating the object on the target
platform with the objects default attribute data from Galaxy Repository.
Deployment View
The part of the Applications View in the IDE that shows how objects are physically dispersed
across Platforms, Areas and Engines. This is a view of how the application is spread across
computing resources.
Derivation
The creation of a new Template based on an existing Template.
Derivation View
The part of the Applications View in the IDE that shows the parent-child relationship between base
templates, derived templates and derived instances. A view into the genealogy of the application.
Derived Template
Any template with a parent template.
Device lntegration Object (DlObjects)
An AutomationObject that represents the communication with external devices or software.
DlObjects run on an Application Engine, and include DlNetwork and DlDevice objects.
DlDevice Object
An object that represents the actual external device (for example, a PLC or RTU) that is
associated with a DlNetwork Object. It provides the ability to diagnose and browse data registers
of the DAGroups for that device.
DlNetwork Object
An object that represents the network interface port to the device via the Data Access Sewer or
the object that represents the communications path to another software application. It provides
diagnostics and configuration for that specific network card.
A-5
A-6

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, Tankl .OutletValve,
where an object called Tankl 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 Sewer, the standard Historian is IndustrialSQL
Sewer.
Host
The parent instance of a child instance in the deployment view. (Example: a Platform instance is a
Host for an AppEngine instance).
Wondenvare Training

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 IServer
Platforms, (b) by real 110 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 (110 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.
lntegrated Development Environment (IDE)
The lntegrated 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 Sewer for its data source. In addition, standard InTouch v8.0 runtimes can leverage
the Wonderware Application Sewer with the addition of a Platform license.
I10 Count
Number of 110 points being accessed into the Galaxy. 110 points are real I10 and are not equivalent
to InTouch tags. 110 count is based on the number of 110 points that are configured through an
OPC Sewer, I10 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 ActiveFactoryTMthat 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 ~p&cationsView in the IDE that shows how objects are arranged to describe the
physical layout of the plant and supervisory process being controlled.
A-7
A-8

Object
Any template or instance found in a Galaxy Database. A common characteristic of all objects is
they are stored as separate components in the Galaxy Repository.
Object Extensions
The capability to add additional functions to an Automation Object while not altering the objects
original behavior. Can be added to derived templates and object instances. They include Scripts
User Defined Attributes (UDAs) and Attribute Extensions.
Object Viewer
A utility in which you can view the attribute values of the selected object in run-time. This utility is
only available when an object is deployed. Object Viewer provides the user with diagnostic
information on Application Objects for the purpose of detecting performance parameters, resource
consumption and reliability measurements. In addition to viewing an object's data value, data
quality and the communication status of the object, you can also modify some of it's attributes for
diagnostic testing. Modifications can include adjusting timing parameters and setting objects in an
execution or idle mode.
OffScan
The state of an Object that indicates it is idle and not ready to execute its normal runtime
processing.
OnScan
The state of an Object in which it is performing its normal runtime processing based on a
configured schedule.
Package Definition File (.aaPDF)
The standard description file that contains the configuration data and implementation code for a
base template. File extension is .aaPDF.
Package File (.aaPKG)
The standard description file that contains the configuration data and implementation code for one
or more object instances or Templates. File extension is .aaPKG.
Platform Count
Number of PCs in the Galaxy. Each Workstation and/or Server communicating directly with the
Application Server requires a platform to be part of the Galaxy Namespace. This includes each
InTouch 9.0 or higher and InTouch View 8.0 or higher client. Each InTouch Terminal Services
Session needs IAS Terminal Services Session License. A Platform License includes a per seat
FSCAL2000 with Microsoft 2000 SQL Server CAL. Stand-alone computers that only host Historian
Servers or remote DA Servers do not need a platform license.
Platform Manager
The Platform Manager provides Galaxy application diagnostics by allowing you to view the runtime status of some system objects and to perform actions upon those objects. Actions include
setting platforms and engines in an executable or idle mode and starting and stopping platforms
and engines. This utility is an extension snap-in to the ArchestrA System Management Console
(SMC).
Platform Object
An object that represents a single computer in a Galaxy, consisting of a system wide message
exchange component and a set of basic services. This object hosts all Application Engines.
PLC
Programmable logic controller.
.-
Primary Application Engine

The object created by the ArchestrA infrastructure when the Backup object has been created
through Redundancy. See Redundancy for further detail.
Wondeware Training
Aooendix A - Wonderware Aoalication Server Giossarv
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 lnTouchG3 HMI. For example, there
is a Proxy Object that enables the Wondenvare Application Server to access an OPC server.
Redundancy
During Configuration
e
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 DlObject 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 DlObject 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 RedundantDlObject.
e
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 RedundantDlObject.
e
Redundant Dl Object
The RedundantDlObject monitors and controls the redundant DlObject data sources. Unlike
redundant AppEngines, individual DlObject 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 InTouchG3 (WindowViewerT") function that provides the viewing of data from the configuration
of the application in InTouch development (WindowMaker).
W o n d e ~ a r eSystem Plaliorm 3.0 Course - Pad 1
A-9

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
Wondeware Application Server security is applied to the Integrated Development Environment
(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 Microsofl 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 administrationlmanagement 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 = V l l O l and its
HierarchicalName = Linel.Tank1.InletValve.
Template
An object containing configuration information and soflware templates used to create new Derived
Templates andlor 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.
Wondenvare Training
lant Model lanning
iagrams
B-2
Appendix B
- Plant Model Planning Diagrams
Wondeware Training
Infentionally left blank -
The Plant Model Planning Diagrams are displayed on the following pages.
Wondenvare System Plaiiorm 3.0 Course Part f
B-4
Appendix B -Plant Model Planning Diagrams
W o n d e w r e Training
B-6
Appendix B - Plant Model Planning Diagrams
)
I
lh
ui
Wondeware Training
6-8
Appendix B
- plant Model Planning Diagrams
- Inienfionally left blank -
Wonderware Training

ArchestrA Training Manual - Class 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ArchestrA Training Manual - Class 1

Uploaded by

Copyright:

Available Formats

Revision A

INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

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

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

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

Lab 13 - DDESuiteLinkClient Auto Reconnect

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

Wonderware System Platform 3.0 Course -Part 1

Wonderware System Platform 3.0 Course - Part 1

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

Device lntegration Products ..................................................... 8-1

Appendix A Wonderware Application Server Glossary ...............................

- System Requirements, Licensing and Support

Section 6 - Application Planning

Section I Course lntroduction

Section I- Course lntroduction

Model the plant floor using automation objects

Wondeware System Platform 3.0 Course -Pad 1

Module 2 - Application Infrastructure

Section I- Course Introduction

Module 3 -Application Objects

Module 4 - Extending the Objects

Wonderware Svstern Platform 3.0 Course Parl 1

Module 5 - Alarms and History

Module 7 - Galaxy Maintenance

Module 8 - Device Integration Products

Section 2 - Data Access Servers

Section 1 - Course Introduction

Section 3 -Device Integration Objects

Module 9 - Multi-Node Applications

Wondenvare System Platform 3.0 Course -Pad 1

Wonderware Software Solutions

Microsoft@ Technologies, such as Microsoft Windows@, Microsoft SQL Server, and

Section 1 - Course Introduction

Wonderware Svstem Platform 3.0 Course -Pad 1

Wonderware System Platform

Section I-Course Introduction

These soflware solutions:

Wondeware System Platform 3.0 Course -Pad 1

Supervisory HMI Software Solutions

Wonderware System Platform

Section I- Course Introduction

Wondeware Syslem Plalform 3.0 Course -Part 1

Section I- Course introduction

The supervisory control and manufacturing information environment is served by a variety of

Wanderware System Plafform 3.0 Course - Parl 1

Section 2 - Wonderware System Platform

Section 2 - Wonderware System Platform

Application development services

Industrial Domain Services

Wondenvare System Platform 3.0 Course -Part 1

Data-level security to protect plant equipment

Software and Device Connectivity Services

Enterprise resource management (ERP) and business systems

Information and Data Management Services

Section 2 - Wonderware Svstem Platform

Information-Delivery and Visualization Services

Wondeware System Platform 3.0 Course -Pad 1

Visualization and HMI

Application Development Services

Section 2 - Wondenvare System Platform

How the application is related to the facility or plant

SQL Server, BizTalk server

System Management and Extensibility Services