SystemPlatformPart1RevA GOLD EntireManual

Training ManualRevision AApril 2009

Part Number 11-GM-10012

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

System Platform - Part 1Wonderware Application Server 3.1 and Device Integration Products

INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

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

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

Invensys, Wonderware, ArchestrA, Factelligence, IntelaTrac, InBatch, InControl, IndustrialSQL Server, InSQL, InTouch, InTrack, QI Analyst, SCADAlarm, SuiteLink, SuiteVoyager, WindowMaker, WindowViewer are trademarks and registered trademarks of Invensys plc, its subsidiaries and affiliated companies. All other brands and product names may be the trademarks or service marks of their respective owners.

Table of Contents 3

Table of Contents

Module 1 Introduction .................................................................................1-1Section 1 – Course Introduction......................................................................... 1-3Section 2 – Wonderware System Platform ...................................................... 1-17

Lab 1 – Creating a Galaxy......................................................................... 1-39Section 3 – The ArchestrA IDE ........................................................................ 1-45Section 4 – Automation Objects....................................................................... 1-67Section 5 – System Requirements, Licensing and Support............................. 1-79Section 6 – Application Planning ..................................................................... 1-89

Lab 2 – Identifying the Mixer ..................................................................... 1-95

Module 2 Application Infrastructure ..........................................................2-1Section 1 – The Plant Model.............................................................................. 2-3

Lab 3 – Creating the Plant Model ................................................................ 2-5Section 2 – The Deployment Model................................................................. 2-13

Lab 4 – Creating the Deployment Model ................................................... 2-15Section 3 – The Runtime Environment ............................................................ 2-25

Lab 5 – Using Object Viewer ..................................................................... 2-29Section 4 – Connecting to the Field ................................................................. 2-39

Lab 6 – Connecting to the Field ................................................................ 2-49

Module 3 Application Objects ....................................................................3-1Section 1 – Templates and Instances................................................................ 3-3Section 2 – The $UserDefined Object ............................................................... 3-9

Lab 7 – Modeling the Heat Exchanger ...................................................... 3-11Section 3 – Change Control and Propagation ................................................. 3-25

Lab 8 – Configuring Change Control and Propagation ............................. 3-27Section 4 – The $AnalogDevice Object ........................................................... 3-35

Lab 9 – Modeling a Meter.......................................................................... 3-37Section 5 – The $DiscreteDevice Object ......................................................... 3-41

Lab 10 – Modeling a Valve, Pump, and Motor .......................................... 3-45Section 6 – Containment.................................................................................. 3-61

Lab 11 – Creating the Mixer ...................................................................... 3-67

Module 4 Extending the Objects ................................................................4-1Section 1 – UDAs............................................................................................... 4-3Section 2 – Extensions ...................................................................................... 4-7

Lab 12 – Configuring the Motor Speed ..................................................... 4-11Section 3 – Introduction to QuickScript .NET................................................... 4-21

Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient ......................... 4-45Lab 14 – Configuring Automatic Reference .............................................. 4-53

Module 5 Alarms and History .....................................................................5-1Section 1 – Alarms............................................................................................. 5-3

Lab 15 – Configuring Alarms..................................................................... 5-15Section 2 – Historization .................................................................................. 5-33

Lab 16 – Configuring History..................................................................... 5-39

Module 6 Security ........................................................................................6-1Section 1 – Security Overview ........................................................................... 6-3

Lab 17 – Security ...................................................................................... 6-13

System Platform - Part 1

4 System Platform - Part 1

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

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

Module 9 Multi-Node Applications ............................................................ 9-1Section 1 – Application Redundancy..................................................................9-3

Lab 18 – Configuring Application Redundancy ......................................... 9-15Section 2 – DI Redundancy.............................................................................. 9-29

Lab 19 – Configuring the Redundant DI Object ......................................... 9-33Section 3 – Multi Node Application................................................................... 9-45

Lab 20 – Convert to Network Environment ............................................... 9-49

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

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

Wonderware Training

Module 1

IntroductionSection 1 – Course Introduction 1-3

Section 2 – Wonderware System Platform 1-17

Lab 1 – Creating a Galaxy 1-39

Section 3 – The ArchestrA IDE 1-45

Section 4 – Automation Objects 1-67

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

Section 6 – Application Planning 1-89

Lab 2 – Identifying the Mixer 1-95

1-2 Module 1 – Introduction

Module ObjectiveIntroduce the Wonderware System Platform and its architecture, environment, and requirements for installation and licensing.

Wonderware Training

Section 1 – Course Introduction 1-3

Section 1 – Course Introduction

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

Agenda

Module 1 – IntroductionSection 1 – Course Introduction

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

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

Lab 1 – Creating a Galaxy

Section 3 – The ArchestrA IDEThis 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 ObjectsThis 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 SupportThis section provides a detailed explanation of the system requirements necessary for Wonderware System Platform, discusses Licensing details and covers Support services.

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

Lab 2 – Identifying the Mixer

Module 2 – Application InfrastructureSection 1 – The Plant Model

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



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 ModelThis section provides an explanation of the Deployment Model and demonstrates the structure of the Deployment Model.

Lab 4 – Creating the Deployment Model

Section 3 – The Runtime EnvironmentThis section provides an explanation of the Runtime environment and explains the use of the Object Viewer in monitoring the Runtime environment.

Lab 5 – Using Object Viewer

Section 4 – Connecting to the FieldThis section provides an understanding of the Device Integration Objects, I/O Server and DA Server. It also provides an overview of DI Objects.

Lab 6 – Connecting to the Field

Module 3 – Application ObjectsSection 1 – Templates and Instances

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

Section 2 – The $UserDefined ObjectThis section introduces you to the $UserDefined object and its functionality.

Lab 7 – Modeling the Heat Exchanger

Section 3 – Change Control and PropagationThis section presents the concept of attribute locking and provides an illustrations on how locking attributes can propagate to previously derived instances.

Lab 8 – Configuring Change Control and Propagation

Section 4 – The $AnalogDevice ObjectThis section introduces you to the concept of the $AnalogDevice object and its functionality.

Lab 9 – Modeling a Meter

Section 5 – The $DiscreteDevice ObjectThis section introduces you to the concept of the $DiscreteDevice object and its functionality.

Lab 10 – Modeling a Valve, Pump, and Motor

Section 6 – ContainmentThis section illustrates the concept of containment and how it works with Application Objects and Templates.

Lab 11 – Creating the Mixer

Module 4 – Extending the ObjectsSection 1 – UDAs

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

Wonderware Training


Section 2 – ExtensionsThis section provides describes the Output Functionality for Application Objects in the Extensions environment.

Lab 12 – Configuring the Motor Speed

Section 3 – Introduction to QuickScript .NETThis section introduces and explains the scripting environment and the various scripting configuration attributes of the ApplicationObject.

Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient

Lab 14 – Configuring Automatic Reference

Module 5 – Alarms and HistorySection 1 – Alarms

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

Lab 15 – Configuring Alarms

Section 2 – HistorizationThis section provides familiarization with the background concept of historization and the details of historizable configuration.

Lab 16 – Configuring History

Module 6 – SecuritySection 1 – Security Overview

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

Lab 17 – Security

Module 7 – Galaxy MaintenanceSection 1 – Exporting and Importing Objects

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

Section 2 – Configuring Instances Through a .CSV FileThis section provides an understanding of fundamental functions dealing with Galaxy Maintenance. Specifically, it illustrates how to Export for future use and how to Import a galaxy created previously.

Section 3 – System Management Console (SMC)This section provides an understanding of role of the System Management Console and how it can be configured.

Section 4 – Network Account UtilityThis section discusses the role of changing the network account and how to use the Change Network Account and how to configure it.

Module 8 – Device Integration Products



Section 1 – Wonderware I/O ServersThis section will describe the configuration of a Wonderware I/O Server (Modbus).

Section 2 – Wonderware Data Access ServersThis section provides familiarization with Wonderware Data Access Server and its use with Application Server.

Section 3 – Device Integration ObjectsThis section provides familiarization with DI Objects and their use with Wonderware Application Server.

Module 9 – Multi-Node ApplicationsSection 1 – Application Redundancy

This section provides an understanding of the concept of redundancy, how it can be configured and key points to more effectively implement this feature. It also provides an understanding of the concept and functionality of Redundant DI Objects

Lab 18 – Configuring Application Redundancy

Section 2 – DI RedundancyThis section provides an understanding of the concept of redundancy, how it can be configured and key points to more effectively implement this feature. It also provides an understanding of the concept and functionality of Redundant DI Objects

Lab 19 – Configuring the Redundant DI Object

Section 3 – Multi Node ApplicationThis section provides an understanding of how to migrate from a standalone configuration to a network configuration. At the conclusion of this section you will have an understanding of the steps necessary to migrate to a network environment.

Lab 20 – Convert to Network Environment

Wonderware Training


Wonderware software solutionsWonderware is the leading supplier of real-time operations management industrial software solutions for Manufacturing Execution Systems (MES), Performance Management, Enterprise Manufacturing Intelligence (EMI), and integration with asset management, Supervisory HMI, GeoSCADA, Production Management, supply and demand chain, and Enterprise Resource Planning (ERP) applications.

Wonderware delivers significant cost reductions associated with designing, building, deploying and maintaining secure and standardized applications for manufacturing and industrial operations. Wonderware software solutions enable companies to synchronize their production operations with business objectives, obtaining the speed and flexibility to attain sustained profitability.

Over one-third of the world's plants and facilities run Wonderware software solutions in dozens of industries worldwide, such as:

AutomotiveChemical & PharmaceuticalCPG (Food & Beverage)Discrete ManufacturingElectrical PowerFacilities ManagementMining and MetalsOil and GasProcess ManufacturingWater and Wastewater

Wonderware software solutions deliver manufacturing and operational performance improvements that help reduce the amount of project-specific work required to develop information and automation applications that are integrated across entire operational enterprises. They can be implemented in the context of existing systems, at a company’s own pace and to the extent that they choose.



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

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

Plan &Build

Machine

Enterprise

Plant / Sites

Operate

Maintain &Evolve

ManufacturingOperations

System & DeviceConnectivity

InfrastructureOperations

.FacilitiesManagement

.Power Generation &

Transmission.Transportation

.Water & Wastewater

.Etc.

.Discrete Manufacturing

.Food & Beverage

.Mining & Metals

.Oil & Gas.Specialty Chemical &

Pharmaceutical

.Etc.

Line / Department

Control RoomOperator

LineOperator

ProcessEngineerIT

DevelopmentEngineer

SystemIntegrator

QualityEngineer

Mobile User

ProductionSupervisor

MaintenanceOperator

MaintenanceSupervisor

ProcessEngineer

IT

Wonderware Training


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

For more information on Wonderware software solutions and products, visit the Wonderware Web site at http://www.wonderware.com.



ArchestrA technologyArchestrA technology, or architecture, helps reduce application engineering effort and deployment, increase efficiency, provide optimization and standardization, and enable integration of distributed automation systems and applications from virtually any vendor. Geographically dispersed applications (from a few hundred to one million I/O, and from a single node to hundreds of stations) can be rapidly and securely implemented.

The ArchestrA architecture leverages advanced software technologies to fill the gap between ERP systems and control systems. This architecture provides the following:

Framework which supports common services and a core set of system objectsDomain Objects which are industry-specific objectsObject Development Toolkit which enables third parties to create new domain objects customized for specific needs

The supervisory control and manufacturing information environment is served by a variety of systems, including (HMI), Distributed Control Systems (DCS), Supervisory Control and Data Acquisition systems (SCADA), Process Information Management systems (PIM), Manufacturing Execution Systems (MES), batch and recipe management systems, and advanced control/simulation systems. The ArchestrA Framework supports core services that are required by most of these different types of supervisory control and manufacturing information systems.

These core services include the following:Integrated Development Environment (IDE)Version managementLicense management and centralized deploymentSystem diagnostics and system administrationInternationalizationData visualization and monitoringEvent-based processing, scripting, and calculation capabilitiesAlarm and event management, historization and securityData acquisition and field device integrationInter-object communications and name serviceReporting and ad-hoc query capabilitySupport for industry standards such as OPC and SQL

The ArchestrA architecture consists of the following:Configuration and Deployment Related Components that are required for centralized deployment of the runtime components. These components are installed just like any other Windows application and include the following:

Centralized object repository (called Galaxy Repository)Integrated Development Environment (IDE) Object deployment services (called Bootstrap)

Runtime Components that are centrally deployed and administered. These components include the following:

PCs with core infrastructure (called Platforms)Key software applications (Engines)Objects (Framework Objects) that expose framework related functionality

Wonderware Training


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

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

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

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

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

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



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

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

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

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

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

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

Wonderware Training


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

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

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

Wonderware offers the following Toolkits:

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

Toolkit Enables developers to:DAServer Toolkit Build custom device integration servers more easilyArchestrA Object Toolkit Extend the ArchestrA architecture with objects that provide specific application or

device integration functionalityHistorian Toolkit Create high-value industrial applications that integrate with data sources from the

System Platform and other data sourcesAlarm Toolkit Produce custom distributed alarm providers and consumersWizard Toolkit Produce their own Wizards for inclusion in InTouch HMI Script Toolkit Develop custom InTouch scriptsGRAccess Toolkit Create programmatic access to and interaction with System Platform Galaxy

configuration data MXAccess Toolkit Create programmatic access to runtime data in a System Platform Galaxy



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

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

Wonderware System Platform FrameworkArchestrA provides an infrastructure for simplifying the development, deployment, lifecycle maintenance, and administration of distributed automation applications.

The supervisory control and manufacturing information environment is served by a variety of systems, including (HMI), Distributed Control Systems (DCS), Supervisory Control and Data Acquisition systems (SCADA), Process Information Management systems (PIM), Manufacturing Execution Systems (MES), batch and recipe management systems, and advanced control/simulation systems.

ArchestrA leverages advanced software technologies to fill the gap between ERP systems and the control systems. This architecture provides the following:

Framework: supports common services and a core set of system objects Domain Objects: are industry-specific objects Object Development Toolkit: allows 3rd parties to create new domain objects customized for specific needs

The ArchestrA infrastructure, or Framework, supports core services that are required by most of the different types of supervisory control and manufacturing information systems mentioned above. These core services include the following:

ArchestrA IDEVersion management License management and centralized deployment System diagnostics and system administration Internationalization Data visualization and monitoring Event based processing, scripting, and calculation capabilities Alarm and event management, historization, and security Data acquisition and field device integration Inter-object communications and name service Reporting and ad-hoc query capability Support for industry standards such as OPC and SQL

The ArchestrA Framework consists of: Configuration and Deployment Related Components: which include the centralized object repository (called Galaxy Repository), ArchestrA IDE and object deployment

Wonderware Training


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



– Intentionally left blank –

Wonderware Training


Section 2 – Wonderware System Platform

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

System PlatformThe Wonderware System Platform provides a single platform for all the SCADA, Supervisory HMI, and Production and Performance Management needs of industrial automation and information personnel. It provides a common and strategic industrial application services platform on top of virtually any existing system, and is built upon the industry-standards based, ArchestrA real-time SOA technology.

The Wonderware System Platform is designed to make it easier for manufacturers to adjust to the ever-changing needs of customers and the overall market. Its diverse functionality extends Wonderware customers’ software investments and encourages flexibility in application development.

It supports consistent and reliable operations across industrial operations and manufacturing facilities as well as promotes sustainable production and operational performance improvements.

The Wonderware System Platform contains an integral core set of capabilities and services to support sustainable production and operations performance improvement via a comprehensive set of six capability areas:

Industrial domain services Software and device connectivity services Information and data management services Information-delivery and visualization services Application development services System management and extensibility services

Section ObjectivesIntroduce the concept of ArchestrA and how it relates to the manufacturing environmentDescribe the benefits of migrating to an ArchestrA architectural environmentClarify how Object Oriented tag-based products relates to SCADAExplain the difference between Object Oriented development process and Tag Based development processExplain what a Galaxy is and how it relates to the Galaxy Database and the Galaxy RepositoryDemonstrate how a Galaxy is created



Industrial Domain ServicesThe Wonderware System Platform offers industrial domain services that are not provided by commercial operating systems or generic IT products. It provides a powerful infrastructure that enables Wonderware customers to leverage lower-cost commercial PC hardware and operating systems in industrial applications.

Application functions are quickly customized. Whether you have no knowledge of computer programming or consider yourself an expert software engineer, the System Platform can empower you to conveniently interact with process systems from any remote location. The result is a reduction of personnel costs and improved response times because the software continuously monitors and deploys messages, 24/7.

Industrial Domain Services provide:Real-time, peer-to-peer communications and messaging, enabling instant responsesHigh computing availability and redundancy for critical applicationsCentralized alarm- and event-monitoring for operational conditionsData-level security to protect plant equipmentAudit logging and extended security protection for developers and system-maintenance personnelPager, mobile phone, PA system and e-mail alerts for unattended operational monitoringA single global Namespace to access data elements anywhere, without tag limitationsPlant information and supervisory functions to script special behavior and responsesSupport for slow and/or intermittent data networks

Software and Device Connectivity ServicesThe Wonderware System Platform enables cost-effective communication to virtually any plant information source. Unifying diverse systems can improve operations and information management. Integrating business and manufacturing activities can also increase plant profitability.

Software and Device Connectivity Services provide:Integration of manufacturing and business systemsEasy importing and migration of legacy systems and external system configurationsConversion of non-structured devicecommunication models into structured systems to increase the maintainability of applications and systemsConnectors and communication servers for control devices, applications and systems including:

Automation devices, control systems and HMIsHistorians and relational databasesQuality and maintenance systemsEnterprise resource management (ERP) and business systemsManufacturing execution systems (MES)

Wonderware Training


Information and Data Management ServicesFurthermore, the Wonderware System Platform facilitates the management of all real-time and historical information — including data transformation and storage. This information management capability can increase a plant’s profitability because it enables immediate access to key performance indicators (KPIs); SPC, downtime and OEE information; live data calculations; event and alarm notifications; and historical data.

More effective information and content management can also improve production management and enhance plant performance. For instance, the reliable information that the Wonderware System Platform enables not only data visualization, but actionable control. The platform also enhances batch management, real-time production monitoring and access to MES data.

Information and Data Management Services provide:Content management toolsStreaming 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 enterpriseData compression, which reduces disk storage and makes more data available onlineAn historical archive that’s auto-configured, eliminating duplicate work

Off-line and late data handling for:Manual dataLabs and quality systemsRemote terminal unit (RTU) environments

Correlation of events and alarms with production historyData transformation and normalizationData Buffering and Store & Forward featuresSimple and fast configuration with powerful process event monitoring



Information-Delivery and Visualization ServicesDelivering 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.

CapabilitiesMultiple client interfaces [i.e., Thick, Terminal Services Edition (TSE) or Web Client]Visualization and HMI

Expansive graphical user interface (GUI)Access-level Windows authentication and data security, as well as enhanced password encryptionComprehensive alarm troubleshooting tools

Information Analysis and ReportingIntegration with trending tools and Microsoft Office productsProduction, SPC, downtime and batch analysis tools

Automatic data retrieval calculations - reduction and aggregate methodsOpen SQL access, enabling simplified data queries with powerful retrieval modesSecure access across firewallsMulti-language client support

Wonderware Training


Application Development ServicesThe Wonderware System Platform and its underlying ArchestrA technology provide easy and intuitive development of modular industrial software solutions, which can be easily changed to meet Wonderware customers¡¦ future needs. As a result, you can drive standards by developing applications once and using them everywhere. The result is a decrease in the amount of time and costs associated with creating, modifying, deploying, maintaining and standardizing software applications.

Application Development Services provide:Flexible, comprehensive software development capabilities for HMI and/or MES applications Advanced ArchestrA technology, which facilitates the assembly of applications that are component-based and generated from standard templatesSmartSymbol technology, enabling the creation of re-usable graphicsDifferent development views, which show:

How the application is related to the facility or plantHow the application is distributed across the networkParent-child relationships for templates and runtime components

Multi-Developer Environment for concurrent developmentModeling - Applications can be structured based on a plant model; are self-documenting; and offer common security, validation and audit trailsUnification with Microsoft products including:

Microsoft Windows operating systemsThe Visual Studio development systemSQL Server, BizTalk serverSharePoint servicesMicrosoft OfficeInternet Explorer internet browser



System Management and Extensibility ServicesFurthermore, the Wonderware System Platform facilitates the easy management, expansion and modification of applications or the host computing architecture. These services provide a range of architectural choices, both during the initial system design phase and throughout the lifetime of an installed system.

Leverage the flexible and scalable ArchestrA software architecture for small and large systems — systems that can be easily expanded to meet future requirements. Improve system troubleshooting. Leverage Wonderware’s technological evolution and increased protection for operating systems and databases. Decrease lifecycle costs for plant IT solutions. Change and expand your system as a whole without disruption.

System Management and Extensibility Services provide:The ability to re-architect systems at any time to support different system topologies (i.e., Single Node, Client/Server, Peer-to-Peer or Web-centricEasy redistribution of server loadRemote application installation and administrationAn online configuration database that centrally maintains softwareRemote change propagationCentralized 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.

ArchestrAArchestrA is a comprehensive plant automation and information architecture designed from the outset to extend the life of legacy systems by leveraging the latest software technologies.

Offerings built upon this architecture empower decision-makers to achieve their business goals, without abandoning prior investments in automation systems, production processes or intellectual property.

ArchestrA's complete approach to industrial architecture significantly reduces a plant's total cost of ownership through easy installation, operation, modification, maintenance and replication of automation applications.

In the ArchestrA environment, software applications can be rapidly assembled rather than programmed. New applications also can be created simply through the reassembly of existing applications.

The ArchestrA vision is to provide a unified and robust architecture that is the basis for collaborative production systems in support of industrial enterprises. Its open-development platform and tools uniquely enable Invensys and third parties such as OEMs, machine builders and system integrators to build domain knowledge and add significant value to the solutions they provide. End-users and suppliers will benefit from ArchestrA's unified platform, which enables the instant integration of application information.

ArchestrA is the comprehensive industrial automation and information architecture that orchestrates a new way to run or expand older plants more efficiently, and an optimal way to build new plants.

Wonderware Training


The Need for ArchestrAQuality, responsiveness, and cost efficiency have always been necessary for any plant or factory that wishes to surpass the competition. Today, they are vital for any plant, factory, or enterprise to survive.

The pace of change accelerates. Product cycles become shorter and more complex. New or enhanced products must be commercialized at breakneck speed, or risk rapid failure. Such offerings must also be quickly customizable for use in today’s global business spaces. Again, as these markets grow ever more economically efficient, the choice for manufacturers is between agility and finality.

That’s why today a variety of computer-based systems are used to operate plants as well as to improve their efficiency. In most plants, multiple varieties of hardware and software systems provide machine and process control, information management, and decision support. These systems enable manufacturers to operate their businesses more effectively and add value to the raw materials they process. Without these systems, many highly engineered consumer and industrial products simply would not exist, because of the complexities involved in their manufacture.

Unfortunately, even today, in most plants these systems operate independently. This hinders a plant manager’s ability to synchronize and control production and business processes in a real-time environment. In other words, the majority of manufacturers have not successfully integrated the functionalities of automation/business/information systems into a single, unified infrastructure. In the past, this has been an expensive and time-consuming process. Those that have successfully integrated have done so at great cost in terms of money and resources. Moreover, despite the huge investments made by companies in these systems over the years, managers still find it difficult to quantify resulting tangible benefits.

The most compelling aspect of the problem now facing manufacturers is that the underlying technology of these systems is rapidly becoming obsolete. As general technology lifecycles shorten, manufacturers are pressed to procure and integrate new technologies with ever-increasing speed — making the ultimate goal of productivity improvement even more difficult to achieve.



In most plants today, “islands of automation” within business and manufacturing systems hinder the plant manager’s ability to synchronize business processes in real time.

Recognizing this challenge, Invensys has developed a solution, ArchestrA automation and information architecture (ArchestrA).

A powerful new infrastructure for industrial applications, ArchestrA promises to provide an information and control superstructure that will increase the productivity of a plant’s existing systems, while enabling the plant to easily integrate important new technologies over the longer term. Building on ArchestrA research and technology, the recently released I/A Series A2 system (I/A Series A2) has taken the first major step toward reducing the risk of automation obsolescence and protecting manufacturers’ investments far into the future.

Manufacturing GoalsFor 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 globalizationDevelop greater agility and a more collaborative, data-driven environment•Synchronize the manufacturing process with planning and scheduling functions to optimize enterprise performanceEmpower operators with critical information to foster improved plant performanceUtilize existing assets more efficiently to increase production, without the need to expand the plant or build new capacityEnsure the greatest possible return on assets, and improve profitability, in the face of continuing manpower reductions

To achieve these goals, managers know they can no longer simply "invest in technology" and expect improvements to come about automatically. In fact, millions of dollars have already been invested with only marginal returns. However, management cannot afford to stand still, because

Wonderware Training


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 SystemsToday’s collaborative manufacturing environment requires that manufacturers synchronize automation systems with business/information systems to accomplish total supply chain management.

To facilitate this collaborative environment, many manufacturers are working toward a rational, cost-effective solution that does not require enormous investment and allows for the preservation of as much existing infrastructure as possible. They are preserving, to the maximum extent feasible, existing investments in hardware and software, as well as in intellectual properties contained in application-specific software. They are working to synchronize the various informational elements within the manufacturing domain, namely automation systems, business systems, and information systems, thereby fulfilling these systems’ original promise of improved manufacturing efficiency. They are identifying optimal long-term strategies based on total cost of ownership.

The pace of change has increased to a point at which it is difficult for manufacturers to execute a new strategy before market conditions change once again. Today’s manufacturer, however, must have the ability to respond to challenges that are virtually unanticipated. Response times have now become the cornerstones of manufacturing competitiveness, and will remain so for the foreseeable future.

The challenge has been to develop an architectural infrastructure that optimizes quality, customer satisfaction, and efficiency of operation, while facilitating quick response and easy reengineering. And to identify and deploy a plant information superstructure that embraces existing systems while providing expansion capabilities for the long term.

Such an architectural infrastructure is available through ArchestrA. This allows manufacturers to:Preserve a significant portion of their existing automation and information infrastructuresIntegrate and synchronize existing production systems and new applicationsMove ahead into the future, confident of shorter project execution times, reduced total cost of ownership, and a proven, long-term strategy that will remain in a leadership position for the life of the plant.



ArchestrA ArchitectureArchestrA, developed by Invensys, is a software infrastructure designed to unify combinations of Invensys, third-party, and customer internal applications, both current and emerging, into a synchronized, plant-level application model, and to foster their ongoing adaptation and improvement. It comprises a unique combination of new toolsets and new applications infrastructure services, allowing the rapid generation of new applications, products, and services. Because it enables easy upgrades via integration of existing systems with these new technologies, it offers manufacturers the promise of extending the lifecycle of an entire plant’s information and control system infrastructure.

ArchestrA facilitates the next logical extension of enabling software architecture designed to accommodate emerging technologies and to ease the reuse of engineering from one project to another. The objective of this unique technology is to dramatically reduce engineering and maintenance time and expense when a manufacturer must modify or expand his company’s process. Incorporating ArchestrA will considerably reduce the cost and time involved in executing strategic change.

Wonderware Training


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 environmentDeployment, scripting, and calculation servicesAlarm and event subsystems with reliable deliveryBuilt-in distributed architecture services for scalabilityIntegration with various types of field devicesInter-object communication and name service managementVersion management servicesSecurity model servicesCentralized license management and deployment servicesCentralized system diagnostics and administrationInternationalization of objects and application servicesGraphical user interface (GUI) editing services



Automation Information PyramidArchestrA supports all layers of industry standard models. It is the basis for Supervisory, Production and Plant Intelligence solutions. In addition, it extends functionality across the enterprise enabling true manufacturing collaboration. The Automation Information Pyramid illustrates these points. It displays the complete effectiveness of ArchestrA across all levels of the manufacturing environment:

1. Plant Floor Connectivity

2. Supervisory

3. Production

4. Plant Intelligence

5. Manufacturing Collaboration

The following page illustrates these segments as they relate to the Automation Information Pyramid.

Wonderware Training


Manufacturing Collaboration

Plant Intelligence

Production

Supervisory

Plant Floor Connectivity



ScalabilityWonderware Application Server provides a scalable and integrated architecture to meet the needs of small, simple applications all the way up to highly challenging manufacturing information management systems.

Wonderware Application Server resolves the problems associated with scaling automation applications because there are no limitations on system size and performance issues are easily addressed through the introduction of new nodes. New workstations and any data points defined are automatically integrated into the initial application through the plant model. The common distributed peer-to-peer Namespace means that all information is shared between the nodes without the user having to perform any additional engineering or configuration.

Object Oriented vs. Tag Based Supervisory ControlThere 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.

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

Process Object Oriented Tag BasedStructure Hierarchical FlatGraphics Development Done Last Done EarlyBackground Process Developed in Objects Developed in TagsPromotion of Standards Strictly Enforced Not Strictly EnforcedGlobal Application Change Progagated from Templates Changed in Tools like ExcelData Represented By Physical Devices as Objects Data Types and communication

Bits as Tags

Wonderware Training


Use of the word "Object-oriented" with SCADAThe phrase "Object-oriented SCADA" has been with us since the early 1990's. It is mostly used today to refer to the ability to build graphics and draw pictures based on classes or a hierarchy. This is referred to as Object Oriented Graphics. This allows you to build a symbol and replicate it across a screen or HMI application and have visual changes made to all the similar symbols at the same time. This is useful functionality, but SCADA applications are more than just pretty pictures. For example, the majority of work that goes into a supervisory application is for things like:

Alarm MonitoringAnimation ScriptsSecurity Scripts Supervisory ScriptsHistorical data storageIntegration with other applications and DatabasesEvent DetectionFlow and movement calculationsDevice integration

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



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

Using object-oriented tools in manufacturing applicationsManufacturing applications typically have a lot of common components. These include common types of:

Plant devices and equipmentOperating proceduresProcess measurementsCalculationsGraphics displays

This leads to a cookie cutter approach, where typically small software programs are developed as objects/code modules that can be stamped out and joined together to form an application. Almost all of the automation vendors have this capability today with their software. Where an object-oriented SCADA System is different, is that after the cookies are stamped out, you can change the stamp, and all of the cookies you already made are automatically changed.

Wonderware Training


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 replicationProject change orders are easily accommodated by making changes in the parent template and having the child objects inherit the changes via change propagationOngoing system changes and expansions are easier and more cost effective because of automated object replication and change propagation

Traditional, Tag Based SCADA Development ProcessFrom the inception of PC based HMI and SCADA software, users have built operator graphics and linked them to tags, which represented addresses in a PLC or a control system. The concentration was on the computer and the software application. Here is an example of how a traditional tag-based SCADA application is developed.

1. A new HMI application is created on a single computer

2. Windows or displays are created for the application

3. Graphics are created for the windows

4. Tag definitions are imported from the PLC or manually configured

5. Alarm and Event Detection Scripts are defined for each tag

6. Tags are linked to graphic elements

7. Graphics animation scripts or links are created

8. IO Tags are defined and linked to the application

9. If the application is to be deployed in a client-server environment, the application is re-architected to centralize alarming, event detection, history archiving, graphics and IO servers.

10. Changes to the system require shutting down the application, making changes to the many scripts and tag database references to enable the new functionality, and reloading the new HMI application on each workstation.



Object oriented Development Process- graphics are created lastWonderware Application Server and the ArchestrA IDE have brought a new era to SCADA Software development through the ability to create a complete plant device model. The developer is abstracted from the complexities of the computing environment and allowed to concentrate on "modeling" how the production facility is laid out and the different manufacturing cells and processes that comprise plant-wide supervisory control. Once the plant model is captured, it is easy to implement supervisory control functions. A small investment in creating Templates yields big results in engineering productivity. The ten easy steps to creating a supervisory application using the Application Server are:

1. A site survey is conducted to understand the layout of the manufacturing operation or process. Piping and Instrument Diagrams (P&ID) can also be referenced to understand the specific equipment in use.

2. A list is developed of similar pieces of equipment, like common types of motors, valves, transmitters, control loops, drives, etc. Distinct areas of operation are also identified.

3. Templates are configured for each common device or component in the facility. For example, there may be 100 transmitters of a particular type that can be modeled as a single device template. This process sets up the standards for the supervisory application and for any applications that are created in the future. These templates will be used to develop objects which represent a specific device, such as a level transmitter LIC101. In addition, templates contain all of the logic, input/outputs, scripting, history configuration, security and alarms and events for the device.

4. Device templates can be contained within each other to build-up a more complicated device, for example, a mixer may contain a level transmitter, pump, inlet / drain valves and agitator.

5. Device templates have attributes which represent real I/O available in the PLC or control system. These attributes are then linked to the I/O through Device Integration Objects.

6. The application can then be assembled by using a simple drag and drop capability inside if the ArchestrA IDE. As templates are dropped into their individual plant areas, an object instance is created that is linked back to the template. This is the "Object-Oriented" nature of the Application Server, which provides incredible power when it comes time to modify anything in the system. The software does all the work as the user is simply configuring templates that represent the equipment in the plant.

7. Objects are then assigned to security groups. This can be done on an individual basis or by area of the plant. These security groups have common permissions. Roles are created to map rights onto each security group. Users can be given one or more roles. This offers a great amount of flexibility in changing user permissions and in managing the security model.

8. The model created in the ArchestrA IDE can now be deployed to the computers that will host the application. Notice that absolutely no consideration needs to be given to how the supervisory stations are going to be laid-out or which computer needs to have a specific part of the system running on it. The Application Server is a fully distributed system, which can reside on a single computer or on hundreds of computers. Standard system objects, such as Platforms and Engines, represent specific computers that are used to host objects when they are deployed.

9. Graphics are then configured using InTouch®, the world's most popular HMI software package. This can also be done using the Smart-Symbol functionality contained in InTouch 9.0 SP 2 which allows a graphic element to be created and linked to a template in the ArchestrA IDE. That way the display graphics are also object-oriented and tightly coupled to the plant model.

Wonderware Training


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



What is a Galaxy?It’s important to understand what a Galaxy is before one is created. A Galaxy is the entire application, the complete ArchestrA system consisting of a single logical name space and a collection of WinPlatforms, AppEngines and objects. One or more networked PC’s that constitute an automation system. It defines the name space that all components and objects live in and defines the common set of system level policies that all components and objects comply with.

A Galaxy Database is the relational database containing all persistent configuration information for all objects in a Galaxy.

And a Galaxy Repository is the software sub-system consisting of one or more Galaxy Databases.

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

This dialog box is comprised of three groups of options: Galaxy Repository/Galaxy connect selections: This consists of the GR Node Name and Galaxy Name boxes.Action buttons: Connect, New Galaxy, Delete Galaxy, About and Cancel.Licensing information

If the Galaxy Name box is empty, you have not yet created a Galaxy on the computer shown in the GR Node Name box. Before you can start the ArchestrA IDE, you must either browse for a Galaxy on another node or create a new Galaxy.

Wonderware Training


All new Galaxies are created with no security. They also have the following characteristics: two users (DefaultUser and Administrator, both with full access to everything), two security roles (Default and Administrator, both with full privileges) and one security group (Default). When creating a new Galaxy, you must select the appropriate Galaxy type:

Default Galaxy: Creates a Galaxy that includes all objects needed for a System Platform application. It also creates a backup file (.cab) at the end of the process and makes it available to this list.

Base_Application_Server.cab: Same as Default Galaxy, but uses the backup file (.cab) to create the galaxy. It does not creates a backup at the end, making the process faster.

Base_InTouch.cab: Creates a Galaxy that includes only the object needed for tag-based Managed InTouch applications.

Reactor_Demo_Application_Server.cab: Creates a Galaxy with the Reactor Demo based on a System Platform application.

Reactor_Demo_InTouch.cab: Creates a Galaxy with the Reactor Demo based on a tag-based Managed InTouch application.

If you previously created one Galaxy on the GR node shown, the Galaxy’s name is automatically shown. Click Connect to start the ArchestrA IDE and to connect to that Galaxy. If you previously created more than one Galaxy on the GR node shown, the most recently accessed Galaxy name is shown. Choose the desired Galaxy from the Galaxy Name list and click Connect to start the ArchestrA IDE and to connect to that Galaxy.




Wonderware Training


Lab 1 – Creating a GalaxyIntroductionThis lab illustrates the steps necessary to create a Galaxy and connect to it with the ArchestrA IDE. Throughout this class you will use this Galaxy to develop a sample application.

ObjectivesUpon completion of this lab you will be able to:

Create a GalaxyUse the ArchestrA IDE to connect to your Galaxy



Create and Connect to a new Galaxya. Create a new Galaxy named TrainingGalaxy.

b. Connect to TrainingGalaxy.

See the next page for Detailed Lab Instructions

Summary Lab InstructionsFollowing 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.

Wonderware Training


Create a Galaxy1. Start the ArchestrA IDE by selecting Start / All Programs / Wonderware / ArchestrA IDE.

This will display the Connect To Galaxy dialog box.

The GR node name field will reflect the name of the local computer.

The Galaxy name drop-down list is initially empty since there are no Galaxies created in this node.

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

3. The New Galaxy dialog box is displayed.

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



4. Enter TrainingGalaxy in the Galaxy name field.

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

6. Click the Create button to continue.

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

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

7. Click Close.

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

Wonderware Training


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

8. Click the Connect button.

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




Wonderware Training


Section 3 – The ArchestrA IDE

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

The ArchestrA IDE User InterfaceThe ArchestrA IDE is the integrated design and development tool from which all ArchestrA objects are configured and deployed to target PCs. It is used to maintain and configure the objects that comprise your application and the underlying infrastructure that supports your application.

Using the ArchestrA IDE, you can import new types of objects in to the Galaxy Repository, configure new ones, and deploy them to PCs on your network. Multiple users can work concurrently on different sets of objects from different ArchestrA IDEs.

The ArchestrA IDE can be installed on any PC that has ArchestrA’s Bootstrap software installed.

Section ObjectivesDiscuss ArchestrA IDEIntroduce the Template Toolbox and Application Views Discuss the object Check-in/Check-out process.



Key Functions of the ArchestrA IDEThe 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 ConfigurationConnect to an existing Galaxy on the networkCreate a new GalaxyDestroy a GalaxyImport/Export Objects (aaPackage, .csv)Import/Export script function libraries (.dll, .tlb, .olb, .wdf, .aaSLIB)

Security ConfigurationConfigure User securityConfigure Object security

Object ConfigurationCreate new objectsCheck out objectsEdit objectsConfigure Historization through objectsConfigure objects for Alarms and EventsExtending object functionalityCheck in objects with commentsDeploy/undeploy objectsPropagate changes to runtime objectsView object’s configuration errors/warningsUpload runtime changes to Galaxy database

IDE ConfigurationSet user preferencesCreate a Tool Box

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

Wonderware Training


The ArchestrA IDE User Interface

Main View

The Main Window of the ArchestrA IDE is composed of the following components:Title barMenu barToolbarTemplate ToolboxApplication ViewsObject Editor AreaOperations ViewStatus bar

When you first log in to the ArchestrA IDE, the Main Window displays the Template Toolbox and Application Views docked on the left, the Toolbar docked at the top, and the Object Editor Client Area on the right. Upon subsequent logins by the same user, the Main Window displays the positions for these controls as they were at the end of the last log in session.

The Title Bar displays the name of the utility. The other elements of the Main Window are described below.



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

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

Galaxy menu – Providing Galaxy or user-level global commands, the Galaxy menu includes the following:

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

Wonderware Training


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

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

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



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

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

Wonderware Training


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-54 for additional information regarding this feature.

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



Upload Runtime Changes – For uploading a deployed object’s configuration to the Galaxy Repository. This function is useful when changes to certain attributes (Writeable_UC, Writeable_UC_Lockable, Writeable_USC, Writeable_USC_Lockable) are made in the configuration environment, but at a later time, the runtime object’s configuration is determined to be preferred. Select the desired object and click Upload. The runtime configuration overwrites the configuration environment data in the Galaxy Repository.

Window menu – For manipulating the Object Editor Client Area of the Main Window, this menu is available if at least one object’s editor is open. This menu includes the following commands:

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

Help menu – similar to a standard MS Help menu, the ArchestrA IDE Help menu includes the following commands:

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

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

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

Wonderware Training


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

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

To display the Operations pane, either Right-click on an object (multi-select is allowed) and click Validate on the shortcut menu.Click Operations on the View menu.

The following pane is then displayed in the Main Window.

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

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

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

If multiple objects are validated, the list of objects is sorted by object name. You can click a column heading to re-sort according to alphanumeric or icon groupings. Use the check mark column heading to sort for objects that are checked out and, therefore, cannot be validated. The object’s icon indicates checked out status with a check mark.

You can perform any operation on an object listed in the Operations pane that is possible in the Template Toolbox or Application Views. Right-click on the object and select commands from the shortcut menu. You can open an object's editor from the Operations pane by double-clicking it. To view an object’s properties (particularly, the Errors/Warnings page of the Properties dialog box), double-click its status icon. You can also copy a line of text in the Operations pane list by clicking Copy from the shortcut menu (or Ctrl+C). The Operations pane, like the Template Toolbox and Applications Views, is also updated as the status and conditions of objects in the Galaxy change.



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

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

Typically, each option on an object’s editor that requires a string or numeric input has an allowable range of inputs. If you type an input outside the allowable range and then attempt to change editor page, close the editor or save the object’s configuration, a message is displayed about the input error indicating the allowable range.

Some configuration settings are dependent on associations with external components, such as script function libraries and relative references to other objects’ attributes. The status of these external components can change, perhaps rendering some capability of the object inoperative.

For instance, an object may refer to a value of an attribute of another object, which is subsequently deleted. That scenario would break the configuration of the remaining object. Objects may be configured prior to the importing of associated script function libraries. In each case, the object would have a status of Bad. You can verify that an object’s configuration is valid and reset its status to Good by manually validating it with the Validate command on the Object menu.

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

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

Using the Find dialog together with the Validate command is an especially useful tactic. For instance, you can find objects in Error state, select them all, right-click on one of them, and click Validate on the shortcut menu.

The Validate command opens the Operations pane in the ArchestrA IDE. See section on Operations Pane for more information.

Only one validation operation can be run at a time. But you can multi-select more than one object for each validation operation. The set of objects are validated serially.

Note: Validation operations cannot be canceled.

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

To validate all objects in the Galaxy, validate the Galaxy object.

Wonderware Training


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

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

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

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

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

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

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

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

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

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



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.

Delete – For deleting the object in focus.

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

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

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

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

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

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

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

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

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

IDE Help – Standard Help command, used for opening the IDE’s HTML Help documentation system.

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

Wonderware Training


Template ToolboxThis part of the Main Window hosts object template toolsets, which contain object Templates, from which instances are created or other object templates are derived. The Template Toolbox contains separate toolset bars for each toolset in the Galaxy Repository. Click the toolset bar to open that toolset and display the object templates contained in the chosen toolset.

When you first log in, the default toolset with default object templates is opened. Once a user has logged in to the Galaxy Repository, the Template Toolbox is loaded with the toolset that was displayed during the last login session.

An example of a Template Toolbox view is as follows:

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



Application ViewsThe Application Views pane displays the galaxy configuration based on how an object is related to other objects:

Model View - This defines the Object relationship to the automation scheme layout. The Objects are organized into Areas to represent the physical plant layout.Deployment View - This view defines the Object instance relationship to the PC that the Object code is running on.Derivation View - This view displays what the derivation path is from Base Template to Instance. All templates and instances are displayed in this view.

The Model view is the default display when the ArchestrA IDE is first started. Subsequent ArchestrA IDE sessions retain the user’s last setting.

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

An example of a Model view is as follows:

This view is used to display the assignment of Object Instances to their area. All Object instances belong to one and only one area.

Areas can be hierarchical. This means that an area can contain an area and the parent area collects the statistics for all its Objects and its sub-areas.

The above diagram represents the tree view that is displayed within the model view. This represents the area based relationships of each of the objects. The diagram is read left to right and top to bottom, so an Area can host Application objects, DeviceIntegrationObjects,.and Objects that contain Objects

If the instance does not have a defined host then the instance will be displayed under the "Unassigned Area" root of the tree.

The top of the tree is the GalaxyObject, This is displayed using the name that was given to the Galaxy when it was created.

To assign one object to another, drag-and-drop it. To unassign an object currently assigned to another object, drag-and-drop it to the Unassigned Area folder.

Galaxy Name

Wonderware Training


Deployment View

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

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

An example of a Deployment view is as follows:

This diagram represents the tree view that is displayed within the deployment view. This represents the topology view based on which PC and Engines the objects run on. The diagram is read left to right and top to bottom, so a Platform can host an AppEngine. Also, an AppEngine can host an Area.

If the instance does not have a defined host then the instance will be displayed under the "Unassigned Host" root of the tree.

To assign an object to another, drag-and-drop it onto the host object. An inappropriate assignment match is not allowed. Conversely, to unassign an object, drag-and-drop it to the Unassigned folder.



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

An example of a Derivation view is as follows:

This view contains all templates and instances. The tree is displayed in alphabetical order at each level within the tree.

The base templates created within the ApplicationObject Toolkit is on the left, as all other templates and instances are derived from these an extra level will be added to the tree.

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

Base templates are shown in the second level of the tree structure, and derived templates and object instances are appropriately indented based on their relationship with parent objects. Templates with no associated instances are grouped together under Unused Templates. Under each branch of the tree, child objects are listed in alphabetical order. Default objects are displayed in bold.

Unlike the Model and Deployment views, you cannot drag-and-drop objects from one branch to another in the Derivation view. The parent-child relationship between a template and a downstream object cannot be changed dynamically. You can perform other commands on objects in this view.

Wonderware Training


Graphic ToolboxThe Graphic Toolbox contains the global ArchestrA graphics that can be used in the Galaxy. It lets you organize your symbols in special folders, called Toolsets. The Graphics Toolbox shows a treeview of toolsets which contains ArchestrA Symbols and Client Controls.

It allows you to define graphics as a standard that you can re-use, such as a generic valve symbol. Symbols in the Graphic Toolbox can later be used by Automation templates and instances. You can store ArchestrA Symbols here, if you only want to use them in InTouch and not in any other Automation object content.

An example of a Graphic Toolbox is as follows:

Object IconsWhen viewing the objects, there are several states that are reflected in the way the icons for that particular object are represented.

For instance, notice the different types of icons in the following example:



Three Types of Status IndicatorsThere are three kinds of indicators that accompany object icons:

deployment status (for instances only)configuration status (for templates and instances)redundancy status (for instances only).

Deployment status indicators include:

Configuration status indicators include:

Redundancy status indicators include:

InTouch status indicator:

Icon DescriptionUndeployed (see AnalogDevice_001 and DDESuiteLinkClient_001 in example above)

(no indicator) Deployed (see AppEngine_002 in previous example)Deployed with configuration changes (see AppEngine_001 in example above)

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

Icon DescriptionConfiguration warning

Configuration error

(no indicator) Configuration good

Icon DescriptionAppEngine undeployed, its redundant pair deployed.

AppEngine deployed, its redundant pair not deployed.

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

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

Icon DescriptionApplies to InTouchViewApp deployment when files are being transferred.

Wonderware Training


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

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

If any of the objects you attempt to check out are already checked out to other people then a dialog appears indicating their status. Also, if some of the objects you attempt to check out are already checked out to you, the operation is ignored.

The Galaxy marks the objects as checked out to you, making them unavailable for check out to other users, and it updates the object’s revision history. A check mark is shown next to an object’s icon in the ArchestrA IDE.

To check out unreserved objects

a. Select them in the Template Toolbox or Application Views.

b. On the Object menu, click Check Out.

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



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

The user responsible for an operation at a specific date and time is listed on the Change Log page. Comments typed by a user in the Check In dialog box (see image later) are listed under the Comment heading.

To check an object in to the Galaxy database

a. Select it and, on the Object menu, click Check In

Wonderware Training


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

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

b. Enter a comment (optional) and click OK to finish checking in the object. Click Cancel to terminate the check in process.

The Galaxy indicates whether any of the objects you are attempting to check in are check-out to other people. If an object you are attempting to check in already is checked in, check in is ignored.

The Check In dialog box enables you to provide comments about configuration changes made while the object was checked out. It is comprised of the following options:

Comment: Use this box to enter your comments about configuration changes made to the object.Don’t Prompt for Check-In Comments in the Future: Use this check box to turn off the comment feature when checking in objects in the future. If you decide to reinstate this feature, click User Information on the Edit menu and select Ask for Check In Comments in the Configure User Information dialog box.

Undo Checkout, Override Check OutTwo other ArchestrA IDE commands related to the concept of check out and check in include:

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



Object Viewer

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

The Object Viewer monitors the status of the objects and their attributes and can be used to modify an attribute value for testing purposes.

To add an object to the Object Viewer Watch list, you can manually type the object and attribute names into the Attribute Reference box in the menu bar and select Go. When prompted to enter the Attribute Type, press the OK key.

You can save a list of items being monitored. Once you have a list of attributes in the Watch Window, you can select all or some of them and save them to an XML file. Right-click on the Watch window to save the selection or load an existing one. You can also add a second Watch window that shows as a separate tab in the bottom of the Viewer.

Refer to the Platform and Engine documentation for information about attributes that may indicate system health. These attributes provide alarm and statistics on how much load a platform or engine may have when executing application objects or communicating with I/O servers and other platforms.

Determining Galaxy Status You can see an overview of the condition of your Galaxy before you deploy. This lets you know if you have objects that are in warning or error status.

To determine the status of a Galaxy

a. Connect to the Galaxy.

b. On the Galaxy menu, click Galaxy Status. The Galaxy Status dialog box appears:

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

c. Click OK.

Wonderware Training


Section 4 – Automation Objects

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

Objects

Automation ObjectsAn automation object allows the encapsulation of all configuration elements of each piece of your system, such as I/O definitions, logic (scripting), history configuration, alarm/event configuration, security/access control and graphics. This self-contained approach dramatically reduces the engineering time associated with the initial creation and maintenance of objects. By keeping all object configuration tightly related and contained within the object itself, there is no need to use multiple editors to make sure that the alarming, I/O definitions, scripting, history, and security are consistent for an object.

There are Template objects, and Instance objects: Template objects: these are high-level definitions of the objects: equipment, devices, constructs or simply system parts of the GalaxyInstance objects: these are the runtime objects and represent the specific items in the environment, like processes, valves, holding tanks, and so on

There are Domain objects and System objects:Domain objects:

Application objects: represent the physical equipment or logical constructs in the GalaxyDevice Integration objects: represent the communication with the external devices

System objects: represent the parts of a Galaxy and not the domain they are monitoring and/or controlling

Attributes and Attribute ReferencesEvery piece of configuration and data available within an object is called an attribute. Interaction with objects, in configuration or runtime, is done through the attributes of the specific object.

Attribute references refer to data within an object's attributes; it consists of an object's reference string plus an attribute's reference string, separated by a dot ("."):

ObjectName.AttributeName

An object reference cannot exceed 32 characters (including the $ character used in template names) and must contain at least one non-numeric character.

Section ObjectivesIntroduce the various objects in the ArchestrA IDEIdentify when and how they are usedExplain how to create and configure instances of objectsIntroduce and explain the hosting and containment relationships of objects



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

Object CategoriesWithin the Template Toolbox there are three main categories of objects. These are:

Application objects AnalogDevice Boolean DiscreteDevice Double FieldReference Float Integer Sequencer SQLDataString Switch UserDefined

Device Integration objectsDDESuiteLinkClient InTouchProxy OPCClient RedundantDIObject

System objectsAppEngine Area InTouchViewApp ViewEngine WinPlatform

Wonderware Training


Application Objects

Application Objects are used to create devices in your Galaxy. These devices represent real objects in your environment.

AnalogDevice Object

This object can act as either an Analog Input (with optional Output) or as an AnalogRegulator that provides an external representation of a PID controller that exists elsewhere (typically a PLC or DCS).

The AnalogDevice can be configured to have a personality of one of the two basic types:Analog – a basic Analog Input or Analog OutputAnalogRegulator – an analog controller that represents an external PID controller

When configured as Analog, this Template is very similar in functionality to the Analog Tag within InTouch today. Just as the InTouch Analog can be configured for Read or ReadWrite, the Archestra AnalogDevice configured as type Analog can be configured as an analog input (with no output capability) or as an analog output (with output capability). The Analog supports the basic alarming capabilities of level alarms, ROC alarms and deviation alarms from a SP target value. In addition, the Analog in ArchestrA provides additional functionality such as PV override enable, PV mode (auto, manual), bad PV alarming, and separate output reference capability.

When configured as an AnalogRegulator, this Template provides both PV and SP monitoring of an external PID controller. It provides SP output capability with an optional separate feedback address for the SP. Other controller-oriented features include controller mode (manual vs. cascade). All the alarm capabilities of the more basic AnalogDevice object are included, with the difference that the SP value for deviation alarms is based on the SP value read from the controller.

Some of the common features of the AnalogDevice regardless of type (Analog or AnalogRegulator) are:

Supports optional scaling of input and output, both linear and square root conversions.Supports HiHi, Hi, Lo, and LoLo level alarms on PV with both value and time deadbanding. Supports Rate of Change (ROC) alarming on PV for both positive-slope and negative-slope ROC.PV Override – when true, allows the PV to be written by a user if the PV mode is set to Manual.Adds SP read and write capability with optional separate read-back address. For data integrity, the value of SP always represents the value read from the external controller, not the requested SP that is output to the external controller.Supports minor and major deviation alarming when PV deviates from SP.



Initial Control Mode – When in Cascade, the SP can only be written by other objects. When in Manual, a user can write the SP. When None, anything can write to it.Control Tracking – optional capability to read a Boolean control track flag from an external device or object. When tracking is on, the SP is pure read-only and cannot be changed.

Boolean Object

The Boolean object is derived from the FieldReference object and is used for evaluations that result in either of the truth values of ‘true’ of ‘false’, often coded 1 and 0 respectively.

DiscreteDevice Object

A Discrete Device is a general purpose Object that is used to represent a large class of physical equipment common in manufacturing such as pumps, valves, motors, and conveyors. These devices have two or more physical states (for example Open, Closed, Moving), and are optionally controlled using a combination of discrete outputs. Their actual state is monitored via a combination of discrete inputs.

The meaning of the states depends on the kind of Discrete Device. In the case of a pump, the states might be configured as “Off” and “On”, while for a valve they might be configured as “Open”, “Closed”, or “Moving”. Note that a control valve has a continuous position represented by 0 to 100% and is not typically represented with a Discrete Device, since its state is represented by a continuous signal rather than discrete signal.

When a Discrete Device is commanded to a new state, it sets an appropriate combination of discrete outputs for that state. When its monitored discrete inputs change, the Discrete Device determines the new actual state of the equipment and sets the “PV” (process variable) appropriately.

Through the use of the Discrete Device the operator is guaranteed that a value displayed on the screen is a good and reliable value. This object will automatically display the state as “Bad” if the quality of any of the inputs is bad or the inputs are in an invalid combination determined at configuration time by the application developer.

Some of the features of the Discrete Device object are as follows:Input and Output states of the DiscreteDevice object are totally independent of each other and can be configured as required by the user’s application. Input and Output can be linked by alarms, which allow the object to detect CommandTimeout and UncommandedChange alarms, when devices unexpectedly change, or fail to change when commanded.Supports devices with two to three commandable states (‘Passive’, ‘Active1’, and ‘Active2’) plus two additional states ‘Fault’ and ‘InTransition’ which cannot be commanded. All those states with the exception of ‘InTransition’ and 'Passive' can trigger a state alarm.Supports the three input modes ‘Auto’, ‘Manual’, and ‘Simulate’.Supports the two control modes ‘Manual’ and ‘Cascade’.CtrlTrack allows a PLC to notify the Discrete Device that the PLC is in control of the state of the actual physical device, and is no longer accepting commands. If configured this way, the Command attribute of the DiscreteDevice object just tracks PV (i.e., the state indicated by its inputs).

Double Object

The Double object is derived from the FieldReference object.

FieldReference Object

The FieldReference object is the generic object for accessing data from an external device. This object can act as both the field input and a field output.

Wonderware Training


The FieldReference Object can be configured into three basic access modes:ReadOnly – Input objectReadWrite – Output object with scanned FeedbackWriteOnly – Output

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

Float Object

The Float object is derived from the FieldReference object.

Integer Object

The Integer object is derived from the FieldReference object.

Sequencer Object

The Sequencer object allows you to configure, execute, and manipulate a sequence of operations associated with ArchestrA attributes within a Wonderware Application Server application.

You can use it to automate:repetitive manufacturing procedures with a finite number of stepssupervisory processes with a finite number of steps

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

SQLData

The SQLData Object is an ArchestrA application object that can be used to store data to, and retrieve data from a SQL Server database. The SQLData Object provides the means to map data in a SQL database to attributes in a Galaxy.

String Object

The String object is derived from the FieldReference object.

Switch Object

The Switch object is the object for accessing data from a simple discrete (0/1) device. This object can act as both a discrete input and a discrete output.

The Switch Object can be configured into three basic access modes:ReadOnly – Input objectReadWrite – Output object with scanned FeedbackWriteOnly – Output

The PV value can be historized, logged as an event, and alarmed when abnormal.

UserDefined Object

The UserDefined object is an empty object that you can use to create customized objects. You can use the UserDefined object in the following ways:

As a "container" for other objects. An object relationship in which one object is comprised of other objects is called containment. Containment allows you to group various objects together to make complex objects. For detailed information on object containment, see the ArchestrA IDE documentation.



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

Note: A UserDefined object can only contain ApplicationObjects.

As a base object to extend through user-defined attributes (UDAs), scripting, and attribute extensions. For detailed information how to customize an object using these features, see the common editor documentation.

For example, you might create a UserDefined object called "Tank" and use it to contain ApplicationObjects that represent aspects of the tank, such as pumps, valves, and levels. You could create two DiscreteDevice object instances called "Inlet" and "Outlet" and configure them as valves, and create an AnalogDevice object instance called "Level" and configure an alarm to be triggered when it overflows. The containment hierarchy would be as follows:

--Tank --V101 (Inlet) --V102 (Outlet) --LT103 (Level)

The Tank object derived from the UserDefined object can be customized to raise an alarm when both the Inlet and Outlet valves are open. For example, you could add a Boolean UDA called "StateAlarm," extend it with an alarm extension, and add the following script:

if me.inlet == "Open" and me.outlet == "Open" then me.statealarm = true; else me.statealarm = false; endif;

You would now have a UserDefined object that forms the complex Tank object, which uses containment and has been extended to raise a specific process alarm.

Device Integration Objects

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

A more detailed discussion of the Device Integration Objects will take place later in this course in Module 2, “Application Infrastructure”, Section 4, “Connecting to the Field” on page 2-39

Wonderware Training


System Objects

System objects are used to define system instances.

AppEngine Object

The AppEngine Object must have a Platform on which to run. The key functionality of this object includes:

hosting application objects, device integration objects and areascontaining the logic to setup and initialize objects, when they’re deployed.containing the logic to remove objects from the engine, when they’re undeployed.determines the scan time within which all objects within that particular engine will execute.

In general the AppEngine contains no added value other then to support the creation, deletion, startup, and shutdown of objects.

Area Object

The Area Object plays a key role in alarm and event distribution. All AutomationObjects belong to an Area. Areas can contain sub-Areas. Areas provide a key organizational role in grouping alarm information and assigning it to those who use alarm/event clients to monitor their areas of responsibility.

This object is very simple; it only allows the value of three attributes to be historized:Active alarm counterUnacknowledged alarm counterDisabled (or silenced) alarm counter

InTouchViewApp Object

The InTouchViewApp object represents an InTouch for System Platform application. The InTouchVewApp object manages the check-in, check-out, and deployment of an InTouch application.

When you create an InTouchViewApp for a new InTouch application, WindowMaker is started by the ArchestrA IDE. You then create the application the same way you would if WindowMaker had been started from the InTouch Application Manager.

ViewEngine Object

The ViewEngine object is used to host InTouchViewApp objects. The ViewEngine object supports common engine features such as deployment, undeployment, startup and shutdown. One ViewEngine object can handle several InTouchViewApp objects.

WinPlatform Object

The WinPlatform platform object is a key base object. The key functionality of this object includes:Calculating various statistics related to the node it’s deployed to. These statistics are published in attributes.Monitoring various statistics related to the node it’s deployed to. These monitored attributes can be alarmed as well has historized.



Starting and stopping engines, based on the engines startup type, which are deployed to it.Monitoring the running state of engines deployed to it. If the platform detects an engine has failed it can (optionally based on the value of the engine’s restart attribute) restart the engine.

There is a special instance of the platform object called the galaxy platform. This platform instance:

Exists on the galaxy node. Is used by message exchange to bind unresolved attribute references

Templates and Instances

TemplatesTemplates are high-level definitions of the devices in your environment. Templates are like a cookie cutter from which you can make many identical cookies.

You define a template for an object, such as a valve, one time and then use that template when you need to define another instance of that item. Template names have a dollar sign ($) as the first character of their name.

A template can specify application logic, alarms, security, and historical data for an object.

A template can also define an area of your environment. You can extend and customize a template by adding User Defined Attributes (UDAs), scripts, or extensions to meet the specific needs of your environment. Objects inherit attributes from their parents.

Wonderware Application Server comes with predefined templates, called base templates. You cannot change these templates. All templates you create are derived from base templates.

You can also nest templates, or contain them. Contained templates consist of nested object templates that represent complex devices consisting of smaller, simpler devices, including valves. A reactor is a good candidate of containment.

Templates exist only in the development environment.

Wonderware Training


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

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

Instances Instances are the run-time objects created from templates in Wonderware Application Server. Instances are the specific things in your environment like processes, valves, conveyer belts, holding tanks, and sensors. Instances can get information from sensors on the real-world device or from application logic in Wonderware Application Server. Instances exist during run time.

In your environment, you may have a few instances or several thousand. Many of these instances may be similar or identical, such as valves or holding tanks. Creating a new valve object from scratch when you have several thousand identical valves is time-consuming. That's where templates come in.

Creating and Deleting InstancesApplicationObject instances are created from the templates provided by the Template Toolbox. A default name is given to the new instance. The newly created Object instance is put into focus and set to rename mode.

This view also allows the Object instance to be edited. Object instances can be deleted from this view if the Object does not have any other Objects assigned to it.

By default the first instance of the Platform object will be configured with the name of the Galaxy Repository node name. This platform can then be renamed.



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

Creating an Instance - Method 1Drag and drop the template object from the Template Toolbox to the Application View. To delete an instance of the Platform object highlight it and click on the Delete icon in the menu icon bar

, or, right-click on it and select Delete.

Notice you are looking atthe Model View.

Wonderware Training


Once the instance has been created it displays as follows:

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

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




Wonderware Training


Section 5 – System Requirements, Licensing and Support

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

System Requirements for Wonderware Application Server/Galaxy Repository

Minimum Hardware Requirements The following list shows the minimum computer hardware requirements to host Application Server version 3.1 components.

Galaxy Repository (GR) node2 gigahertz (GHz) or faster dual core processor, or a 3 GHz or faster single core processor. A dual core processor is strongly recommended for optimal performance Minimum of 2 gigabytes (GB) RAM. For Galaxies with more than 500 objects, 4 GB RAM is recommended in the GR node30 GB of available disk spaceSuper VGA (1024 x 768) or higher resolution video adapter and monitor. Network interface cardCD-ROM or DVD driveKeyboardMouse or a compatible pointing device

Development and Application nodes2 GHz or faster processorMinimum 1 gigabyte (GB) RAM. For improved performance 4 GB RAM is strongly recommended30 GB of available disk space Super VGA (1024 x 768) or higher resolution video adapter and monitorNetwork interface cardCD-ROM or DVD driveKeyboardMouse or compatible pointing device

The hardware requirements for using the Alarm Client and Trend Client at run time are the same as for the InTouch HMI version 10.1 run time.

The Windows Vista operating system imposes hardware requirements that may exceed the minimum requirements for Application Server version 3.1. If you intend to install Application Server 3.1 on a computer running Windows Vista, see the following Microsoft web site for hardware requirements:

www.microsoft.com/windows/products/windowsvista/editions/systemrequirements.mspx

Section ObjectivesDescribe the necessary system requirements for a successful installationDiscuss Licensing requirementsDiscuss Support services



Software Requirements This section describes the operating system, database, and other software requirements to install Application Server version 3.1.

Operating Systems SQL Server Database Requirements Other Software Requirements

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

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

Notes:

1. The Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server operating systems are not supported for Application Server version 3.1. An error occurs if you attempt to install or upgrade Application Server version 3.1 on a computer running any edition of the Windows 2000 operating system.

2. The computer designated as the Galaxy Repository node can run on Windows XP Pro only as a single-node configuration of Application Server. Windows Server 2003 is the recommended operating system for the GR node.

3. You can run Application Server only on computers running a 32-bit operating system. You cannot run Application Server on a computer running a 64-bit operating system.

4. The Bootstrap, IDE, and Galaxy Repository are supported by the following language versions of Microsoft operating systems: English, Japanese, Chinese, German, and French. The Galaxy Repository is also supported by the English, Japanese, Chinese, German, and French versions of Microsoft SQL Server 2005.

Operating Systems Wonderware Application Server ComponentsArchestrA IDE (Development

Node)

ArchestrA Run Time

(Application Node)

Galaxy Repository (GR Node)

Windows Vista Business (See Vista Restrictions) x x xWindows Vista Business SP1 (See Vista Restrictions) x x xWindows Vista Enterprise (See Vista Restrictions) x x xWindows Vista Enterprise SP1 (See Vista Restrictions) x x xWindows Vista Ultimate (See Vista Restrictions) x x xWindows Vista Ultimate SP1 (See Vista Restrictions) x x xWindows Server 2003 Standard Edition SP2 x x xWindows Server 2003 Enterprise Edition SP2 x x xWindows Server 2003 Standard Edition R2 SP2 x x xWindows Server 2003 Enterprise Edition R2 SP2 x x xWindows XP Professional SP3. See Note 2. x x See Note 2Windows XP Tablet x

Wonderware Training


SQL Server Database Requirements Microsoft SQL Server 2005 with SP2 is the only database supported by Application Server version 3.1. You must use the Standard or Enterprise editions of SQL Server 2005. Neither the Compact, Express, nor the Workgroup editions of SQL Server 2005 can be used as the Galaxy Repository.

SQL Server 2005 SP2 must be installed on the computer designated as the ArchestrA Galaxy Repository node prior to installing Application Server. You also cannot install and use Application Server on a computer that has both Microsoft SQL Server 2000 and Microsoft SQL Server 2005 installed. The Galaxy Repository locks the SQL Server maximum memory usage to 65% of the computer's physical memory. TCP/IP must be enabled on the computer hosting a SQL Server 2005 database. The TCP/IP protocol setting can be verified from the SQL Server 2005 Network Configuration under SQL Server Configuration Manager. The Microsoft SQL Server 2005 login for BUILTIN\Administrators group must be present and enabled.

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

Microsoft .NET Framework 3.5 Microsoft .NET Framework 3.5 must be installed on every computer that hosts an Application Server version 3.1 component. The Application Server installation program halts if .NET Framework 3.5 is not installed on the target computer. A dialog box appears requesting that you install .NET Framework 3.5. If you click Install Prerequisites, the installation program automatically installs .NET Framework 3.5.

Microsoft Visual Studio 2005 Microsoft Visual Studio 2005 is required only by the MXAccess and GRAccess toolkits distributed with Application Server.

Alarm Client and Trend Client RequirementsThe software requirements for using the Alarm Client and Trend Client at run time are the same as for the InTouch HMI version 10.1 run time. If you want to trend data from the Wonderware Historian (formally known as IndustrialSQL Server), version 9.0 or later is required.

The Trend Client is compatible with the following Wonderware products: InTouch 10.1Wonderware Application Server 3.1Wonderware Historian 9.0 ActiveFactory 9.2QI Analyst 8.1

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



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

Using Multiple Network Interface Cards with Windows Vista If you are using multiple network interface cards (NICs), you must configure certain settings for the firewall or else a remote Vista node cannot connect to the Galaxy Repository node.

A connection in Vista is a term used to define a network interface card (NIC), its settings and the settings of whatever the NIC is connected to. Under certain circumstances, the connection on your computer can change if, for example, the IP address on the computer to which you are connected changes. Your computer's connection can be affected by external factors. During computer startup, and each time a connection changes, Vista goes through an "Identifying" process to determine which profile should be assigned to the connection.

A profile is a collection of firewall settings that can be applied to a connection. There are three profiles currently defined in Vista: "Domain", "Public" and "Private".

The Domain profile is assigned automatically to a connection if a domain controller for the domain to which the computer is a member is found on the connection. The Public profile is designed to keep the computer from being visible to other computers on the network. Network discovery is turned off for the Public profile.

Wonderware Training


The Private profile is used for a more trusted environment. Network discovery is turned on for a Private profile. Firewall exceptions and rules can be created on any or all of these profiles.

This is important because the OS Configuration utility and the Vista Firewall utility apply their firewall exceptions to the Domain and Private profiles only.

As previously noted, you can specify which profile you want assigned to a connection as long as that connection is not a Domain connection. This is done through the "Network and Sharing Center". Click on the Network icon in the right side of the task bar and then click on one of the networks that is shown. You can change a connection from a Public profile to a Private profile. The firewall calls these settings "Profiles" but the network calls them "Location types."

On computers using dual NICs, the first NIC is normally connected to the domain and is assigned the Domain profile automatically. The second NIC is typically assigned the Public profile.

The first issue is that your entire computer (all connections) is restricted to the most restrictive of the profiles assigned to any connection. So if the second connection was assigned a profile of Public, none of the firewall exceptions set by the OS Configuration or Vista Firewall utilities will be allowed. The exceptions were set for Domain and Private only, not Public. You must set the second connection to the Private profile for any of the firewall exceptions to work.

The second issue is that it appears that a restart of your computer, or even a restart of a computer to which you are connected, can change your connection back to the Public profile. Once again the firewall exceptions will not be effective. You'll have to change the connection back to the Private profile after each restart or a restart of the connected computer.

To avoid these NIC issues and prevent the "Identifying" process from taking place on a connection and changing the assigned profile, certain items must be present in the definition of the connection. Follow the rules below:

1. If you have only one NIC, no action is required. The profiles and firewall rules are automatic.

2. If you have two NICs follow the actions below: If the second NIC is not physically connected to anything (that means no wire in it), no action is required. The profiles and firewall rules are automatic. If the second NIC is connected, it MUST be configured. Follow the rules for configuring a normal redundancy setup. Vista will identify this NIC and assign it a Private profile. If the NIC is not configured, Vista will assign a profile of Public to this NIC and cause all of the Wonderware product firewall exceptions to be deactivated on all NICs. For the NIC to be configured properly, give it an IP address, sub net mask and gateway address. The gateway address can be the same as the IP address. Usually these addresses will be the internal, non-routable addresses like 192.168.0.x or the 10.x.x.x range. If you have more than two NICs, make sure all connected NICs are configured with an IP address and default gateway address and have been assigned a profile of private.



Wonderware System Platform Licensing

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

Wonderware System PlatformThe Wonderware System Platform is licensed as a single product that includes the following individual features:

1 Application Server license sized by IO-count1 Historian Server Standard Edition license sized by Tag-count1 Information Server license1 Information Server Advanced Client license1 Device Integration Server licensen Application Server Platform licenses (where n is 2, 3 or 4) for the purpose of hosting:

an Application Object Serverthe Historian Serverthe Device Integration Serverthe Information Server

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

The Wonderware System Platform license is available in different sizes, each one offered as a unique combination of the following:

Application Server IO-countHistorian Server Tag-countthe number of Application Server Platforms included

Application Server IO Count Number of I/O points accessed by the Galaxy.Application Server Platform Count Number of dedicated Application Object Server nodes in the

application.Historian Server Count Number of Historian Server nodes in the application.Information Server and Clients Count Number of Information Server nodes in the application and

number of nodes that are going to access the servers remotely.

Device Integration Server Count Number of Device Integration Server nodes in the application.

InTouch for System Platform Count Number of visualization nodes required in the application.ActiveFactory Count Number of dedicated ActiveFactory nodes in the application.Development Studio Count Number of development workstations in the application.

Wonderware Training


Wonderware System Platform Options licenses, listed below, are added to this license as needed, depending on the size of the system and requirements:

additional Historian Servers with Platform available at different Tag-countsadditional Information Servers with Platformadditional Device Integration Serversadditional Application Server Platforms

Wonderware ClientsIn addition to the Wonderware System Platform, one or more of the following Wonderware Clients are usually required:

InTouch for System Platform (also available as Terminal Services Edition if needed)Information Server ClientActiveFactory

The InTouch for System Platform license includes an Application Server Platform and is available in different flavors, as follows:

InTouch for System Platform with Trend/Analysis*InTouch for System Platform without Trend/Analysis*InTouch for System Platform Read-only with Trend/Analysis*

* Trend/Analysis refers to an ActiveFactory license.

The Information Server Client license is available in two different versions:Information Server Advanced ClientInformation Server Standard Client; which lacks InTouch Write Back, InBatch and QI Analyst integration.

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

Wonderware Development StudioTo develop applications for the Wonderware System Platform one or more Wonderware Development Studio licenses are required. The Wonderware Development Studio license includes a single-node license to run the following products:

ArchestrA Integrated Development Environment (IDE)Application Server sized by IO-countApplication Server Platform for testing System Platform-based applicationsInTouch Development and RuntimeDevice Integration ProductsHistorian Server Standard Edition limited to 24 hour data retrieval and sized by Tag-countMicrosoft SQL Server



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

Information ServerInformation Server ClientActiveFactoryInControl

The Wonderware Development Studio license is available in different sizes, each one offering a unique combination of:

Application Server IO-countInTouch Tag-countHistorian Server Tag-count

Wonderware Training


InstallationFor instructions on installing Wonderware Performance Software, see the installation document located in the root folder of the installation CD.

Additionally, refer to the “Wonderware Software Installation” series of online seminars where a session corresponding to Wonderware Performance Softwqare 3.5 may be available.

Wonderware eLearning training options are located at http://www.wonderware.com/training

Product supportWonderware provides responsive, award-winning teams of specialists committed to delivering world-class customer support, training, and consulting services. For information on the various customer support programs, contact your local distributor or access the Wonderware Technical Support site online at http://www.wonderware.com/support/mmi/

You will find a variety of information on the Technical Support site including the Wonderware Developer Network (WDN) Library, Documentation, FAQs, Tech Alerts, Tech Articles, Tech Notes, and Tech Support Forums. When you first enter the site, you will have limited access. To gain access to the different areas and services, you must first register.

Also on the Technical Support site is the Technical Support Policies, Terms & Conditions guide which provides information on how to contact Technical Support, information on the support policies and procedures, and much more.


http://www.wonderware.com/training



Wonderware Training


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.

IntroductionIn order to successfully implement a project for the Wonderware System Platform environment, you should start with careful planning to come up with a working model of your plant or plant area. A six-step project workflow is provided that describes how to complete different tasks in a logical and consistent order, so that you minimize the engineering effort.

The project information that you define will become your guide when actually creating your industrial application using the ArchestrA IDE. The better your project plan, the less time it will take to create the application, and with fewer mistakes and rework.

Suggested Project WorkflowJust 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.

Section ObjectivesExplain a project workflow and area devices and why they are neededIdentify functional requirements and naming conventionsExpand on the concept of ArchestrA and how it relates to the manufacturing environment.Explain the benefits of migrating to an ArchestrA architectural environment.

Identify Field Devices and Functional Requirements

Define the Deployment Model

Define Naming Conventions

Define the Area Model

Plan Templates

Define the Security 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.

Identifying Field Devices and Functional RequirementsThe first step in project planning is to identify the field devices that you want to include in your application. Field devices include components such as valves, agitators, rakes, pumps, Proportional-Integral-Derivative (PID) controllers, totalizers, and so on. Some devices are made up of more base-level devices. For example, a motor is a device that may be part of an agitator or a pump.

After you have identified all of your field devices, you will then need to determine the functionality for each.

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

Wonderware Training


The following diagram shows a simple P&ID:

The key for this P&ID is as follows:FIC = Flow controllerPT = Pressure transmitterTT = Temperature transmitterFT = Flow transmitterCT = Concentration transmitterLT = Level transmitterLIC = Level controllerFV = Flow valve

Examine each component in your P&ID and identify each basic device that is used. For example, a simple valve can be a basic device. A motor, however, may be comprised of multiple basic devices.

Once you have created the complete list, group the devices according to type, such as valves, pumps, and so on. Consolidate any duplicate devices into common types so that only a list of unique basic devices remains, and then document them in your project planning worksheet.

Each basic device is represented in the ArchestrA IDE framework as an “object.” An instance of an object must be derived from a defined template. The number of device types in your final list will help you to determine how many object templates you will need to create for your application. You can group multiple basic objects to create more complex objects, which is a concept known as “containment.”

��

��

��

��

��

��

��

�

��

��

�

��

��

��

��

��

��

��

��

��

�

��

��

��

��

�

��

��

��

��



Identifying Functional RequirementsFor each unique device, you will need to define the functional requirements, which includes:

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

Defining Naming ConventionsThe second step in the workflow is to define the naming conventions for templates, instances, and object attributes. Naming conventions should adhere to:

Conventions that you use within your company.ArchestrA IDE naming restrictions. For example, you might have an instance tagname of:

YY123XV456

with the following attributes:

OLS, CLS, Out, Auto, Man

The following illustration shows how the naming convention in a traditional Human-Machine Interface (HMI) is different from the naming within ArchestrA IDE:

��

� ��

��

��

��

�� !�"#

�� !�"#$��%

�� !�"#$��%

�� !�"#$��

�� !�"#$��&

�� !�"#$'�

(��%

(��%

(��

(��&

('�

For more information refer to the InTouch to IAS Migration document

Wonderware Training


For ArchestrA IDE, references are created using this naming convention:

<objectname>.<attributename>

For example:

YY123XV456.OLS

Defining the Area ModelThe third step of the project workflow is to define the Area model. An Area is a logical grouping within your application that represents a portion of the layout of your plant. In a typical manufacturing plant, you would define the following Areas: Receiving Area, Process Area, Packaging Area and Discharge Area. You will need to define and document all of the Areas of your plant that will be part of your application.

Each object will need to be assigned to a particular Area. When you install Application Server, a single placeholder is created by default, called "Unassigned." Unless you specify otherwise, all object instances will be assigned to this placeholder location.

The following are a few tips for creating Areas:If you create all of your Areas first, you can easily assign an object instance to the correct Area if you set that particular Area as the Default Area; otherwise, you will have to move them out of the unassigned Area later.It is helpful to create a System Area to which you can assign instances of WinPlatform and AppEngine objects. WinPlatform and AppEngine objects are used to support communications for the application, and do not necessarily need to belong to a plant-related Area or any Area for that matter.Alarms will be grouped according to Areas.Areas can be nested.

When building an Area hierarchy, keep in mind that the base Area that is assigned to a Platform determines how the underlying objects will be deployed. If a plant area (physical location) is going to contain two computers running AutomationObject Server platforms, then two logical Areas will have to be created for the one physical plant area.

One approach for creating instances of an object is to create an instance for one Area at a time. If you use this approach, then mark the Area as the default, so that each instance is automatically assigned to the selected Area. Before you begin to create instances in another Area, change the default to the new Area.

A final consideration for constructing Areas is that the various Areas equate to alarm groups. It is at the Area level that alarm displays can easily be filtered.

Planning TemplatesA template is an element that contains common configuration parameters for objects that are used multiple times within a project. Templates are instantiated to represent specific objects within the application.

For example, you might need multiple instances of a valve within your application, so you would create a valve template that has all of the required properties. This allows you to define once and reuse multiple times. If you change the template, the changes can be propagated to the instances. You can use simple drag-and-drop within the ArchestrA IDE to create instances from templates.

Additional information on how to actually develop objects using templates is covered in Module 3, “Planning for Object Templates” on page 3-5.



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

Define Security Model: Each attribute of an AutomationObject is given a security classification. This provides the ability to define who can write to attributes of an object.

Define Deployment Model: The Deployment Model view shows which objects instances reside on which computers. In the ArchestrA environment, the physical location of object instances is not required to approximate the real-world environment it models. The Deployment view does not need to reflect your physical plant environment.

Wonderware Training


Lab 2 – Identifying the Mixer

IntroductionThis lab provides several detailed diagrams which identify components of a simulated factory layout for this training scenario, as well as the main pieces of equipment that you will model and develop during this course.

The following diagrams provided in this lab will be used as references: Factory Layout Heat Exchanger: Process Diagram & Field I/O Signals Mixer: Process Diagram & Field I/O Signals

Your instructor will assign you a student number that you will use to create the unique identifiers for each heat exchanger and mixer assigned to you.

This lab will help familiarize you with the plant processes on which the remaining labs are based.

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

Collect the proper information needed before proceeding to develop a Galaxy Use the naming convention and device structure defined for this class in subsequent labs



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



Wonderware Training


Identify the Sample Application

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

Description of the Mixer SystemThe mixer system consists of the following devices and functionality:

3 valves:Inlet 1: Inlet 1, which is used in conjunction with Pump 1 adds the first material into the tankInlet 2: Inlet 2, which is used in conjunction with Pump 2, adds the second material into the tankOutlet: drains the tank

2 pumps:Pump 1: Pump 1, which is used in conjunction with Inlet 1 adds the first material into the tankPump 2: Pump 2, which is used in conjunction with Inlet 2, adds the second material into the tank

1 motor:Agitator: Mixes the materials in the tank

2 metersLIT: Current level of the tankTT: Current temperature of the tank

Description of the Process

In this class a simulated mixer system process continuously executes batches (runs) with the following steps:

1. Add first material to the tank

2. Add second material to the tank

3. Mix the material in the tank

4. Drain the tank




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

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

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

Wonderware Training


Wonderware Training

Module 2

Application InfrastructureSection 1 – The Plant Model 2-3

Lab 3 – Creating the Plant Model 2-5

Section 2 – The Deployment Model 2-13

Lab 4 – Creating the Deployment Model 2-15

Section 3 – The Runtime Environment 2-25

Lab 5 – Using Object Viewer 2-29

Section 4 – Connecting to the Field 2-39

Lab 6 – Connecting to the Field 2-49

2-2 Module 2 – Application Infrastructure

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

Wonderware Training

Section 1 – The Plant Model 2-3

Section 1 – The Plant Model

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

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

The ArchestrA plant application model allows you to organize a distributed computing application by:

Once a plant application model has been developed, applications can be easily extended or replicated based on the structure you have provided. With this Facility Model you can:

Rapidly create application standardsDeploy 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.

Section ObjectivesExplain the importance of having a model of the plant facilityExamine the concept of how to utilize ArchestrA Application Server to model a specific facility

SectionPlant Production Line

Area Manufacturing Cell



Reporting Alarms Based on Area ModelWhen 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:

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.

• Area AutomationObjects All AutomationObjects and Area objects report detected alarms through the Area, which distributes them to alarm and event clients.

• WinPlatform AutomationObjects Report their own alarms and events

• AppEngine AutomationObjects Report their own alarms and events

• Device IntegrationObjects Report their own alarms and events

Wonderware Training


Lab 3 – Creating the Plant Model

IntroductionThis lab illustrates the steps necessary to create the plant model for the Galaxy based on the information gathered in Lab 2, “Identifying the Mixer”. You will create an additional $Area instance named ControlSystem to accommodate future system objects created throughout the rest of this class.

To help organize the templates, you will develop a custom toolset named Training to hold the templates created in the class.


Create new template toolsets Create derived templates Create instances Use the $Area object to create a plant model for the Galaxy



Create a Template Toolset

a. Create a new Template Toolset named Training under the Galaxy.

Create the Plant Model

b. Create a derived template from the $Area object named $tArea and assign it to the Training template toolset.

c. Create the following instances out of the new $tArea template:DischargeIntake Production Line1 Line2 ControlSystem

d. Arrange the new $tArea instances to model the factory layout defined in Lab 2.



Wonderware Training


Create a Template Toolset1. In the Template Toolbox, right-click on the Galaxy and select New Template Toolset.




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

Create the Plant Model3. In the Template Toolbox, expand System / $Area to create a derived template of the $Area

object by right-clicking the $Area template and selecting New / Derived Template.

Wonderware Training


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

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

6. Ensure that the Model view is selected.



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

8. Name the new instance Discharge.

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

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

Wonderware Training


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




Wonderware Training

Section 2 – The Deployment Model 2-13

Section 2 – The Deployment Model

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

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

Planning for Deployment Deploying your Galaxy copies the objects from the development environment to the run-time environment. This makes your objects "live" and functional.

Until you deploy your ArchestrA IDE configuration environment to the run-time environment, changes you make in the ArchestrA IDE do not appear in the run-time environment. To see run-time data associated with your objects, use Object Viewer or InTouch.

Objects deploy from the configuration environment to the run-time environment as follows:

Section ObjectivesExplain the concept of the Deployment Model.Demonstrate the structure and organizational execution of the Deployment Model.

IDE Configuration Environment deploys toObject Viewer,

Run-time environmentGalaxy database : [Does not exist in run-time environment]

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

Instance Objects : Instance objects [Run-time configuration and behavior]

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

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

Scripts configuration : Scripts execution

Alarms configuration : Alarms generate and acknowledge

History configuration : History Logs

[Wonderware Historian]



Deploying Objects You deploy object instances for three reasons:

TestingPlace the application into production to process field dataUpdate an existing application with changes you made

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

Redeploying Objects Redeploying is similar to deployment. While you are testing, you frequently redeploy your application to see changes you make. The redeploying process undeploys the object and then deploys it back.

You may have an object whose deployment state is Pending Update. That means the object changed since it last deployment. When you deploy those changes, the new object is marked as the last deployed version in the Galaxy.

Undeploying Objects You may need to undeploy one of more objects. Undeploying removes one or more objects from the run-time environment.

Before you start, you need to select the object or objects you want to undeploy in the ArchestrA IDE.

Before you delete or restore a Galaxy, undeploy all objects in the Galaxy.

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

Wonderware Training


Lab 4 – Creating the Deployment Model

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


Use the $WinPlatform, $AppEngine and $Area objects to create a deployment model for the GalaxyDeploy instances to the runtime environment



Create the WinPlatform Object a. Create a derived template from the $WinPlatform object named $tWinPlatform and assign it

to the Training template toolset.

b. Create an instance of the $tWinPlatform template named GRPlatform and assign it to the ControlSystem area.

Create the AppEngine Object c. Create a derived template from the $AppEngine object named $tAppEngine and assign it to

the Training template toolset.

d. Create an instance of the $tAppEngine template named AppEngine and assign it to the ControlSystem area.

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

areas on the AppEngine object.

Deploy the Objects f. Cascade deploy the GRPlatform.



Wonderware Training


Create the WinPlatform Object1. In the Template Toolbox, create a derived template of the $WinPlatform object by right-

clicking the $WinPlatform template and selecting New / Derived Template.

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

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




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

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

5. Name the new instance GRPlatform.

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

Wonderware Training


Create the AppEngine Object7. In the Template Toolbox, create a derived template of the $AppEngine object by right-

clicking the $AppEngine template and selecting New / Derived Template.

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

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

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



11. Name the new instance AppEngine.

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

Wonderware Training


Create the Deployment Model13. Select the Deployment view.

14. Assign the AppEngine instance to the GRPlatform.



15. Assign all remaining areas to the AppEngine instance.

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

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

Wonderware Training


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

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

18. Click Close to return to the ArchestrA IDE.

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




Wonderware Training


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.

Runtime EnvironmentThe previous workflow task defined the deployment model that specifies where objects are deployed. In other words, the deployment model defines which nodes will host the various AutomationObjects.

The objects deployed on particular platforms and engines define the objects' “load” on the platform. The load is based on the number of I/O points, the number of user-defined attributes (UDAs), and so on. The more complex the object, the higher the load required to run it.

After deployment, the Runtime environment facilitates the activity generated by the objects. In Application Server the Object Viewer is used to monitor the Runtime environment. The Object Viewer is used to check communications between nodes and determine if the system is running optimally. For example, a node may be executing more objects than it can easily handle, and it will be necessary to deploy one or more objects to another computer.

To view the activity in the Runtime database the Object Viewer is used. It displays the current value of all of the objects and object attributes in the database. In order to create the Runtime database, Application Server requires information about all of the variables being created. As object and object attribute values change (for example created, value change, configuration change), the changes are reflected in Runtime and monitored via the Object Viewer.

Object ViewerThe Object Viewer monitors the status of the objects and their attributes and can be used to modify an attribute value for testing purposes.

To add an object to the Object Viewer Watch list, right-click the attribute from the Attribute Name panel and select Add to Watch.

You can save a list of items being monitored. Once you have a list of attributes in the Watch Window, you can select all or some of them and save them to an XML file by right-clicking on the Watch window and selecting Save. A previously saved Watch window can also be loaded to monitor previously saved attributes. You can also add a second Watch window that shows as a separate tab in the bottom of the Viewer.

Section ObjectivesExplain the concept of the Runtime EnvironmentIllustrate the differences in the Development environment and the Runtime environmentExplain the use of the Object Viewer in monitoring the Runtime environment



Uploading Run-time Configuration You can upload run-time configuration changes to the Galaxy database. This lets you keep any attribute values that changed during run time.

The values of certain attributes can be set in the configuration environment, but they can also be changed by the user at run time. As a result, the values of these attributes can differ between the run-time and configuration environments.

For example. you create an object with a UDA myInteger. In the Object Editor, you specify an initial value of 30.

Then you deploy the object. At run time, you write a new value to myInteger of 31. If you redeploy this object, the original value of 30 overwrites any value assigned during run time.

If you want to upload run-time changes to the Galaxy, make sure the selected objects are: Not edited and checked in since last deployment or uploadNot in Pending Update stateChecked 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.

Deployed Objects sectionObjects deployed on the Platform.

Attributes sectionIndividual attributes of the object.

Attribute Monitoring section Location for monitoring attribute activity.

Wonderware Training


If you select an object that is currently checked out to you, a warning appears during run-time upload. If you continue, you lose all configuration changes you made to the checked out object. The Galaxy performs an Undo Check Out operation on it before the run-time attributes are copied to the Galaxy database.

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

To upload run-time changes to the Galaxy

a. Select one or more objects in the Model view or Deployment view. For example, you could select an entire hierarchy from AppEngine down.

b. In the Object menu, click Upload Runtime Changes. The run-time attributes of the selected objects are copied over those in the Galaxy database.




Wonderware Training


Lab 5 – Using Object Viewer

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


Open Object Viewer from the ArchestrA IDEAdd attributes to watch windows to get a live feed Create and rename watch windows within Object Viewer Save watch windows to disk



Using ObjectViewera. Open Object Viewer from within the ArchestrA IDE.

b. Rename the default watch window to Platform Info and add the following attribute references:

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

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



Instance Attribute NameGRPlatform CPULoadGRPlatform DiskSpaceFree[1]GRPlatform RAMAvailableAvg

Instance Attribute NameAppEngine Scheduler.ScanPeriodAppEngine ScanStateAppEngine ScanStateCmd

Wonderware Training


Using ObjectViewer1. In Model view, open Object Viewer by right-clicking the GRPlatform instance and selecting

View in Object Viewer.




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

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

Deployed Objects section.Objects deployed on the Platform.

Attributes section.Individual attributes of the object.

Attribute Monitoring section. Location for monitoring attribute

Wonderware Training


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

4. Click OK.

5. The tab is now labeled Platform Info.



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

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

Wonderware Training


7. Repeat the previous step for the following attributes: DiskSpaceFree

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

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



9. Right-click in the new Watch List 1 and select Rename Tab to rename the default Watch List 1 tab.

10. The Rename Tab dialog box displays. Enter Engine Info for the Tab Name field and click OK.

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

Wonderware Training


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

Scheduler.ScanPeriod ScanState ScanStateCmd

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



The Save As dialog box displays.

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

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

Wonderware Training


Section 4 – Connecting to the Field

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

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

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

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

Section ObjectivesBecome familiar with Device Integration Objects, I/O Server and Data Access ServerOverview of DI Objects



Wonderware SuiteLinkWonderware SuiteLink uses a TCP/IP-based protocol. SuiteLink is designed specifically to meet industrial needs, such as data integrity, high-throughput, and easier diagnostics. This protocol standard is supported for Windows 2000, Windows 2003 Server, and Windows XP.

SuiteLink is Not a Replacement for DDE. Wonderware recommends that DDE be used for internal client communication, and SuiteLink for communication over the network.

Each connection between a client and a server depends on your network situation.

SuiteLink provides the following benefits:Consistent high data volumes can be maintained between applications, regardless of whether the applications are on a single node or distributed over a large node count.Value Time Quality (VTQ) places a time stamp and quality indicator on all data values delivered to VTQ-aware clients.Extensive diagnostics of the data throughput, server loading, computer resource consumption, and network transport are made accessible through the Microsoft Windows NT® operating system performance monitor. This feature is critical for the scheme and maintenance of distributed industrial networks.The network transport protocol is TCP/IP using Microsoft’s standard Winsock interface.To use the SuiteLink Communication Protocol, the following conditions must be satisfied.

You must have Microsoft TCP/IP configured and working properly.You must use computer names (Node Names) of no more than 15 characters.For more information on installing and configuring Microsoft TCP/IP, see your Microsoft Windows operating system's documentation.Wonderware SuiteLink must be running as a service. If for some reason SuiteLink has been stopped, you will need to start it again. (SuiteLink is automatically installed as a Common Component when you install InTouch. It is configured to startup automatically as a Windows Service).

DDE and SuiteLink I/O AddressingDDE and SuiteLink identifies an element of data in an I/O data source program by using a three-part naming convention that includes the application name, topic name and item name. To obtain data from another application, the client program opens a communication channel to the server program by specifying these three items. Additionally, if the communication channel is between applications running in different computers, a node name must be specified too.

Node: Name of the computer the I/O data source program or service is running on.

Application: Name of the source program or service that provides I/O data to the client application. This is the name of the executable file without the extension.

Topic: It's an application-specific sub-group of data elements.

Item: Name of the actual individual data point to be access once the communication channel is opened.

For example, in the case of Excel as a server program, the application name is "Excel", the topic name is the name of the specific spreadsheet that contains the data and the item name is the identification of the cell on the spreadsheet to/from which the data is to be read/written.

Wonderware Training


OPCOPC is open connectivity in industrial automation and the enterprise systems that support industry. Interoperability is assured through the creation and maintenance of open standards specifications.

The first standard (originally called simply the OPC Specification and now called the Data Access Specification) resulted from the collaboration of a number of leading worldwide automation suppliers working in cooperation with Microsoft. Originally based on Microsoft's OLE COM (component object model) and DCOM (distributed component object model) technologies, the specification defined a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications to facilitate interoperability. The COM/DCOM technologies provided the framework for software products to be developed. There are now hundreds of OPC Data Access servers and clients.

A typical analogy for needing the original Data Access Specification is printer drivers in DOS and then in Windows. Under DOS the developer of each application had to also write a printer driver for every printer. So AutoCAD wrote the AutoCAD application and the printer drivers. And WordPerfect wrote the WordPerfect application and the printer drivers. They had to write a separate printer driver for every printer they wanted to support: one for an Epson FX-80 and one for the H-P LaserJet, and on and on. In the industrial automation world, one industrial device manufacturer wrote their Human Machine Interface (HMI) software and a proprietary driver to each industrial device (including every PLC brand). Another industrial device manufacturer wrote their HMI and a proprietary driver to each industrial device (including every PLC brand, not just their own).

Windows solved the printer driver problem by incorporating printer support into the operating system. Now one printer driver served all the applications! And these were printer drivers that the printer manufacturer wrote (not the application developer). Windows provided the infrastructure to allow the industrial device driver's solution as well. Adding the OPC specification to Microsoft's OLE technology in Windows allowed standardization. Now the industrial devices' manufacturers could write the OPC DA Servers and the software (like HMIs) could become OPC Clients.

The resulting selfish benefit to the software suppliers was the ability to reduce their expenditures for connectivity and focus them on the core features of the software. For the users, the benefit was flexibility. They could now choose software suppliers based on features instead of "Do they have the driver to my unique device?" They don't have to create a custom interface that they must bear the full cost of creating and upgrading through operating system or device vendor changes. Users were also assured of better quality connectivity as the OPC DA Specification codified the connection mechanism and compliance testing. OPC interface products are built once and reused many times; hence, they undergo continuous quality control and improvement.

The user's project cycle is shorter using standardized software components. And their cost is lower. These benefits are real and tangible. Because the OPC standards are based in turn upon computer industry standards, technical reliability is assured.

The original specification standardized the acquisition of process data. It was quickly realized that communicating other types of data could benefit from standardization. Standards for Alarms & Events, Historical Data, and Batch data were launched.



Device Integration Objects

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

DDESuiteLinkClient

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

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

There is a one-to-one relationship between an instance of the DDESuiteLinkClient object and a running I/O Server. If you want to reference data points in more than one I/O Server, you must configure and deploy more than one DDESuiteLinkClient object. For example, you would need to configure one DDESuiteLinkClient object to communicate to an TCP I/O Server and another one to talk to the GEHCS I/O Server.

When you configure the DDESuiteLinkClient object, you can specify one or more I/O Server topics to which access is required. At run time, all items that the Galaxy application requires for a

Wonderware Training


specified topic are updated with the latest values from the I/O Server. The rate at which the values are updated depends on how the topics were configured within the target I/O Server.

If you want to connect to a DDE I/O Server, specify login information that the DDESuiteLinkClient object uses to connect to the I/O Server.

From other objects and from scripts, you can reference the topics you configured for the DDESuiteLinkClient object. For example, you might configure the input source for a FieldReference object to reference an item for one of the topics. Thus, the FieldReference object input source is receiving data from an I/O Server through the DDESuiteLinkClient object.

To aid in rapid application development, you can create a list of topic items that appear in the ArchestrA Attribute Browser. To do this, specify the item address and associate it with a user-defined attribute name (alias). Creating the item list is not required in order to reference data from the I/O Server.

The reference syntax for a DDESuiteLinkClient object data point is: <objectname>.<topicname>.<itemname>

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

The <objectname> is the name that you choose to give to the DDESuiteLinkClient object.

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

InTouchProxy

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

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

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

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

There is a one-to-one relationship between an instance of the InTouchProxy object and a running InTouch node. An InTouch "node" is a unique combination of the computer name and InTouch application. If you want to reference data points in more than one InTouch node, you must configure and deploy more than one InTouchProxy object. For example, you would need to configure one InTouchProxy object to get data from an InTouch application running on Computer1 and another one to get data from an InTouch application running on Computer2.

When you configure the InTouchProxy object, you might want to specify one or more existing InTouch tagnames (items) to use as object attributes. At run time, if these attributes are added in the client (for example, the Object Viewer watch window), they are updated with the latest values from the InTouch items. InTouch sends a new data value for an item to the InTouchProxy object



each time the value changes. Any items that you configure for an InTouchProxy object automatically becomes available within the ArchestrA Attribute Browser.

From other objects and from scripts, you can reference the attributes you created for InTouch items. For example, you might configure the input source for a FieldReference object to reference one of these InTouchProxy object attributes. Thus, the FieldReference object's input source would be receiving data from a tag in an InTouch node through the InTouchProxy object. The reference syntax for an InTouchProxy object data point is:

<objectname>.<InTouchTagName>

The <objectname> is the name that you choose to give to the InTouchProxy object.

The group of specified InTouch items for an InTouchProxy object is also known as the "scan group." Only one scan group exists in the InTouchProxy object. Run-time object attributes within the scan group allow you to monitor errors related to the data quality for InTouch item values in a scan group.

OPCClient

The OPCClient object is a key member of the core set of AutomationObjects within the ArchestrA system infrastructure. The OPCClient object is a DeviceIntegration (DI) object that allows access to a running OPC Data Access (DA) Server. A third-party OPC DA Server can provide data points to Galaxy application objects through the OPCClient object.

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

There is a one-to-one relationship between an instance of the OPCClient object and a running OPC DA Server. If you want to reference data points in more than one OPC DA Server, you must configure and deploy more than one OPCClient object. For example, you would need to configure one OPCClient object to communicate to an TCP OPC Server and another one to talk to the CIP OPC Server.

An OPCClient object supports the following operations on I/O points for the OPC DA Server: Subscriptions, which are implemented via scan groups. Read transactions, which are implemented via block reads.Write transactions, which are implemented via block writes.

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

RedundantDIObject

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

This capability allows clients to configure redundant connections to a field device.

The RedundantDIObject is a DeviceIntegration object that makes redundant connections to a field device possible. If one of the source objects is unable to provide connection to the field device, the RedundantDIObject automatically switches to the other source object for continued data acquisition.

The way the RedundantDIObject determines that a data source is in Bad state by monitoring the ConnectionStatus attribute common to all DIObjects, the ProtocolFailureReasonCode attribute that reflects a failure in communication by a DAS DIObject with a field device, and the ScanState attribute common to all ApplicationObjects. When those attributes are, respectively, Disconnected,

Wonderware Training


non-zero, or Offscan, the status of the corresponding data source object is changed and a switchover attempt is made to the other data source.

There is a one-to-two relationship between an instance of a RedundantDIObject and a pair of source DeviceIntegration objects.

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

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

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

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

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

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

RedundantDIObjects belong to a family of objects called DINetwork objects.

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

Scan ModeThe scanning mode for the scan group, either ActiveOnDemand, Active, or ActiveAll. For the ActiveOnDemand mode, attributes that are not actively being referenced by any client or object are not scanned. For the Active mode, an attribute is always in the active scanning state. When the last reference to the attribute is unregistered (unadvised), the attribute is deleted. For ActiveAll, an attribute is always in the active scanning state, but when the last reference to the attribute is unregistered (unadvised), the attribute is not deleted.

To enable Advanced Communication Management, you must:Select Advanced Communication Management for your Galaxy.



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

I/O ServerDifferent I/O data sources have different requirements. Two main groups are identified:

Legacy I/O Server applications (SuiteLink, DDE, and OPC Servers) do not require a platform on the node on which they run. They can reside on either a standalone or workstation node.

However, the DI Objects used to communicate with those data sources such as the DDESuiteLinkClient object, OPCClient object, and InTouchProxy objects must be deployed to an AppEngine on a Platform. Although it is not required that these DI Objects be installed on the same node as the data server(s) they communicate with, it is highly recommended in order to optimize communication throughput.For Device Integration objects like CIP and TCP DINetwork objects, both the DAServer and the corresponding DI Objects must reside on the same computer hosting an AppEngine.

I/O Servers can run on Workstations, provided the requirements for visualization processing, data processing, and I/O read-writes can be easily handled by the computer. Run the I/O Server and the corresponding DI Object on the same node where most or all of the object instances (that obtain data from that DI Object) are deployed.

This implementation expedites the data transfer between the two components (the I/O Server and the object instance), since they both reside on the same node. This implementation also minimizes network traffic and increases reliability.

However, it is good practice to evaluate the overhead necessary to run each

Data Access Server (DA Server)DAServers, are designed to provide simultaneous connectivity between plant floor devices and modern DDE, SuiteLink and/or OPC based client applications. DAServers support the OPC Data Access 2.05 specification and offer additional features beyond the standard, including powerful diagnostics and remote configuration capabilities. They offer enhanced communication diagnostics and performance.

Each DAServer is designed to provide simultaneous connectivity between client applications based on Wonderware SuiteLink, OPC and DDE protocols that run on Microsoft's Windows® operating systems and the data devices supported by the specific protocol being translated.

Several standard features are available with each DA Server, including:Compliance with OPC version 2.05 Stand-alone operation mode Support for hot configuration, device additions and device- and server-specific parameter modifications A wide range of DA

Servers support connectivity to numerous protocols and products. Wonderware's current DA Servers offering also includes support for:

Allen-Bradley's CIP protocol for ControlLogix Allen-Bradley's TCP protocol Allen-Bradley's DH Plus protocol Siemens' Simatic Net S7

Wonderware Training


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.




Wonderware Training


Lab 6 – Connecting to the Field

IntroductionIn this lab the $DDESuiteLinkClient object is used to create a connection to an InControl application running the simulation that will feed your Galaxy for the rest of this class.

The InControl application effectively simulates the functionality of a regular IO Server or DA Server connected to a real PLC.


Create and configure a $DDESuiteLinkClient object to connect to an IO Server or DA Server using SuiteLink as the communication protocol Monitor the connection status of the $DDESuiteLinkClient object on runtime



Create the Device Integration objecta. Derived a new template from the $DDESuiteLinkClient object, name it

$tDDESuiteLinkClient, and assign it to the Training template toolset.

b. Create an instance of the $tDDESuiteLinkClient template and name it InControl.

c. Configure the General tab of the new instance as follows: Server node: <ask your instructor> Server name: RTEngine Communication protocol: SuiteLink

d. On the Topic tab, add a topic called tagname and import the InControl Items List.csv file from the C:\Wonderware Training folder.

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

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

object.

Verify the Connection on Runtimeg. Open Object Viewer from within the ArchestrA IDE.

h. Using the watch list created in Lab 5, create a new watch window called InControl and add the following attribute references from the InControl instance:

ConnectionStatus Reconnect ServerNode ServerNameCommunicationProtocol ScanGroupList (enter 1 as the array index)

i. Save the watch list.



Wonderware Training


Create the Device Integration object 1. Expand the Device Integration toolset.

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

3. Name the new template $tDDESuiteLinkClient.

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




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

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

Wonderware Training


7. In the General tab, configure the object as follows: Server node: <ask your instructor>. The following figure uses ‘TRAININGPC’ as an example. Server name: RTEngine Communication protocol: SuiteLink

8. Select the Topic tab.

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



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

The Open dialog box displays.

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

12. Click the Open button.

Wonderware Training


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

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



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

16. Click the OK button.

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

Deploy the Object 18. Select the Deployment view.

19. Assign the InControl instance to the AppEngine object.

Wonderware Training


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

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

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

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



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

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

Wonderware Training


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

View in Object Viewer.

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

25. The Object Viewer application opens to display the attributes of the selected object in the right panel.

26. If you closed Object Viewer, open your watch list by right-clicking the Watch List (bottom section of Object Viewer) and select Open to open the My Watch Windows file.

27. Right-click in the Watch List and select Add Watch Window to add a new tab to the watch list.

28. Right-click in the Watch List and select Rename Tab to rename the default Watch List 1 tab.

29. The Rename Tab dialog box is displayed. Name the new tab InControl.



30. Click OK.

31. In the Attribute List (right section of Object Viewer) locate the following attributes, right-click on them, and select Add to Watch to add them to the watch list. You may also click and drag each attribute to the InControl watch list.

ConnectionStatus CommunicationProtocol Reconnect ServerName ServerNode ScanGroupList (enter 1 as the array index)

Verify that the InControl.ConnectionStatus Value is Connected.

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

Wonderware Training

Module 3

Application ObjectsSection 1 – Templates and Instances 3-3

Section 2 – The $UserDefined Object 3-9

Lab 7 – Modeling the Heat Exchanger 3-11

Section 3 – Change Control and Propagation 3-25

Lab 8 – Configuring Change Control and Propagation 3-27

Section 4 – The $AnalogDevice Object 3-35

Lab 9 – Modeling a Meter 3-37

Section 5 – The $DiscreteDevice Object 3-41

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

Section 6 – Containment 3-61

Lab 11 – Creating the Mixer 3-67

3-2 Module 3 – Application Objects

Module ObjectivesBe able to

Identify and work with templatesDerive and configure templates

Wonderware Training

Section 1 – Templates and Instances 3-3

Section 1 – Templates and Instances

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

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

Section ObjectivesThis section:

Introduces you to the concept of templates and explain how to derive a template.



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

Instances Instances are the run-time objects created from templates in Wonderware Application Server. Instances are the specific things in your environment like processes, valves, conveyer belts, holding tanks, and sensors. Instances can get information from sensors on the real-world device or from application logic in Wonderware Application Server. Instances exist during run time.

In your environment, you may have a few instances or several thousand. Many of these instances may be similar or identical, such as valves or holding tanks. Creating a new valve object from scratch when you have several thousand identical valves is time-consuming. That's where templates come in.

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

Wonderware Training


Planning for Object TemplatesThe fourth step in the workflow is to determine the templates that you will need. A template is an element that contains common configuration parameters for objects that are used multiple times within a project. Templates are instantiated to represent specific objects within the application. Both the templates and the instances created from them are called ApplicationObjects.

For example, you might need multiple instances of a valve within your application, so you would create a valve template that has all of the required properties. This allows you to define once, and reuse multiple times. If you change the template, the changes can be propagated to the instances. You can use simple drag-and-drop within the ArchestrA IDE to create instances from templates.

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

For your project planning, document which existing template can be used for which objects, and what templates you will need to create yourself.

A child template that you derive from a parent template can be highly customized. You can implement user-defined attributes (UDAs), scripting, and alarm and history extensions.



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

Deriving a TemplateTemplates are either derived from Base Objects, existing templates or created within the ObjectToolkit and imported.

Base templates cannot have their attributes configured. However, a template can be derived from one of the base templates. That derived template can then be configured and customized for attributes unique to the object it is modeling. Once that derived template is configured, instances of it can be created. Each instance will have all the attributes of the derived template.

Upon derivation the new template is created within the default toolset. The new template is created and placed into rename mode. The new template will inherit all attributes and associations of the original template that were locked. If the default toolset does not exist then the system will create it when the derived template is created. Creating a derived template is available from the Template Toolbox and the Derivation view as well as by using keyboard shortcut keys.

When creating an instance of an object that object instance will need to be configured independently. When deriving a template an instance of the template is created that takes on all of the attributes of the template from which it was created. This propagation of objects of a like kind can have a tremendous impact on the ability to create multiple instances of template derived objects containing fully replicated attributes.

Wonderware Training


Leveraging of Template Instances

To derive a Template from another one, do the following:

a. Select the Template in the ArchestrA IDE the new Template is to be derived from.

b. Right-click the selected Template and click Derived Template on the Create submenu of the context menu. The new Template is created, placed in the same toolset as the original Template, and set in rename mode.

c. Rename the derived Template.

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




Wonderware Training

Section 2 – The $UserDefined Object 3-9

Section 2 – The $UserDefined Object

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

$UserDefined ObjectThe UserDefined object provides the basic functionality you need to develop an ArchestrA supervisory application. The UserDefined object provides this functionality as Field Attributes, scripts, User Defined Attributes (UDAs), and attribute extensions.

You can configure Field Attributes as an Analog or Discrete type with one of the following access modes:

Input. The Field Attribute only accepts input. The Field Attribute is updated based on the value that is read from the configured input address.InputOutput. The Field Attribute accepts input and sends output. The output destination can optionally differ from the input source address. The InputOutput mode supports the User writeable and Object writeable attribute categories.Output. The Field Attribute only sends output. The Field Attribute writes to the specified output destination. The Output mode supports the following categories:

CalculatedCalculated retentiveUser writeableObject writeable

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

The Analog Field Attribute supports the following data types: IntegerFloatDouble

The Analog Field Attribute provides the enabling and configuration for the following functionality: Scaling of Input and Output valuesHistoryHiHi, Hi, Lo and LoLo Limit AlarmsRate of Change AlarmsTarget Deviation AlarmsBad Value AlarmStatistics


Introduces you to the $UserDefined object and its functionality.



The Discrete Field Attribute provides the enabling and configuration for the following functionality: State LabelsHistoryState AlarmBad Value AlarmStatistics

The UserDefined object is an object that you can use to create customized objects. You can use the UserDefined object as a template, or as a container.

As a template

Use the UserDefined object as a template containing Field Attributes associated to multiple variables in a system. In this case, the object provides a simple and manageable structure as all the variables are contained in the same object.

For example, you might create a UserDefined object called “Tank” and configure Field Attributes that represent variables associated to the tank system:

LT100 - Analog Field Attribute - Input from a level transmitter configured with options such as: Scaling, Limit alarms and Statistics (Min/Max/Avg).TT100 - Analog Field Attribute - Input from a temperature transmitter configured with options such as Rate of Change alarm and Statistics (Min/Max/Avg).SW100a - Discrete Field Attribute - Input from a limit switch configured with options such as State Labels and State alarm.SW100b - Discrete Field Attribute - Input from a limit switch configured with options such as State Labels and State alarm.XV100a - Discrete Field Attribute - InputOutput to a solenoid valve configured with options such as State Labels, State alarm, and Statistics (Open/Close time).XV100b - Discrete Field Attribute - InputOutput to a solenoid valve configured with options such as State Labels, State alarm, Statistics (Open/Close time).

References between attributes in the object can be accomplished by using relative reference, for example:

The “Tank” can be customized to raise an alarm when both XV100a and XV100b valves are open. For example, you can add a Boolean UDA called “ValueOpenAlarm”, extend it with an Alarm Extension, and then add the following OnExecute script:

IF me.XV100a == "Open" AND me.XV100b == "Open" THEN me.ValueOpenAlarm = true;

ELSE me.ValueOpenAlarm = false;

ENDIF;

As a “container”

Use the UserDefined object as a “container” for other objects. An object relationship in which one object is comprised of other objects is called containment. Containment allows you to group various objects together to make complex objects.

Wonderware Training


Lab 7 – Modeling the Heat Exchanger

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


Configure and use object templates to create instances that will inherit configurations Use the Field Attributes functionality provided by the $UserDefined object Use the Galaxy Browser to build references to instance attributes within the Galaxy



Create the Heat Exchanger Template

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

b. Add to the $HeatEx template four analog field attributes named T1, T2, T3 and T4. Configure each field attribute as follows:

Create and deploy a Heat Exchanger Instance

c. Create an instance of the $HeatEx template (leave the default name) and assign it to the Intake area.

d. Configure the Input source of each one of the four field attribute references, where XX is your student number:

e. Deploy the object.

View the Heat Exchanger Data in Runtime

f. Open Object Viewer from within the ArchestrA IDE.

g. Using the watch list created in Lab 5, add a new watch window named HeatEx with the following attributes from the HeatEx_001 instance:

T1 T2 T3 T4

h. Save the watch list.


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

Field Attribute Instance Attribute NameT1 InControl tagname.HE1XX_TC1T2 InControl tagname.HE1XX_TC2T3 InControl tagname.HE1XX_TC3T4 InControl tagname.HE2XX_TC3

Wonderware Training



Create the Heat Exchanger Template 1. In the Template Toolbox, expand the Application toolset.

2. Create a derived template of the $UserDefined object by right-clicking the $UserDefined template and selecting New / Derived Template.

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




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

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

Wonderware Training


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

7. Configure the new field attribute as follows:

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



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

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


11. Click OK.

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

13. Click the Close button.

Wonderware Training


Create a Heat Exchanger Instance 14. Using the Template Toolbox and the Model view, create an instance of the $HeatEx template

using the default name of HeatEx_001.

15. Assign the instance to the Intake area.

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

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



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

19. The Galaxy Browser window appears.

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

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

Wonderware Training


22. Click OK.

The Input source attribute contains the selected reference:

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

24. Click the Save and Close button .


26. Click OK.



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

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

Wonderware Training


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

28. Click OK to accept the default settings.

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

29. Click Close when the deployment is complete.



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

Wonderware Training


View the Heat Exchanger Data in Runtime 30. Right-click the HeatEx_001 instance and select View in Object Viewer to show the

HeatEx_001 object and its attributes in Object Viewer.

31. The Object Viewer application opens displaying the attributes of the selected object. If you closed Object Viewer, click File / Load Watch List to open the watch list file you saved earlier.


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

The Rename Tab dialog box is displayed.

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



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

T1 T2 T3 T4

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


Wonderware Training

Section 3 – Change Control and Propagation 3-25

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.

Locking an attribute in a Template indicates that its value is to be logically “shared” with all derived objects (Templates or instances). In other words, when the value changes in the template, that change is propagated to all the derived children of the object. When an attribute is “locked” in the Template, the value can be changed in that Template but not in any of the derived children.

Based on this concept, an attribute can have one of three logical lock types:

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

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

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

Locking an Attribute

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



To lock a Template attribute, do the following:

a. Select the desired Template in the ArchestrA IDE and start its editor.

b. Enter a value in an attribute field in the object’s editor.

c. Select the locking mechanism for that attribute. Some editors may have lock icons associated with certain edit fields, but this possibility is within the scope of the developer of the object’s editor.

d. Save and close the object editor.

The locked attribute in any derived templates and instances created from this template are locked and unavailable. To test this, you can derive a new template or create an instance from the original template, and then check the new object’s editor. The locked attribute is unavailable for editing.

Unlocking an AttributeTo unlock a Template attribute, do the following:

a. Select the desired Template in the ArchestrA IDE and start its editor.

b. Select the locking mechanism for the locked attribute in the object’s editor. Some editors may have lock icons associated with certain edit fields, but this possibility is within the scope of the developer of the object’s editor.

c. Save and close the object editor.

The previously locked attribute in any instances created from this template are now unlocked. The previously locked attribute in any templates derived from this template are still Locked (in me). The previously locked attribute in any instances of derived templates remain in Locked in Parent.

Wonderware Training


Lab 8 – Configuring Change Control and Propagation

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


Lock attributes in templates to control the changes that can be made on derived objects Propagate changes from templates to derived object by modifying the value of locked attributes



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

Verify the Changes to the Existing Instance b. Open the configuration editor for the HeatEx_001 instance to verify the changes made in the

template.

Redeploy the Object c. Redeploy the object.



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

Wonderware Training


Lock the Attributes1. In the Training template toolset, double-click on the $HeatEx template to open its

configuration editor.




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

Engineering units: ‘Celsius’ and locked

Scaling section: locked

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

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


Wonderware Training


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

Verify the Changes to the Existing Instance 5. Double-click the HeatEx_001 instance to open its configuration editor and verify the changes.

6. Select the T1 field attribute and expand the Enable I/O scaling section and verify the changes.



7. Save and Close the editor.

Redeploy the Object Notice that the InControl instance icon has changed; a square that is shaded with a black triangular shape has been added to indicate the object configuration has changed in the deployed object, but the change is not deployed.

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

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

9. Leave the default settings and click OK.

Wonderware Training


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

10. Click Close.




Wonderware Training

Section 4 – The $AnalogDevice Object 3-35

Section 4 – The $AnalogDevice Object

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

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

AnalogDevice Object as a Basic Analog Input/Output ObjectAnalogDevice Object as an Analog Regulator Object

AnalogDevice Object as a Basic Analog Input/Output Object When configured as a basic analog device, this object provides a means for reading and optionally writing analog signals from the field or from another object. The basic I/O characteristics are:

The process value (PV) is read from the field (except when the AnalogDevice object is configured to be in Manual mode).You can configure the AnalogDevice object to enable or disable analog output. If you enable output, you can configure the output destination address to be the same (default) or different from the input source address. Commands to change the PV will result in an output to field. For data integrity, the value of PV represents the value read from the external controller (except when the AnalogDevice object is in Manual mode), not the requested PV that is output to the external controller.The input and outputs can be optionally scaled between raw counts and engineering unit values using either linear or square-root conversions.

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

In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV value. If you enable the PV override, then you can use the PV.Mode attribute to place the AnalogDevice object into either Auto or Manual mode. When the AnalogDevice object is in Auto mode, the PV is updated from the field and matches the value and quality of the PVAuto attribute. When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated from the field, but the PV value does not. Instead, the PV can be set by a user write or a script, and the quality is always set to UNCERTAIN.

Finally, you can configure the AnalogDevice object to historize key variables, including PV and PV.Mode.


Introduces you to the concept of the $AnalogDevice object and its functionality.



AnalogDevice Object as an Analog Regulator Object When configured as an analog regulator device, the AnalogDevice object provides a means for reading and optionally writing two separate analog signals from the field or from another object: one PV value and one setpoint (SP) value. The basic I/O characteristics are:

The process value (PV) is read from the field (except when the AnalogDevice object is configured to be in Manual mode), but is never written.The SP value is both read from the field and written to the field. You can configure the SP output destination address to be the same (default) or different from the input source address. Commands to change SP result in an output to field. For data integrity, the value of SP always represents the value read from the external controller, not the requested SP that is output to the external controller.The PV and SP can be optionally scaled between raw counts and engineering unit values using either linear or square-root conversions.

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

In addition, you can configure the AnalogDevice object to allow or disallow the overriding of the PV value. If you enable the PV override, then you can use the PV.Mode attribute to place the AnalogDevice object into either Auto or Manual mode. When the AnalogDevice object is in Auto mode, the PV is updated from the field and matches the value and quality of the PVAuto attribute. When the AnalogDevice object is in Manual mode, the PVAuto attribute continues to be updated from the field, but the PV value does not. Instead, the PV can be set by a user write or a script, and the quality is always set to UNCERTAIN.

Other controller-oriented features that can be configured for an AnalogDevice object of type analog regulator include:

Controller mode (CtrlMode attribute). You can use the controller mode to govern what types of writes are allowed to the SP value within the system. Controller mode options are Manual, Cascade, and None. When the object is in Manual mode, only end users are allowed to command a change in the value of SP. In Cascade mode, only scripts or other supervisory objects are allowed to command a change to SP. Finally, if None is specified for the controller mode, any type of write is allowed for the SP.Control tracking. A Boolean control track flag can be read from an external device or object. When tracking is on, the external controller "owns" the value of the SP; the SP is purely read-only and cannot be commanded to be changed and output to the field.

Wonderware Training


Lab 9 – Modeling a Meter

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


Configure an $AnalogDevice object



Create the Meter template a. Derived a new template from the $AnalogDevice object, name it $Meter, and assign it to the

Training template toolset.

b. Configure the object as follows:



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

Wonderware Training


Create the Meter Template1. In the Training template toolset, right-click the $AnalogDevice template and select New /

Derived Template to create a derived template of the $AnalogDevice object.

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

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




4. Configure the General tab as follows:


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

Wonderware Training


Section 5 – The $DiscreteDevice Object

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

$DiscreteDevice ObjectThe DiscreteDevice object is a general purpose ApplicationObject that represents a large class of physical equipment common in manufacturing, such as pumps, valves, motors, and conveyors. These devices have two or more discrete physical states (for example, Open, Closed, and Moving). The actual state of a device is monitored using a combination of discrete inputs, and a device can be optionally controlled using a combination of discrete outputs.

The state names are configurable and are mapped to both input and output Boolean combinations in truth-table form. The meaning of the states depends on the type of discrete device. For a pump, the states might be configured as "Off" and "On," while for a valve they might be configured as "Open," "Closed," and "Moving." Note that a control valve has a continuous position represented by an analog signal of 0 to 100% and is not properly represented with a discrete device. Control valves are best represented with the AnalogDevice object.

When a DiscreteDevice object is commanded to a new state, it sets the configured combination of discrete outputs for that state. When one or more of its monitored discrete inputs change, the DiscreteDevice object determines the new actual state of the equipment and sets the process value (PV) appropriately.

Input and output states are totally independent of each other and can be configured as required by your application; however, the input and output states can be linked by alarms. This allows the object to detect a command timeout and uncommanded change alarms when devices unexpectedly change, or fail to change when commanded to do so.

Historization of key attributes including the current state (PV) and commanded state (Cmd) can also be configured.

Finally, the DiscreteDevice object supports a rich set of statistics reporting that you can enable during configuration.

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

Passive

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

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


Introduces you to the concept of the $DiscreteDevice object and its functionality.



Second Active

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

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

The fault state occurs when the feedback that is coming from the field is incorrect or impossible based on how the discrete device works. For example, a fault would occur if the Hi and Lo limit is being reached at the same time for a single device. Examples of fault state names are "Error," "Bad," or "Broken."

Monitoring a Discrete Device through Inputs If you configure the DiscreteDevice object to have inputs (feedback) from the field, the input values are used to update the overall state of the device. A DiscreteDevice object can have up to four inputs. After defining the inputs, map the different input combinations to the possible states for the device.

For example, you might have a valve on your discrete device that can be either opened or closed. You have defined the passive state of the device as Closed, the first active state as Opened, and the fault state as Bad. You would then create references for two field inputs: one for the open position (Valve_Open), and one for the closed position (Valve_Close). You then would map the inputs to the defined states. For example:

Valve_Open Valve_Close Mapped State

0 0 Transition

0 1 Closed

1 0 Opened

1 1 Bad

where:

1=TRUE

0=FALSE

By default, when the monitored discrete inputs change, the DiscreteDevice object determines the new actual state of the equipment and updates the value of the process value (PV) appropriately.

You can configure the DiscreteDevice object to allow or disallow overriding of the PV value. If you enable the PV override, then the object can be placed in Auto, Manual, or Simulate modes using the PVMode attribute.

When the object is in Auto mode, the PV updates from the field and matches the value and quality of PVAuto. When the object is in Manual mode, PVAuto continues to update from the field but the PV does not. Instead, the PV can be set by a user or script and the quality is always marked as UNCERTAIN.

Wonderware Training


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

Controlling a Discrete Device through Outputs You can control (command) the passive, first active, and second active states of the discrete device using the Cmd attribute. The transition and fault states are not commandable. When a DiscreteDevice object is commanded to a new state, it sets an appropriate combination of discrete outputs for that state.

For example, you might map the first active state of "Open" to a discrete device output reference that will turn a valve to the open position. When you set the Cmd attribute to "Open," the valve is "commanded" to be opened. If inputs (feedback) are configured for the DiscreteDevice object, the object could then detect when the valve is actually open or closed.

Commanding a discrete device to a new state does not directly change the PV unless you have the PVMode set to "Simulate."

Controller-oriented features for the DiscreteDevice object include: A configurable control mode. The control mode (Manual or Cascade) determines what types of writes are allowed to the Cmd value within the system. Manual indicates that only users (operators) are allowed to request a change to Cmd, whereas Cascade indicates that only scripts or other supervisory objects are allowed to request a change to Cmd. Control tracking. A Boolean control track flag can be read from an external device or object. When tracking is on, the external controller "owns" the value of the Cmd; the Cmd is purely read-only and is set to the value of PV.

Alarm Capabilities The DiscreteDevice object provides sophisticated alarming capabilities, including:

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

Statistical Features The DiscreteDevice object offers advanced built-in state tracking calculations that can be used for equipment monitoring and time-in-use tracking, including:

The most recent time durations of the Active1, Active2 and Passive states.The total accumulated time durations of the Active1, Active2 and Passive states, with optional alarming on the Active1 and Active2 total durations.The number of transitions into the Active1, Active2 and Passive states.A commandable reset of all statistics.




Wonderware Training


Lab 10 – Modeling a Valve, Pump, and Motor

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


Configure a $DiscreteDevice object



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


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

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

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

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


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

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

Number of Inputs: 2 (locked) Input Name: (locked) Input 2 Input Name: CLS Input 1 Input Name: OLS Input to PV Map: (locked)

0 0: Traveling0 1: Open1 0: Closed1 1: Fault

PV override: (locked)

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

Wonderware Training


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


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

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

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

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


Enable second active state:

Unchecked (locked)

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

Number of Inputs: 1 (locked) Input Name: (locked) Input 1 Input Name: FlowSwitch Input to PV Map: (locked)

0: Stopped1: Running


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



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


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

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

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

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



Enable second active state:

Unchecked (locked)

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

Number of Inputs: 1 (locked) Input Name: (locked) Input 1 Input Name: AuxContact Input to PV Map: (locked)



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

Wonderware Training


Create the Valve Template 1. Expand the Application toolset in the Template Toolbox.

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

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

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


Enable inputs: Checked (locked)

Enable outputs: Checked (locked)




6. Configure the States tab as follows:

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

Wonderware Training


7. Configure the Inputs tab as follows:

Number of Inputs: 2 (locked) Input Name: (locked) Input 2 Input Name: CLS Input 1 Input Name: OLS Input to PV Map: (locked)

0 0: Traveling0 1: Open1 0: Closed1 1: Fault




8. Configure the Outputs tab as follows:


Create the Pump Template 10. Right-click the $DiscreteDevice template in the Template Toolbox and select New / Derived

Template to create a derived template of the $DiscreteDevice object.

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

Wonderware Training


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

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







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

Wonderware Training



Number of Inputs: 1 (locked) Input Name: (locked) Input 1: Input Name: FlowSwitch Input to PV Map: (locked)








Wonderware Training


Create the Motor Template 18. Right-click the $DiscreteDevice template in the Template Toolbox and select New / Derived

Template to create a derived template of the $DiscreteDevice object.

19. Name the new template $Motor and move it to the Training template toolset.

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







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

Wonderware Training



Number of Inputs: 1 (locked) Input Name: (locked) Input 1 Input Name: AuxContact Input to PV Map: (locked)






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


Wonderware Training


Section 6 – Containment

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:

TagnamesContained NameHierarchical Name

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

Name DescriptionTagname The unique name of the individual object. For example, Valve1.Contained Name The name of the object within the context of its container object. For

example, the object whose Tagname is Valve1 may also be referred to as Tank1.Outlet, if Tank1 contains it and it has the contained name "Outlet".

Hierarchical Name Hierarchical names that are fully-qualified names of a contained object include the name of the objects that contain it.

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

For example, if:

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

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

Valve1 could be referred to as:

"Valve1"

"Tank1.Outlet"

"Reactor1.SurgeTank.Outlet".



For example, an instance of a $Tank is named Tank01. An instance of $Valve called Valve01 is contained within the instance of $Tank.

Change the contained name of Valve01 to InletValve. Now Valve01 can also be referred to by its hierarchical name Reactor1.InletValve. The name of the contained object can be changed, though, within the scope of the hierarchy.

Contained names can be up to 32 alphanumeric or special characters. The second character cannot be $ and the name must include at least one letter. You cannot use spaces.

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

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

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

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

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

Wonderware Training


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



To enable referencing and flexibility within scripting, these objects can be referenced in several different ways. Each object has a unique Tagname, such as:

Inlet Valve = InletValve01Agitator = Agitator01Outlet Valve = OutletValve01Level = Level01

Wonderware 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 Tank01, the contained names are: Tank01.InletTank01.AgitatorTank01.OutletTank01.Level

Additionally, you can use containment references in scripts such as: Me.Outlet: Allows a script running within the parent object to generically reference its child outlet instance.MyContainer.Inlet: Allows a script running in any of the children instances to reference another child instance named Inlet that belongs to the same parent.



Renaming Contained Objects Before you rename a contained name of an object, make sure that the object is not checked out to another user or currently deployed.

The new contained name must comply with naming restrictions. Template names can be up to 32 alphanumeric or special characters, including the required $ as the first character. The second character cannot be $ and the name must include at least one letter. You cannot use spaces.

Contained names also cannot be the same contained name as an existing contained object within the same level of hierarchy in the containment relationship.

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

To rename an object's contained name

1. Select the object in an Application view.

2. On the Edit menu, click Rename Contained Name.

3. Type a new contained name.

All IDEs connected to the Galaxy show the object's new contained name.

Containment and the Derivation ViewThe Derivation View does not show containment relationships. It shows templates and instances with regard to containment in the follow ways:

Non-contained instances show their tagnames.Contained instances show their tagnames and hierarchical names.Non-contained templates show their object name.Contained templates show their hierarchical name.

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

Renaming can be done on an instance's tagname and contained name. A template only has a template name.

Wonderware Training


Lab 11 – Creating the Mixer

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


Create and configure a containment relationship between objects.



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


Create the Mixer’s Valves Templates

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

Create the Mixer’s Pumps and Agitator templates

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

d. Derived a new templates from the $Motor object, name it $Agitator, and assign it to the $Mixer template.

Create the Level and Temperature Meter Templates

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

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

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

area.


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

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

Wonderware Training


tact

rt

en

en

en

itchart

itchart

h. Configure the input and output references for the contained objects as follows

where XX is your student number.

:

i. Deploy the object.

For Agitator_001AuxContact.InputSource: InControl. tagname.T1XX_AG_AuxCon

CmdStart.OutputDestination: InControl tagname.T1XX_AG_CmdSta

For Inlet1_001CLS.InputSource: InControl tagname.T1XX_IV1_CLSOLS.InputSource: InControl tagname.T1XX_IV1_OLS CmdOpen.OutputDestination: InControl tagname.T1XX_IV1_CmdOp

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

For LIT_001PV.Input.InputSource: InControl tagname.T1XX_LT_PV

For Outlet_001CLS.InputSource: InControl tagname.T1XX_OV_CLSOLS.InputSource: InControl tagname.T1XX_OV_OLSCmdOpen.OutputDestination: InControl tagname.T1XX_OV_CmdOp

For Pump1_001FlowSwitch.InputSource: InControl tagname.T1XX_TP1_FlowSwCmdStart.OutputDestination: InControl tagname.T1XX_TP1_CmdSt

For Pump2_001FlowSwitch.InputSource: InControl tagname.T1XX_TP2_FlowSwCmdStart.OutputDestination: InControl tagname.T1XX_TP2_CmdSt

For TT_001PV.Input.InputSource: InControl tagname.T1XX_TT_PV



View the Mixer Data in Runtime j. Open Object Viewer from within the ArchestrA IDE and, using the watch list created

previously, add a new watch window called Mixer and add the following attribute references:

k. Save the watch list.


Object Attribute Agitator_001 Cmd

PVInlet1_001 Cmd

PVInlet2_001 Cmd

PVLIT_001 PV

Outlet_001 Cmd

PVPump1_001 Cmd

PVPump2_001 Cmd

PVTT_001 PV

Wonderware Training


Create the Mixer Template1. Expand the Application toolset in the Template Toolbox.

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

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

Create the Mixer’s Valves Templates 4. Right-click the $Valve object in the Training template toolset and select New / Derived

Template to create a derived template of the $Valve object.

5. Name the new template $Inlet1.

6. Move $Inlet1 to the $Mixer template to contain it within the $Mixer object.

Notice the $ in $Inlet1 is automatically removed, indicating it is a template contained within another template.

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




8. Name the new template $Inlet2.

9. Move $Inlet2 to the $Mixer template to contain it within the $Mixer object.

10. Create a new derived template of the $Valve object and name it $Outlet.

11. Move $Outlet to the $Mixer template to contain it within the $Mixer object.

The Training template toolbox should now look like the following:

Create the Mixer’s Pumps and Agitator templates 12. Derive the following templates from the $Pump object, containing them within the $Mixer

object:Pump1Pump2


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

Wonderware Training



Create the Level and Temperature Meter Templates 14. Derive the following template from the $Meter object, containing it within the $Mixer object:

LIT


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





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

Wonderware Training


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

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





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

Wonderware Training


Create a Mixer Instance 22. Using the Template Toolbox and the Model view, create an instance of the $Mixer template

using the default name of Mixer_001.

23. Assign the instance to the Line1 area.



Configure the Agitator 24. Double-click the Agitator_001 instance.

The Agitator_001 configuration editor appears.

25. Select the Inputs tab.

26. Click the Browse Galaxy button after Input Source Reference.

Wonderware Training


27. From the InControl Instance, select the tagname.T1XX_AG_AuxContact attribute, where XX is your student number.

00 is used in the following examples.

28. Click OK.

29. Select the Outputs tab.

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

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

32. Click OK.



The attribute reference appears in the Output Destination Reference:


Wonderware Training


Configure Inlet1 34. Double-click the Inlet1_001 instance to open its configuration editor.

35. Select the Inputs tab and configure the Input Source Reference as follows, where XX is your student number.

Input Name Instance AttributeInput 2: CLS InControl tagname.T1XX_IV1_CLSInput 1: OLS InControl tagname.T1XX_IV1_OLS



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


Output Name Instance AttributeOutput 1: CmdOpen InControl tagname.T1XX_IV1_CmdOpen

Wonderware Training


Configure Inlet2 38. Double-click on the Inlet2_001 instance to open its configuration editor.


Input Name Instance AttributeInput 2 : CLS InControl tagname.T1XX_IV2_CLSInput 1: OLS InControl tagname.T1XX_IV2_OLS





Output Name Instance AttributeOutput 1: CmdOpen InControl tagname.T1XX_IV2_CmdOpen

Wonderware Training


Configure LIT 42. Double-click the LIT_001 instance to open its configuration editor.

43. Select the I/O tab and configure the PV input source as follows, where XX is your student number.


Instance AttributeInControl tagname.T1XX_LT_PV



Configure Outlet 45. Double-click on the Outlet_001 instance to open its configuration editor.


Input Name Instance AttributeInput 2: CLS InControl tagname.T1XX_OV_CLSInput 1: OLS InControl tagname.T1XX_OV_OLS

Wonderware Training




Output Name Instance AttributeOutput 1: CmdOpen InControl tagname.T1XX_OV_CmdOpen



Configure Pump1 49. Double-click on the Pump1_001 instance to open its configuration editor.


Input Name Instance AttributeInput 1: FlowSwitch InControl tagname.T1XX_TP1_FlowSwitch

Wonderware Training




Output Name Instance AttributeOutput 1: CmdStart InControl tagname.T1XX_TP1_CmdStart



Configure Pump2 53. Double-click on the Pump2_001 instance to open its configuration editor.


Input Name Instance AttributeInput 1: FlowSwitch InControl tagname.T1XX_TP2_FlowSwitch

Wonderware Training




Output Name Instance AttributeOutput 1: CmdStart InControl tagname.T1XX_TP2_CmdStart



Configure TT 57. Double-click on the TT_001 instance to open its configuration editor.

58. Select the I/O tab and configure the PV input source as follows, where XX is your student number.


Deploy the Object 60. Select the Deployment view, right-click the Mixer_001 instance and select Deploy.

The Deploy dialog box displays. By default the system will Cascade Deploy 9 objects in the containment relationships and set all instances On Scan as soon as the objects are deployed.

61. Leave the default settings and click OK.

Instance AttributeInControl tagname.T1XX_TT_PV

Wonderware Training


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

62. Click Close.

View the Mixer Data in Runtime 63. Right-click on the Mixer_001 instance and select View in Object Viewer. If you closed Object

Viewer before, you can use File / Load Watch List to open the file you saved earlier.


65. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to Mixer.



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

Object List Attribute ListAgitator_001 Cmd

PVInlet1_001 Cmd

PVInlet2_001 Cmd

PVLIT_001 PV

Outlet_001 Cmd

PVPump1_001 Cmd

PVPump2_001 Cmd

PVTT_001 PV

Wonderware Training



Wonderware Training

Module 4

Extending the ObjectsSection 1 – UDAs 4-3

Section 2 – Extensions 4-7

Lab 12 – Configuring the Motor Speed 4-11

Section 3 – Introduction to QuickScript .NET 4-21

Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient 4-45

Lab 14 – Configuring Automatic Reference 4-53

4-2 Module 4 – Extending the Objects

Module ObjectivesBe able to work with extending the objects and configuring them for additional functionality.

Wonderware Training

Section 1 – UDAs 4-3

Section 1 – UDAs

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 objectConfigure its data typeSpecify the attribute categorySet initial values and locks on the new attributeSet whether the new attribute is an array and how many elements comprise itSet alarms and historization for the new attribute (done on the Extensions page)Define security and references to other objects (done on the Extensions page)

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

Put to the extreme, scripts and UDAs can be used to create a completely new type of ApplicationObject starting from an empty container object that has no behavior / logic itself.

You can add UDAs to a template or an instance. When you add a UDA to a template, the UDA, its data type, and category are automatically locked in the child instances.

If UDA parameters such as initial values and security classifications are locked in the template, they cannot be changed in child instances. If these parameters are unlocked in the template, the initial value and security are editable and lockable in derived templates. When unlocked in either the base or derived template, the value is editable in instances.

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

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



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

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

Select from the data types Boolean, Integer, Float, Double, String, Time, ElapsedTime or InternationalizedString.

Allowed categories are Calculated, Calculated retentive, Object writable and User writeable. You can lock writable attributes. If you select Calculated for an attribute, only scripts running on the same object can write to the attribute.

You can create an array for each data type except InternationalizedString. Select This is an array and specify the array's length in the Number of elements box.

The Value parameter specifies the initial setting for the attribute when the object is deployed. Enter value data for each data type. In the case of a non-arrayed Boolean, select the True/False check box to use a True value. Clear the check box to use a False value. For an arrayed Boolean, select the desired element and provide a default value by typing either true or false.

Data Type Group

UDAs Name List

Inherited UDAs Name List

Wonderware Training

Section 1 – UDAs 4-5

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




Wonderware Training


tput on Group

on Group

n Group

n Group

Labeln Group

n Group

Section 2 – Extensions

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

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

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

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

Extendable Attributes list

InputOuExtensi

InputExtensi

AlarmExtensio

OutputExtensio

BooleanExtensio

HistoryExtensio



attribute's value and quality, and updates the extended attribute's value and quality every scan. Changes read from the source are not written back to the Destination attribute.Input Extension Group: Use to configure an attribute to be a reference source for another object. In other words, the extended attribute acquires the update value of the Source attribute.Output Extension Group: Use to configure an attribute to be writeable to an external object's attribute. In other words, when the value or quality (from Bad or Initializing to Good or Uncertain) of the extended attribute is modified, the value of the Destination attribute is updated.Alarm Extension Group: Use to create an alarm condition when a Boolean attribute's value is set to TRUE.History Extension Group: Use to historize the value of an attribute that does not already have history capabilities.Boolean Label Extension: Specify custom text strings for the False state and the True state. These custom text strings appear in the Active alarm state list in the Alarm extension area for you to select. If you are using the InTouch HMI, you can see these custom text strings in InTouch.

To create and associate an extension with an object

1. On the Extensions page of the object's editor, select an attribute in the Extendable Attributes List. The four extension groups dynamically change according to allowed extension rules for the selected attribute type.

2. Select the check box of the kind of extension you want to apply to the selected attribute. The associated parameters for each kind of extension are then made available.

3. For InputOutput Extension, enter a Source attribute by either typing in the reference string or clicking the attribute browser button at right. Use the Attribute Browser dialog box to search for the desired reference string in an object. Then if Destination is different from Source, click Output Destination Differs from Input Source, and enter a Destination attribute by either typing in the reference string or clicking the attribute browser button. An X is placed in the InputOutput column of the selected attribute.

Caution! If you clear the Output Destination Differs from Input Source check box, the content of the Destination box automatically becomes "---". In the run-time environment, "---" is interpreted as the same reference as the Source value entered during configuration time. In the run-time, you can change the Source reference. Therefore, during configuration, do not lock the Destination parameter if you clear the Output Destination Differs from Input Source check box.

4. For Input Extension, enter a Source attribute by either typing in the reference string or clicking the attribute browser button at right. Use the Attribute Browser dialog box to search for the desired reference string in an object. An X is placed in the Input column of the selected attribute.

5. For Output Extension, enter a Destination attribute by either typing in the reference string or clicking the attribute browser button at right. Use the Attribute Browser dialog box to search for the desired reference string in an object. Select the Output Every Scan check box if you want the extended attribute to write to the Destination attribute every scan period of the object (otherwise, the write executes only when the value is modified or when quality changes from Bad or Initializing to Good or Uncertain). An X is placed in the Output column of the selected attribute.

6. For Alarm Extension, select a Category from the list: Discrete, Value LoLo, Value Lo, Value Hi, Value HiHi, DeviationMinor, DeviationMajor, ROC Lo, ROC Hi, SPC, Process,

Wonderware Training


System, Batch or Software. Type a Priority level for the alarm (default is 500). Also, choose between Use Object Description for Alarm Message or typing in another alarm message in the Message box. An X is placed in the Alarm column of the selected attribute.

7. For History Extension, enter values for the remaining parameters: Force Storage Period, Engineering Units, Value Deadband, Trend High and Trend Low, if available (depends on the data type of the selected attribute). An X is placed in the History column of the selected attribute.

8. For Boolean Extensions,

9. Lock the value if desired. The lock symbol is available only when you are extending a template. Otherwise, it indicates the lock condition of the value in the parent object.

10. Set the security classification for the attribute if available. See "Security Icons" in "Working with Object Editors" for more information.

11. Save and close the object editor to include the new attribute extensions in the configured object.

Output Functionality The following information applies to the functionality of InputOutput and Output extensions as well as the output function of the Field Reference, Switch and Analog Device objects.

If a single set request is made to a destination attribute during a single scan cycle, that value is sent to the destination. During a single scan cycle, though, more than one set request to the same destination is possible. In that case, folding occurs and the last value is sent to the destination.

The following occurs during a single scan cycle: Only the last value requested during a scan cycle will be sent to its destination when the object executes. Its status is marked as Pending as it waits for write confirmation from the destination object. All other set requests during that scan cycle are marked as successfully completed.

If one or more new sets are requested during the next scan cycle, then the second scan cycle's value is determined in the same way as described above. It is then sent to the destination when the object executes again and the value sent to the destination during the previous scan cycle is marked with successful completion status even if write confirmation had not been received.

In other words, within a single scan cycle, data is folded and only the last set requested is sent to the destination. For instance, an {11,24,35,35,22,36,40} sequence of set requests will result in a value of 40 being sent to the destination object. All other values result in successful completion status.

The exception to the above-described functionality is for Boolean data types used in User sets (sets from InTouch or FactorySuite Gateway). This functionality accounts for an unknown user input rate (for instance, repeated button pushes) with a consistent object scan rate for outputs, and therefore creates reproducible results. In this case, a combination of folding as described above plus maintenance of a queue of one element deep in order to better meet the expectation of users. To begin with, the first value set after the object is deployed (the default True or False) is always written to its destination.

Subsequently, the following occurs during a single scan cycle: A two-tiered caching scheme of a Value to be Sent and a Next Value to be Sent is implemented. The Value to be Sent is based on data change as compared to the last value sent to the destination object. The Next Value to be Sent is based on data change as compared to the Value to be Sent value. When the first data change occurs, the new value is cached in the Value to be Sent queue. Folding occurs if the same value is requested again. If another value change occurs, this second value is cached in the Next Value to be Sent queue. Again, folding occurs if the same value is requested again.



The Value to be Sent value is sent during the next scan cycle, and the Next Value to be Sent value is sent during the following scan cycle.

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

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.

Previous Scan Cycle Value Sent

Scan Cycle Set Requests Value to be Sent Next Value to be Sent

0 1,0,0,1,1 1 none1 1,0,0,1,1 0 10 1,1,0,0 1 01 1,1,0,0 0 none

Wonderware Training


Lab 12 – Configuring the Motor Speed

IntroductionIn Lab 2, you identified that the motors, such as the agitator in the mixer, have a signal that indicates the speed of the motor when it is running, and that this speed has a setpoint associated with it to specify the desired speed for the process.

When you created the $Motor template in Lab 10 using the $DiscreteDevice, it was explained that this object does not include, by default, attributes that can be used to indicate the speed of the motor.

In this lab the $Motor template is modified by adding the attributes and functionality necessary to include the speed data (and its setpoint) as identified in Lab 2.


Add and configure UDAs to your objects Extend attributes with input and output functionality



Add and Extend the UDAs a. Add two Float UDAs to the $Motor template: one Object writeable named Speed, and

another one User writeable named SpeedSP.

b. Extend the Speed attribute with an Input extension and configure its Source as ---.---.

c. Extend the SpeedSP attribute with an InputOutput extension and configure its Source

as ---.---. Leave Output destination differs from input source unchecked and lock it.

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

View the Agitator Speed Data in Runtime e. Deploy the object and open Object Viewer from within the ArchestrA IDE.

f. Using the watch list created in Lab 5, add a new watch window named Extensions with the following attributes from the Agitator_001 instance:

PV Cmd Speed SpeedSP

g. Set the SpeedSP attribute to any valid float value to test it.

h. Save the watch list.



Extendable Attribute Instance AttributeSpeed.InputSource InControl tagname.T1XX_AG_SpeedSpeedSP.InputSource InControl tagname.T1XX_AG_SpeedSP

Wonderware Training


Add and Extend the UDAs 1. Double-click the $Motor template to open its configuration editor.

2. Select the UDAs tab.

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

4. Name the UDA Speed and press Enter.

5. Configure the Speed UDA as follows:


Data type: Float

Category: Object writeable



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

7. Select the Extensions tab.

8. Select the Speed attribute.

Data type: Float

Category: User writeable

Wonderware Training


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

Input extension: checked

Source: ---.---

Ensure the Speed Attribute is selected before configuring Input extension.



10. Select the SpeedSP attribute.

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


InputOutput extension: checked

Source: ---.---

Output destination differs from input source:

unchecked (locked)

Ensure the SpeedSP Attribute is selected before configuring Input extension.

Wonderware Training


Configure the Agitator Instance 13. Double-click on the Agitator_001 instance to open its configuration editor.



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

Instance AttributeInControl tagname.T1XX_AG_Speed

Ensure the Speed Attribute is selected before configuring Input extension.



17. Select the SpeedSP attribute

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


View the Agitator Speed Data in Runtime 20. Deploy the Agitator_001 object, using the default settings in the Deploy window.

21. Open Object Viewer by right-clicking the Agitator_001 instance and selecting View in Object Viewer. If you closed Object Viewer before, you can use File / Load Watch List to open the file you saved earlier.


Instance AttributeInControl tagname.T1XX_AG_SpeedSP

Ensure the SpeedSP Attribute is selected before configuring Input extension.

Wonderware Training


23. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to Extensions.

24. Add the following Agitator_001 attributes to the watch list: Cmd PVSpeed SpeedSP

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

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

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

27. Save the watch list.




Wonderware Training


Section 3 – Introduction to QuickScript .NET

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

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



Scripts PageThe Scripts page has six areas.

Wonderware Training


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

Script State: Select to send the state of the script to a Wonderware Historian Server historian, the ArchestrA historian. Script Editor box: Shows the script you are writing.

Script Development EnvironmentAttribute Browser

From within the Script Editor the user can leverage the Attribute-Picker tool to browse through the attribute namespace of the hosting object and other objects to pick a certain attribute to be included in the script code. The tool does not distinguish between attributes of on-engine and off-engine objects.

Script Function Browser

Like the InTouch script editor, the name of the selected script function and its calling syntax will be added to the script text when the user picks it in the script function browser. In addition to being able to insert the function call, the user can also enter a type declaration statement for object names. In addition, the browser provides the user the ability to distinguish between properties and methods.

Similar to browsing for script functions, the user can also browse for .NET / COM objects that have been imported using the ArchestrA IDE.

Syntax Validation

Script language syntax validation is performed by selecting the red check mark above the script window.

This operation will identify and inform/warn the script developer of any syntax errors in the script. A script with syntax errors can be saved. However, an object leveraging such a script cannot be deployed.



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

Startup

Called when the object is loaded into memory (deployment, platform or engine start). This script method is intended to be used to instantiate COM objects and .NET objects. Depending on load and other factors, it may be possible that sets to object attributes from this script method may fail. Attributes that reside off-object are not available to this script method. Therefore it is not recommended to use this script method for any scripting beyond its intended use.

OnScan

Called the first time an AppEngine calls this object to execute after the object scan state is changed to OnScan. This script method is intended to be used to initiate local object attribute values, or to provide more flexibility in the creation of .NET or COM objects. Attributes that are off-engine are not available to this script method. It is not recommended to use this script method for any scripting beyond its intended use.

Execute

Called every time the AppEngine performs a scan and the object is OnScan.

The execute script method is the workhorse of the scripting methods. This is the place that runtime scripting should be done to ensure that all attributes and values are available to the script. This script method in analogous to the InTouch scripts with the following conditional trigger types:

On True: Executes if the expression validates from a false on one scan to a true on the next scan.¹ On False: Executes if the expression validates from a true on one scan to a false on the next scan.¹ While True: Executes scan to scan as long as the expression validates as true at the beginning of the scan.¹,² While False: Executes scan to scan as long as the expression validates as false at the beginning of the scan. ¹,² Periodic: Executes whenever the elapsed time evaluates as true. Data Change: Executes when there is a change in data from one scan to the next.

¹ Data changes between each scan are not evaluated, only the value at the beginning of each script is used for evaluation purposes, in other words if a boolean attribute were to change from True to False to True again during 1 scan cycle, this change would not be evaluated as a data change as the value is True at the beginning of each scan cycle.

² Time-based script considerations (a trigger period of 0 means that the script execute every scan).

Wonderware Training


Time-based scripts, WhileTrue, WhileFalse, and Periodic are evaluated and executed based on the elapsed time from a timestamp generated from the previous execution, not on an elapsed time counter. Because of this it is possible that a change in the system clock can result in the interval between execution of these script to be off.

For example, a periodic script is set to run every 60 minutes. The script executes at 11:13 am, therefore we would expect it to execute 60 minutes later at 12:13 PM. However, let's assume that a time sync event has occurred and the node's time is adjusted from 11:33 am to 11:30 am. The script will still execute when the system time reaches 12:13 PM. But because of the time change the actual (True) time period that has elapsed between executions is 63 minutes.

Quality changes

When the DataChange Trigger type is selected, the Quality changes checkbox enables. Select this box to trigger the script to run when the Quality of the Expression value changes. In this configuration the script will run whether or not the Expression value changes.

Deadband

When the DataChange Trigger type is selected, Deadband specifies the amount the expression value must change before the script is executed.

OffScan

Called when the object is taken OffScan. Primarily used to clean up the object and account for any needs that should be addressed as a result of the object no longer executing.

Shutdown

Called when the object is about to be taken out of memory, usually as a result of the AppEngine stopping. Primarily used to destroy COM objects and .NET objects and clean up memory.



Attribute References

Relevant ReferencesReferences that go up the hierarchy to parent objects are called relative references.

Relative references, such as Me, are valid reference strings. A valid reference string must always contain at least a relative reference or one substring.

The following are valid relative references that refer to the current object: MeMyContainerMyPlatformMyEngineMyArea

Relative references are especially useful in templates because absolute references typically do not apply or make sense.

When you use relative references, like MyContainer, you can refer to contained objects within that container. For example, a reference to MyContainer.InletValve.PV is equivalent to Tank1.InletValve.PV in the following hierarchy:

Tank1 Cannot reference at this level because this is not contained

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

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

Specifying Attributes within a ScriptThe following sections describe how internal attributes (attributes of the object that the script is attached to) as well as external attributes (attributes of other objects) can be referenced from within a script.

References to both internal as well as external attributes have in common that typically the part specifying the property is omitted meaning that the value property is meant. In this case only the value property and the associated quality can be accessed via this attribute reference.

Specifying Internal AttributesFor internal attributes the syntax: me.+<fully qualified local part of the attributes reference> needs to be specified.

Example:If me.PV==”Open” Then{Do something}Endif;

Wonderware Training


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

First the user has to specify an alias for an external reference (for example, PVofInletValve) in the Alias Reference table (see below). Then the alias can be used directly in the script code:

If PVofInletValve==”Open” Then{Do something}

Endif;

This script can be locked in the template without locking down which attribute on what object is actually used in an instance derived from this template.

The actual mapping to an attribute is done via the Alias Reference table exposed by the script editor. The table exposes the following fields:

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 ValueSo far you mainly focused on the typical case when access to the Value property of an attribute is needed; i.e., the property part of a reference can be omitted. In the rare case when the script developer needs to access properties other than the value property, a dedicated reference is needed for every property.

Example: Let’s assume you need to read the Value property and the Dimension1 property of the external attribute Valve101.PV. Let’s further assume that you want to use inline references. The corresponding code snippet is:

A = Valve101.PV; {reads the Value property}B = Valve101.PV.Dimension1; {reads the Dimension1 property}

The two references Valve101.PV and Valve101.PV.Dimension1 are treated as two completely different references.

Note: Even though the two references Valve101.PV and Valve101.PV.Value (explicitly specifying the Value property) refer to the same property, they too are treated as two separate references. Therefore the user should avoid mixing both ways of referring to the Value property in a given script.

Alias ReferencePVofInletValve Valve101.PV… …



Accessing Array References Arrays can be accessed either by referencing an individual element of an array or by referencing the entire array. The individual element is specified by specifying the element within the square brackets as follows:

Tag.ArrayAttribute[3]

To get an entire array, either of the following syntaxes works:

Tag.ArrayAttribute[-1]

Or

Tag.ArrayAttribute

UDAs and Scripting When using UDAs in scripting, keep the following list in mind.

If you use Calculated and Calculated retentive UDAs, they must be manually initialized. For example, if you use me.UDA=me.UDA+1 as a counter in a script, you must also initialize the UDA with something like me.UDA=1 or me.UDA=<some attribute value>.Calculated UDAs can be initialized in scripts with Execution type triggers of On Scan and Execute, but not initialized in Startup scripts.Calculated retentive UDAs can be initialized nearly anywhere, however the advantage of initializing on Startup is the StartingFromCheckpoint attribute can be evaluated. For example, a Calculated retentive UDA retains the attribute’s current value after a computer restart, redundancy-related failover, or similar situation in which valid checkpoint data is present. Your Startup script should contain a statement testing the Boolean value of the StartingFromCheckpoint attribute on the object’s AppEngine. If the value is TRUE, do not initialize the UDA. If the value is FALSE, initialize the UDA.

Language DefinitionAll QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the case is preserved throughout editor sessions.

Both single line and multi-line comments are supported. Single line comments start at a ‘ in a source code line that has no matching ending ‘ in the line. Multi-line comments start with a { and end with a } and can span multiple lines as the name suggests.

Examples:Dim A; ’This is a single line commentDim B; {This is an example of a multi-line comment}

Spaces and indentation can be used as desired to improve readability, except that at least one space must appear between adjacent identifiers, and spaces and line breaks cannot appear within identifiers and numbers. Individual statements are distinguished by a semicolon that marks the end of a statement.

QuickScript.NET Operations that Require 1 OperandOperation Description~ Complement- NegationNOT Logical NOT

Wonderware Training


QuickScript.NET Precedence of OperatorsThe following list shows the order of precedence for evaluation of operators. The first operator in the list is evaluated first, the second operator is evaluated second, and so on. Operators in the same line in the list have equivalent precedence. Operators are listed from highest precedence to lowest precedence.

QuickScript.NET Operations that Require 2 OperandsOperation Description* Multiplication/ Division+ Addition and Concatenation- Subtraction= AssignmentMOD ModuloSHL Left ShiftSHR Right Shift& Bitwise AND^ Exclusive OR| Inclusive OR** Power< Less than> Greater than<= Less than or Equal to>= Greater than or Equal to== Equivalency ("is equivalent to")<> Not Equal toAND Logical ANDOR Logical OR

Precedence Operator1 (highest) (, )2 - (negation), NOT, ~3 **4 * , /, MOD5 +, -6 SHL, SHR7 <, >, <=, > =8 ==, <>9 &10 ^11 |12 =13 AND14 (lowest) OR



QuickScript.NET VariablesLocal variables or attributes can be used interchangeably within the same script. However, local variables go out of scope at the end of the script function they are used in. However, variables declared in the general section of the script exist and keep their value throughout the lifetime of the object that the script is associated with. Thus this kind of variable turns into a ‘member variable’ of the script class. Other scripts attached to the same object cannot access this variable.

Variables can be used on both the left and right hand side of statements and expressions.

Each variable must be declared within the script by a separate DIM statement followed by a semicolon The DIM statement syntax is as follows:

DIM <variable_name> [ ( <upper_bound> [, <upper_bound >[, < upper_bound >]] ) ] [ AS <data_type> ];

where

variable_name ::= <letter> { <letter> | <digit> | <special_character> }letter ::= A-Z | a-zdigit ::= 0-9special_character ::= _upper_bound ::= 1-2,147,483,647data_type ::= Boolean | Discrete | Integer | Float | Real | Double | String | Message | Time | Object

The variable name is limited to 255 Unicode characters. Note that, in contrast to attribute names, variable names must not contain dots. Variable names and the data type identifiers are not case sensitive. If there is a naming conflict between a declared variable and another named entity in the script (attribute name, alias, name of an object leveraged by the script), the variable name takes precedence over the other named entities.

For example, let’s assume that your script accesses the hosting object’s PV attribute in the script text and you declare ‘DIM PV AS Integer;’. Within the declaring script, expressions using ‘PV’ in a statement will refer to the value associated with the local variable ‘PV’ rather than the attribute ‘PV’.

Note: The naming convention for QuickScript.NET variables is more restrictive than in QuickScript. In QuickScript additional special characters are allowed:QuickScript_special_character :- _!@-?#$%\&

In contrast to QuickScript arrays with up to three dimensions are supported. Only the upper bound of each dimension can be specified and is fixed after the declaration; i.e., a statement analogous to VB’s ReDim statement is not supported. The lower index of each array dimension is always 1.

Wonderware Training


The data type declaration (AS <data_type>) is optional. If omitted, the data type of the variable is Integer (as in QuickScript).

Indirect DatatypeThe Indirect keyword supports dynamically binding a variable to an arbitrary reference string for get/set usage.

The syntax for this keyword, including the use of the method, BindTo(s), is

show in the example below:dim x as indirect;...x.BindTo(s); ' where s is any expression that returns a stringx = 1234;if WriteStatus(x) == MxStatusOk then' ... do somethingendif;

QuickScript.NET Control Structures QuickScript.NET provides four primary control structures in the scripting environment:

IF ... THEN ... ELSEIF ... ELSE ... ENDIFFOR ... TO ... STEP ... NEXT LoopFOR EACH ... IN ... NEXTWHILE Loop

Data Type (as specified inAS <data_type>)

Default Value Comment

Boolean, Discrete False Discrete and Boolean are synonymous. Discrete is still supported for migration from InTouch.True=1, False=0

Integer 0 Signed–2147483648 to 2147483647

Float, Real NaN Float and Real are synonymous. Real is still supported for migration from InTouch.For range information please refer to Appendix

Double NaN For range information please refer to Appendix String, Message “”

(empty string)

Maximum length defined by BSTR (2147483647)

Time 0 Resolution is 100 nanoseconds, used to reflect an absolute date / time the content reflects the number of 100-nanosecond intervals since 00:00 January 1, 0001.

ElapsedTime 0 100 nanosecond ticks represents a time span.Object Nothing Leveraged for accessing OLE Automation servers.



IF … THEN … ELSEIF … ELSE … ENDIFThe 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;

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

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 ThenMessage = ”Value is zero”;

ElseIf value > 0 ThenMessage = ”Value is positive”;

ElseIf value < 0 then

Data Type MappingBoolean, Discrete Directly used (no mapping needed)Integer Value = 0 evaluated as False

Value != 0 evaluated as TrueFloat, Real Value = 0 evaluated as False

Value != 0 evaluated as TrueDouble Value = 0 evaluated as False

Value != 0 evaluated as TrueString, Message Cannot be mapped. Using an expression

that results in a string type as the boolean_expression results in a script validation error.

Time Cannot be mapped. Using an expression that results in a time type as the boolean_expression results in a script validation error.

Object Cannot be mapped. Using an expression that results in an object type as the boolean_expression results in a script validation error.

Wonderware Training


Message = ”Value is negative”;

Else{Default. Should never occur in this example}

EndIf

FOR … TO … STEP … NEXT Loop A FOR-NEXT loop is used to perform a function (or set of functions) within a script several times during a single execution of a script. The general format of the FOR-NEXT loop is as follows:

FOR <analog_var> = <start_expression> TO <end_expression> [STEP<change_expression>]

[statements]

[EXIT FOR;]

[statements]

NEXT;

Where:analog_var is a variable of type Integer, Float, Real, or Double.start_expression is a valid expression, to initialize analog_var to a value for execution of the loop.end_expression is a valid expression. If analog_var is greater than end_expression, execution of the script jumps to the statement immediately following the NEXT statement.(This holds true if loop is incrementing up, otherwise, if loop is decrementing, loop termination will occur if analog_var is less than end_expression.)change_expression is an expression, to define the increment or decrement value of analog_var after execution of the NEXT statement. The change_expression can be either positive or negative. If change_expression is positive, start_expression must be less than or equal to end_expression or the statements in the loop will not execute. If change_expression is negative, start_expression must be greater than or equal to end_expression for the body of the loop to be executed. If STEP is not set, then change_expression defaults to 1.

It is possible to exit the loop from within the body of the loop via the EXIT FOR statement.

The FOR loop is executed as follows:

1. analog_var is set equal to start_expression.

2. The system tests to see if analog_var is greater than end_expression. If so, the loop exits. (If change_expression is negative, the system tests to see if analog_var is less than end_expression.)

3. The statements in the body of the loop are executed. Here the loop can potentially be exited via the EXIT FOR statement.

4. analog_var is incremented by 1 - or by change_expression if it is specified.

5. Steps 2 through 4 are repeated.

Note: FOR-NEXT loops may be nested. The number of levels of nesting possible depends on the memory and resource availability.



FOR EACH … IN … NEXTThe FOR EACH loop can only be used with collections exposed by .NET objects and OLE Automation servers .A FOR-NEXT loop is used to perform a function (or set of functions) within a script several times during a single execution of a script. The general format of the FOR-NEXT loop is as follows:

FOR EACH <object_variable> IN <collection_object >

[statements]

[EXIT FOR;]

[statements]

NEXT;

Where:object_variable is a variable of type <some COM interface>collection_object is a variable holding a collection object.

As in the case of the FOR … TO loop it is again possible to exit the execution of the loop via the statement ‘EXIT FOR;’ from within the loop.

Note: Collections are frequently leveraged by VB and VBA / JScript. Microsoft’s office suite is built around the concept of collections. Furthermore Microsoft® started to expose more and more of the Windows® system via collections.

Example:Dim fso As IFileSystem;Dim folder As IFolder;Dim fileCollection As IFileCollection;Dim file As IFile;Dim fileName as String;

fso = new FileSystemObject;folder = fso.GetFolder(“C:\Temp”);fileCollection = folder.Files;For Each file In fileCollection fileName = file.name; Next;

FOR EACH will allow for looping through arrays.

Wonderware Training


WHILE LoopA WHILE loop is used to perform a function (or set of functions) within a script several times during a single execution of a script while a condition is true. The general format of the WHILE loop is as follows:

WHILE <boolean_expression>

[statements]

[EXIT WHILE;]

[statements]

ENDWHILE;

Where:boolean_expression is an expression that can be evaluated as a Boolean as defined above in the description of IF…THEN statements.

It is possible to exit the loop from within the body of the loop via the EXIT WHILE statement.

The WHILE loop is executed as follows:

1. The system tests to see if boolean_expression is true. If not, the loop exists.

2. The statements in the body of the loop are executed. Here the loop can potentially be exited via the EXIT WHILE statement.

3. Steps 1 through 2 are repeated.

Note: WHILE loops may be nested. The number of levels of nesting possible depends on the memory and resource availability.

Script Execution Error HandlingWhen the script execution engine experiences a script execution error the script’s current execution scan is aborted. Script execution will be reattempted on the next engine scan after the script has encountered an execution error. The script properties will indicate the cause of the error in a dedicated attribute and enter an active alarm state (‘Script Error’ alarm). The alarm condition will remain until the script subsequently completes a successful execution cycle.

Notes: When a script execution abort occurs, the script just stops. Sometimes it might be necessary to set the quality of some UDAs that are controlled by the aborted script to bad. The user can accomplish this by exercising a second script that monitors the abortion of the first script.Failed writes constitute a normal behavior that does not constitute an alarm.

Example: A script constantly tunes the parameters of a PID loop which is typically in control mode. However, every time when a shift changes, the PID object is set to manual mode for a short period of time. Now the writes fail but the script just keeps going and eventually a script run will again successfully be able to set the PID parameters.

Of course it is also possible to check the WriteStatus from within the script and react accordingly.



Alarm Type Errors

Watchdog Timeout ErrorTo prevent the possibility that a script can cause an overrun of the ApplicationEngine scan cycle (for example, by running in an infinite loop), a script is aborted after the timeout period for the script has elapsed. The script execution infrastructure will clean up after the aborted script as best as possible. For example, the script infrastructure must attempt to release external objects or data base connections that were created by the script. However, it can never be guaranteed that an aborted script has no negative side effects. For example, the script could have started to manipulate data base entries and could leave some table entries in an inconsistent state.

All synchronous mode scripts will be subject to the same timeout period, which is exposed as an attribute on the AppEngine.

The script developer will be required to configure the timeout period for each Asynchronous mode script in order to provide flexibility in accommodating the potentially time consuming operations that these scripts are intended for.

Overflow Error A script experiences an overflow condition. Overflow conditions not only apply to analog data types (integer float) but also other data types (for example, string length overflow).

Division by ZeroThe division by zero error is raised only for integer operations. In the case of float values the scripting is able to deal with + ∞ and - ∞ and also NaN (Not a Number).

Net Call Execution Errors If a script encounters an exception during call of a .NET function call, the error will be caught and an error message (in red) will be logged to the logger. In addition, the execution alarm Boolean condition is raised in this case.

Pre-Installed Binary LibrariesAs part of the scripting environment a single binary library is shipped. This library provides functionality to support both generic scripting tasks and tasks requiring access to specialized portions of Application Server

Math functions: Includes functions like Abs, Sin, Sqrt, etc.String functions: StringLen, etc.System functions: LogMessage, etc.

Importing Additional Binary LibrariesScript Library Packages can be added to the system and made available to the user like pre-installed script libraries.

Note: Script libraries developed with the InTouch 32-bit Extensibility toolkit can be imported and converted to Script function Libraries.

Wonderware Training


Exporting Binary LibrariesOnce imported, script functions exposed in the imported libraries can be used in any scripts. When objects using those scripts are exported from the Galaxy (say Galaxy A) and imported into another Galaxy (Galaxy B) the libraries once imported into Galaxy A are not automatically exported with the object. I.e., in order to run the exported object in Galaxy B, the script libraries that the object depends upon need to be manually copied to Galaxy B.

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

Only referenced attributes expose quality. Local variables do not have a quality assigned. I.e., when assigning the value of an attribute to a local variable the quality information is lost.

Example: The following code snippet assumes that A and B are local variables of appropriate data type.

A = Valve101.PV{The value of A is now the value of Valve101.PV.Value. The actual name of the Value property is spelled out for clarity purposes. The variable A just holds the value, not the quality.}B = Valve101.PV.Quality{Another variable can be used to hold the quality information but no local variable is able to hold the value and the quality information.}

Quality Handling in Script Expressions Script expressions are ‘one liners’ and as such it does not make sense to only execute the part of an expression that deals with attributes of acceptable quality. I.e., the expression is either evaluated as a whole or not at all.

If any of the input variables to the expression change to an initializing or bad quality state, the result value reported will have a quality of initializing or bad (if there exists at least one input with initializing and another input with bad quality, bad will have precedence over initializing quality and be reported as the expression result’s quality). The result value itself is set to the default value for the given data type (for example, a result value of type float is set to NaN – not a number) when the quality turns unacceptable.

If the script expression is used as the trigger for the execution of a script and the quality of at least one referenced attribute is unacceptable (i.e., initializing or bad), then the script is not triggered at all.

Data Quality Propagation (DQP)DQP seeks to streamline the script development task when writing scripts that robustly handle data quality. One of the main differences between DQCE and DQP is that in the latter case the execution of the script still happens even though some of the referenced attributes might expose unacceptable quality. In typical cases portions of a given complex script are not affected by the bad quality of a given attribute and therefore will be executed. As a result the script developer needs the ability to evaluate the quality of attributes within the script and to react accordingly (for example, by branching into a code segment that causes the system to go into a fail safe mode.)



When using the Application Server scripting language, the script developer should understand the following rules and behavior: data time handling / propagation.

Script Functions do not Leverage Quality InformationFor Script Functions the in and out parameters as well as a potential return value have no associated quality information. For example, a Script Function for calculating the square root of a float value might have a signature like this:

float Sqrt(float InValue)

If an attribute reference is passed in as the InValue then the quality information is stripped off and only the value of the referenced property (typically the Value property) is passed in.

Note: A function is invoked independent of whether the quality of the referenced attribute is acceptable or not. It is the responsibility of the script developer to ensure that the method is invoked appropriately.

Quality Check From Within a ScriptThe script developer has the ability to control the execution of script blocks by evaluating the quality of a set of leveraged attributes. It is possible to either test each attribute’s quality individually

If (Valve101.PV.Quality == 192) OrValve101.PV.Quality == 0) Then …

Or to use the quality check functions as follows:If IsGood(Valve101.PV) Or

IsBad(Valve101.PV)) Then …

Positive Script LogicScript languages adhering to DQP encourage users to apply positive logic in the script. I.e., any expression that is used in a control statement (examples are: IF, REPEAT, WHILE) to produce a Boolean result will equate to a false value if the expression leverages at least one attribute that has bad or initializing quality. I.e., condition statements are automatically evaluated as False if at least one attribute with unacceptable quality is used in the condition statement. Example: If (Valve101.PV == “Closed”) And

(Valve102.PV == “Closed”) ThenSet Valve103.Cmd = “Open”

ElseSet Valve103.Cmd = “Close”{This should be the fail safe mode}

Endif;

If the quality of Valve101.PV and Valve102.PV is acceptable then the ‘if’ and ‘else’ branches are executed purely based on the value of those two attributes.

However, if at least one of the PV values has an unacceptable quality (bad or initializing) then automatically the ‘else’ branch is executed. I.e., if statements should be written in a way that the else branch always constitutes the fail safe mode.

Adhering to this standard allows script writers to take quality into account without ever explicitly evaluating the quality of referenced attributes.

Wonderware Training


Condition statements are the only instance where a DQP enabled script language takes quality implicitly into account. In all other cases the script execution system ignores the quality if the script developer does not choose to test the quality explicitly. This also means that the assignment

PID1.SP = PID2.SP

is executed independent of whether the quality associated with PID2.SP is Bad or Initializing. That might be surprising at first. However, it leads to a more consistent behavior of the script environment. Consider the following very similar script lines:

PID1.SP = PID2.SP + 10PID3.SP = Sqrt(Tank101.Level)PID4.SP = PID2.SP + A

{A is a local variable}

As soon as the right side is not just a single attribute reference but involves additional statements, the script execution system has to ignore the quality. From a user’s perspective it is easier if all the listed cases are treated equally; i.e., the quality is ignored in all cases.

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

Execution ModeExecute 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 ExecutionThe 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 ExecutionThe asynchronous mode is used for the class of scripts that perform operations that don’t meet the above speed and determinism criteria. These scripts will be executed on a worker pool of separate, lower priority threads than the Application Engine’s primary thread. No support will be provided to establish prioritization of execution among Asynchronous mode scripts; they will all receive the same priority.

An asynchronous script running in a separate thread can access ArchestrA™ attributes via normal get/set calls. The call is marshaled over to the main engine thread and processed. The calling thread waits for call return until main thread can process get/set request. This is OK since asynchronous thread is usually slower and background in nature.

Only script code written for the Execute type of an object can be declared asynchronous.

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



Specification of execution order for asynchronous scripts within an object is allowed. However, this ordering just impacts condition evaluation, not execution ordering since asynchronous scripts are run in separate threads from each other.

Asynchronous Script Threads Threads are used for processing asynchronous scripts simultaneously when they are due and their trigger condition is true. Only one script can execute on one thread at a time. If an asynchronous script comes due and no worker thread is available, it is immediately queued for execution and awaits a free worker thread. As soon as the worker thread is free from its previous script, it executes the newly queue script.

A default number of worker threads is to be provided. This is a configurable attribute of the Engine.

Asynchronous Scripts Diagnostics and Attributes Asynchronous scripts require some additional attributes within the script to provide the following behavior:

Kill attribute - terminates the asynchronous script when written to. Shutdown attribute – simply a Boolean flag that requests the asynchronous script to shut down on its own. A well-written script will check this command before and after time-consuming operations. Running indicator attribute – indicates whether the asynchronous script is currently executing. Elapsed time attribute – indicates the amount of time the asynchronous script has been executing (if RunningFlag is true).Asynchronous scripts also have the following diagnostic attribute within the engine:Count of asynchronous scripts running – indicates the number of asynchronous scripts currently executing.Count of asynchronous scripts waiting – indicates the number of asynchronous scripts currently queued to execute.

Script Timeout The execution time of both synchronous as well as asynchronous mode scripts is monitored against a timeout period. All synchronous scripts on an AppEngine share the same timeout period which is exposed as a configurable attribute of the AppEngine.

In the case of asynchronous scripts a timeout period that is shared for all asynchronous scripts does not make sense since the needed execution time can vary by orders of magnitude between different asynchronous scripts. In order to account for this, the timeout period can be separately configured for each asynchronous script. It is exposed as an attribute of the script.

Wonderware Training


Support for .NET ConstructsQuickScript .NET is built on top of .NET and supports the following .NET constructions in its syntax:

Declaring variables of .NET types.Calling public constructors (with and without parameters) of .NET types.Calling public instance methods (with and without parameters) of .NET types.Calling public static methods (with and without parameters) of .NET types.Calling public indexers (with one or more parameters) of .NET types.Using .NET enumerations.

OLE Automation SupportOver the last couple of years Microsoft used many different terms when talking about OLE Automation. In order to reduce confusion the following part attempts to establish the terms used throughout this document:

Support for COM Servers:Support for Get/Set PropertySupport for method invocation on COM server

Creating objects outside of the context of scripts does not work. In many cases an object can only be created in a programmatic manner based on another already created object.VBS example:

Dim xlAppDim xlBookDim xlSheet' Assign object references to the variables. Use' Add methods to create new workbook and worksheet' objects. Note that xlBook and xlSheet can only be' created after the objects xlApp and xlBook got ' created.Set xlApp = WScript.CreateObject("Excel.Application")Set xlBook = xlApp.Workbooks.AddSet 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 ScriptScripts can create COM servers using one of two techniques. The “New” technique is the preferred technique since it allows early-binding of methods which offers the advantage of early validation of method calling syntax and better runtime performance.

1. New keyword – this keyword instructs the script to create a new .NET object. ActiveX components that have been imported into the Galaxy Repository explicitly end up with .NET wrappers that allow them to be created using this technique. In the example below, early-bound methods on

Dim app as Excel.Application;

App = new Excel.Application;



2. CreateObject method – this method instructs the script to specifically create a named COM object that is installed on the system upon which the script is to be deployed. These are late-bound objects. Late-bound methods on app can be called after the object is created.

dim app as object;

app = CreateObject(“Excel.Application”);

Script ExamplesThe following script examples may be used for reference.

Note: Many additional script examples may be located in the ArchestrA IDE Help files under Enhancing an Object’s Functionality/QuickScript .NET Scripting Language/Sample Scripts.

Load an XML Document from Disk and Do Look-ups on Itdim doc as System.Xml.XmlDocument; dim node as System.Xml.XmlNode; doc = new System.Xml.XmlDocument; doc.Load("c:\catalog.xml"); ' find the title of the book whose isbn is 044023722X node = doc.SelectSingleNode("/catalog/book[@isbn='044023722X']/title"); LogMessage(node.InnerText); ' find all titles written by Grisham for each node in doc.SelectNodes("/catalog/book[author/lastName='Grisham']/title") LogMessage(node.InnerText); next;

Query a SQL Server Databasedim connection as System.Data.SqlClient.SqlConnection; dim command as System.Data.SqlClient.SqlCommand; dim reader as System.Data.SqlClient.SqlDataReader; connection = new System.Data.SqlClient.SqlConnection("server=(local);uid=sa;database=northwind"); connection.Open(); command = new System.Data.SqlClient.SqlCommand("select * from customers", connection); reader = command.ExecuteReader(); while reader.Read() LogMessage(reader("CompanyName")); endwhile; reader.Close(); connection.Close();

Create a Look-up Table, Then Do a Look-up on It dim zipcodes as System.Collections.Hashtable; zipcodes = new System.Collections.Hashtable; zipcodes["Irvine"] = 92618; zipcodes["Mission Viejo"] = 92692; LogMessage(zipcodes["Irvine"]);

Wonderware Training


Use DDE to Access an Excel Spreadsheet WWPoke("excel", "sheet1", "r1c1", "Hello"); WRequest("excel", "sheet1", "r1c1", me.Greeting); ' Note: use "" to embed double quotes in strings

WWExecute("excel", "sheet1", "[SELECT(""R1C1"")][FONT.PROPERTIES(,""Bold"")]");




Wonderware Training


Lab 13 – Adding Auto Reconnect to DDESuiteLinkClient

IntroductionThe $DDESuiteLinkClient object lacks the capability to automatically reconnect to the data source if the connection is lost, therefore in this lab you will extend the object with UDAs and scripts to add reconnection functionality.

You will also add additional diagnostic information to the $DDESuiteLinkClient object through a UDA/script combination that will indicate the number of disconnects the object has experienced since it last went on scan.

Note: Your instructor will demonstrate the script’s resulting functionality.


Use the QuickScript.NET scripting engine to extend your objects with extra functionality Use attributes, including UDAs, within scripts Create scripts with different execution types Reconnect whenever the InControl object gets disconnected



Add the auto-reconnect functionality a. Add a script called Reconnect (locked) to the $tDDESuiteLinkClient with an Execute

execution type configured as follows:

b. Add a Calculated Integer UDA named DisconnectCnt.

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

Expression: Me.ConnectionStatus <> 2

Trigger type: OnTrue

Script body: Me.DisconnectCnt = Me.DisconnectCnt + 1;

and an OnScan execution type configured as follows:

Script body: Me.DisconnectCnt = 0;

d. Deploy the InControl object




Trigger type: WhileTrue

Trigger period: 00:00:05.0000000

Script body:Me.Reconnect = True;

Wonderware Training


Add the Auto-reconnect Functionality 1. Double-click the $tDDESuiteLinkClient template to open its configuration editor.




2. Select the Scripts tab.

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

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

Aliases section: (locked)

Declarations section: (locked)

Scripts section:

Execution type: Execute (locked)

Basics section: (locked)


Trigger type: WhileTrue

Trigger period: 00:00:05.0000000

Script body section: Me.Reconnect = True;

Wonderware Training



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

Data type: Integer

Category: Calculated

The DisconnectCnt attribute is a counter that will keep track of how many times the object disconnects. This attribute value will be updated via a script, defined next.




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

This script monitors the connection status of the object. Every time it changes from a 'Connected' status to a non-connected status ('Disconnected' or 'Mixed'), it increments the count (DisconnectCnt attribute).



Scripts section:

Execution type: Execute (locked)

Basics section: (locked)


Trigger type: OnTrue

Script body section: Me.DisconnectCnt = Me.DisconnectCnt + 1;

Wonderware Training


8. Select the DisconnectMonitor script

9. Select an Execution type of OnScan to add a second section to the script.

10. Configure the script as follows:

Script body section: Me.DisconnectCnt = 0;

This script will initialize (set to zero) the DisconnectCnt attribute when the object goes on scan.


12. Deploy the InControl instance, accepting the defaults in the Deploy dialog box.

Note: Your instructor will demonstrate how the completed lab steps have changed the behavior of the deployed object.




Wonderware Training


Lab 14 – Configuring Automatic Reference

IntroductionThis lab illustrates how to add to the mixer objects the capability of automatically configuring the input and output references within the objects based on the naming conventions established for your galaxy.

To successfully provide this functionality, a compromise regarding the naming of the objects has to be arranged. In this example, it is required that every instance derived from the $Mixer template is named with the valid three-digit mixer identification number at the end as identified in Lab 2.


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



Add the auto-configuration functionality a. Add a script to the $Mixer template called AssignIO (locked) with an OnScan execution type.

b. In the AssignIO script body, add the Lab 14 - Configuring Automatic Reference.txt script located in the Wonderware Training folder.

c. Lock the Aliases and Declarations sections.

Modify the Mixer instance, create and deploy a new Mixer instance d. Undeploy the Mixer_001 instance and change its name to Mixer_1XX.

e. Create a new instance of the $Mixer template named Mixer_2XX and assign it to the Line2 area.

f. Deploy both instances of the mixer.

g. Using the watch list created in Lab 5, verify configuration of Mixer 1and its contained Objects using the Mixer tab in Object Viewer.

h. Rename the Mixer tab in Object Viewer, naming it Mixer 1.

i. Add a new watch window named Mixer 2 with the following attributes to verify configuration of Mixer 2 and its contained Objects.




PVInlet1_002 Cmd

PVInlet2_002 Cmd

PVLIT_002 PV

Outlet_002 Cmd

PVPump1_002 Cmd

PVPump2_002 Cmd

PVTT_002 PV

Wonderware Training


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

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

'Get the common part for the references. Dim dataSource As String; dataSource = "InControl.tagname.T" + StringRight(Me.Tagname, 3);

'Configure inlet valve 1. Me.Inlet1.CLS.InputSource = dataSource + "_IV1_CLS"; Me.Inlet1.OLS.InputSource = dataSource + "_IV1_OLS"; Me.Inlet1.CmdOpen.OutputDest = dataSource + "_IV1_CmdOpen";

'Configure inlet valve 2. Me.Inlet2.CLS.InputSource = dataSource + "_IV2_CLS"; Me.Inlet2.OLS.InputSource = dataSource + "_IV2_OLS"; Me.Inlet2.CmdOpen.OutputDest = dataSource + "_IV2_CmdOpen";

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

'Configure transfer pump 1.Me.Pump1.FlowSwitch.InputSource = dataSource + "_TP1_FlowSwitch"; Me.Pump1.CmdStart.OutputDest = dataSource + "_TP1_CmdStart";

'Configure transfer pump 2. Me.Pump2.FlowSwitch.InputSource = dataSource + "_TP2_FlowSwitch"; Me.Pump2.CmdStart.OutputDest = dataSource + "_TP2_CmdStart";

'Configure level meter. Me.LIT.PV.Input.InputSource = dataSource + "_LT_PV";

'Configure temperature transmitter. Me.TT.PV.Input.InputSource = dataSource + "_TT_PV";

'Configure agitator. Me.Agitator.AuxContact.InputSource = dataSource + "_AG_AuxContact"; Me.Agitator.CmdStart.OutputDest = dataSource + "_AG_CmdStart"; Me.Agitator.Speed.InputSource = dataSource + "_AG_Speed"; Me.Agitator.SpeedSP.InputSource = dataSource + "_AG_SpeedSP";




Scripts section:

Execution type: OnScan (locked)

Script body section: Lab 14 - Configuring Automatic Reference.txt script located in the Wonderware Training folder.




Modify the Mixer instance, create and deploy a Mixer instance 4. Right-click Mixer_001 and select Undeploy.

5. Click OK to confirm the Undeploy, retaining the default selections in the Undeploy dialog box.

Wonderware Training


6. Click Close when the Undeploy complete message displays.

7. Right-click Mixer_001 and select Rename.

8. Rename Mixer_001 to Mixer_1XX, where XX is your student number.

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

9. Click the Yes button.

10. Right-click the $Mixer template and choose New / Instance to create a new instance of the $Mixer template.

11. Rename the new instance Mixer_2XX, where XX is your student number.

12. Click Yes when the warning displays.



13. Assign Mixer_2XX to the Line2 area.

14. Click the button to expand the Mixer_2XX instance.

The new instance of the Mixer_2XX displays a warning icon on all contained objects. Your instructor will address this after the lab.

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

Important! If there is a warning icon on the Mixer_2XX instance itself, notify your instructor.

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

16. Click Close when deployment is complete.

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

Warning icons are OK!

Wonderware Training



Verify configuration of Mixers and their contained Objects19. Right-click on Mixer_1XX and select View in Object Viewer. If you closed Object Viewer

before, you can use File / Load Watch List to open the file you saved earlier.

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

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


23. Right-click in the new Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to Mixer 2.



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



PVInlet1_002 Cmd

PVInlet2_002 Cmd

PVLIT_002 PV

Outlet_002 Cmd

PVPump1_002 Cmd

PVPump2_002 Cmd

PVTT_002 PV

Wonderware Training

Module 5

Alarms and HistorySection 1 – Alarms 5-3

Lab 15 – Configuring Alarms 5-15

Section 2 – Historization 5-33

Lab 16 – Configuring History 5-39

5-2 Module 5 – Alarms and History

Module ObjectiveObtain an overview and understanding of the concepts of Alarms, Events and Historization and how ArchestrA handles each.

Wonderware Training

Section 1 – Alarms 5-3

Section 1 – Alarms

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

What is an Alarm/EventThe alarm and event capabilities in the system provide for users to automate the detection, notification, historization and viewing of either application (process) alarms and events or system/software alarms events. Alarms and events are things that occur in the runtime system. Events and alarms are different and the system distinguishes between the two. An event is simply an occurrence of a condition at a certain point in time. The system can detect events, store them historically and report them to various clients. Alarms, on the other hand, represent the occurrence of a condition that is considered abnormal (generally bad) in nature and requiring immediate attention from a user. Alarms are a special type of event that indicate something abnormal has happened. The system handles the real-time reporting of alarms in a special manner and provides special clients for their viewing.

Examples of alarms include:A process measurement has exceeded a predefined limit, such as a high temperature alarm.A process device is not in the desired state, such as a pump that should be running has stopped.The system hardware is not operating within desired limits, for example the CPU utilization on a Platform exceeds a certain percentage for an extended time.

Examples of events include:A plant process has started; for example, a new batch or campaign starts.The operator has changed a plant operator parameter; for example, a setpoint on a temperature controller.The system engineer has changed the runtime system configuration; for example, deployment of a new AutomationObject.The system engineer has started or stopped a system component; for example, stopping an engine.A platform has come back online after it had a failure or shutdown.A user has logged into the system.Detection of a severe software problem; such as a failed Application Object component.

The following items are not considered alarms or events:Configuration actions within the Galaxy Repository; for example import or check-out.Installation of Bootstrap on a PC.A message sent to the system logger (SMCLogger). Note, sometimes certain software events may log a message in addition to generating an event, but this is ancillary. Logger messages are not events.Viewing a window in the View Engine.

Section ObjectivesFamiliarize you with the concept of alarms and events, and Enable you to understand how ArchestrA handles alarms and events.



How does ArchestrA handle alarms?

The Platform as an Alarm ProviderA Platform can act as a single Alarm Provider that provides alarms to the InTouch Distributed Alarm subsystem. A boolean checkbox is provided in the Platform AutomationObject indicating whether it subscribed to Areas or not for alarm and event reporting. The Platform, when deployed, only initiates subscription to those Areas that are only deployed to that Platform.

The platform is responsible for routing all alarms and events for all Areas subscribed to by that Platform to InTouch’s distributed alarming infrastructure. The Platform acts as a router between all Alarm/Event Notification Distributors that are running in the subscribed Areas throughout the Galaxy (inside every Area, Platform, Engine, DI Device, etc.) and the distributed alarming infrastructure. The Platform also routes alarm acknowledgements, enables and disables received from distributed alarming back to the appropriate AutomationObject. Alarm acknowledgements, enables, and disables carry along the User information for security purposes. An alarm generated by Application Server contains fields that are generated by the alarm functions inside the AutomationObject. Those fields are mapped to fields in InTouch as follows:

InTouch as an Alarm ConsumerThe 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

Alarms:ArchestrA field InTouch Dist Alarms MappingType = alarm state change N/aTimestamp of alarm event TimeTagname NameCommon message text string. CommentArea Alarm groupCommon name for alarm primitive (for example “PV.HiAlarm”)

Alarm Type (string)

New alarm state (ack, rtn, etc.) StatePriority = 1-999 Priority Value (mxValue) ValueLimit (mxValue) LimitValue MxReference N/aLimit MxReference N/aUnits MxReference N/aCategory ClassCategory SubClass

Wonderware Training


AutomationObject’s acknowledge attribute for the alarm. Security is used as part of this set (it is a UserSetAttribute). An optional comment can be entered when the acknowledge is requested.

An acknowledge of an alarm is reported as an alarm state change back to the distributed alarming. The optional operator comment is included in the event message sent back.

Distributed Alarming has no support for passing a rejected acknowledge failure feedback. Therefore, if an acknowledge is requested from a client but does not succeed, the only feedback on the InTouch client will be no change in acknowledge status on the client.

Alarm Enable/DisableThe InTouch Alarm Client can enable/disable alarming on any AutomationObject. The platform receives the enable request and forwards it to the target AutomationObject’s AlarmMode attribute. Security is used as part of this set (it is a UserSetAttribute).

How does ArchestrA handle Events?A Platform is an Event Provider that provides events to the InTouch Distributed Alarm subsystem. This provider routes all events that are generated by AutomationObjects hosted by that Platform to Application Server. The provider does not need to deal with subscriptions to Areas. The provider acts as a router between the NotificationDistributor (inside every Area, Platform, Engine, etc) and the InTouch Distributed Alarm subsystem.

Several types of events can be generated by AutomationObjects The following tables define how the fields in those events are mapped to fields in the Distributed Alarm subsystem.

System Events:

ArchestrA field Distributed Alarm subsystem Mapping

Type (or Category) = System Type = SYSTimestamp TimeTagname NameTag description CommentArea Alarm groupSystem event description (“started”, “stopped”)

Event Type – if string, or use Comment field

N/a State = none (preferred) or “UNACK_RTN”

N/a Priority = 1N/A Provider = GalaxyN/A Event Class = EVENT

Security Audit (includes User Data Change) Events:


Type = Operator Change Type = OPRTimestamp TimeTag.primitive.attribute NameTag description CommentArea Alarm groupView engine name



Operator 1 name RequestingEngineName + Operator name

Operator 2 name N/aOld value LimitNew value valueN/a State = none (preferred) or

“UNACK_RTN”N/a Priority = 999N/A Provider = GalaxyN/A Event Class = EVENT

Application Data Change Events:


Type = Data Change Type = LGCTimestamp TimeTag.primitive.attribute Name? Or name+comment?Tag description CommentArea Alarm groupView engine name Platform (the PC’s node name)Old value LimitNew value ValueN/a State = none (preferred) or

“UNACK_RTN”N/a Priority = 999N/A Provider = Galaxy

Security Audit (includes User Data Change) Events: (continued)


Wonderware Training


Alarm QueriesAlarm queries are used within alarm clients to retrieve real-time alarm information and event reports from the Galaxy.

The fully-qualified syntax of an alarm query to retrieve a single alarm within an object as reported by a specific WinPlatform object is:

\\nodename\Galaxy!area!object.attribute

If the WinPlatform object that serves as an alarm provider is located in the local computer, the following syntax of the alarm query is allowed:

\Galaxy!area!object.attribute

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

Use of Wildcard

The asterisk (*) is a wildcard character that may be used to substitute any character or characters in the object.attribute part of the alarm query.

The following table lists different examples on the use of the wildcard character on alarm queries and their return data:

Only one wildcard character is allowed per alarm query.

Using Multiple Queries

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

\Galaxy!Area1 \Galaxy!Area2

By using multiple queries it is possible to retrieve alarms from different nodes (WinPlatform objects) at the same time, for example:

\\NodeNameA\Galaxy!Area1 \\NodeNameB\Galaxy!Area2

Alarm Query Results\\nodename\Galaxy!area All alarms and events from the area object itself.

All alarms and events from all the objects hosted in the area.

All alarms and events from all subareas contained in the area as configured in the Model View of the ArchestrA IDE.

All alarms and events from all the objects hosted in the contained areas.

\\nodename\Galaxy!area!area All alarms and events from the object itself.\\nodename\Galaxy!winplatform All alarms and events from the WinPlatform object itself.\\nodename\Galaxy!engine All alarms and events from the engine object (AppEngine or

ViewEngine) itself.\\nodename\Galaxy!dio All alarms and events from the device integration object itself.

Alarm Query Results\\nodename\Galaxy!area!object.* All alarms and events from a specific object within an

area.\\nodename\Galaxy!area!*.attribute All alarms and events from all the objects in the area for

the specific attribute.\\nodename\Galaxy!area!objectprefix* All alarms and events from objects whose name begins

with the specific prefix.



General AttributesAlarm Attributes

You can set individual alarms within an object for each type of alarm. For example, you can set alarms for each of the limits of a level alarm. The calculated AlarmMode attribute value of an individual alarm uses the same inputs an object alarm. The parent AlarmMode attribute is from the object itself. As with object alarms, the individual alarm mode is set to the most restrictive input state. For example, if the object’s AlarmMode state is disabled and the individual alarm’s AlarmInhibit is FALSE, the individual alarm is disabled.

Each individual alarm is autonomous from other individual alarms in an object. The AlarmMode of an individual alarm is not propagated to other alarms. Unlike inhibit for the entire object, inhibit of an individual alarm does not affect the alarms of any contained objects. You can selectively enable, silence, or disable an individual alarm and not set other alarms to the same value within the object hierarchy.

Alarm Attributes

Attribute DescriptionAlarmInhibit If TRUE, all alarms for the object are disabled. Typically written to by a script, user or

input extension. If an area, all alarms for objects in area are disabled. If a container, all alarms for objects in container are disabled.

AlarmMode Indicates current alarm mode of object. The mode is based on the object's commanded mode; if an area and container are enabled. Otherwise, the most disabled state of the container or parent area applies. Disabled mode is considered the most disabled, then Silenced and then Enabled.

AlarmModeCmd The currently commanded alarm mode of the object. InAlarm Indicates whether any of the object's alarms are in the Active state. Can be true only

when the object is on scan and alarms are enabled.

Attribute Description<Attribute>.Acked Used to specify whether an alarm has been acknowledged. This

attribute is updated when the AckMsg attribute is set. This attribute is always set to FALSE when a new alarm condition is detected (when the InAlarm attribute changes from FALSE to TRUE).

<Attribute>.AckMsg The operator comment at the time the alarm is acknowledged. Any received text is stored, and the Acked attribute is set to TRUE. Also, the TimeAlarmAcked attribute is set to the current time. The maximum length is 256 characters.

<Attribute>.AlarmMode The current alarm mode setting. Valid values are: Enable, Disable, Silence.

<Attribute>.AlarmModeCmd The command to set the alarm mode. Valid values are: Enable, Disable, Silence.

<Attribute>.Category The category of the alarm. The label of each alarm category is fixed.

Wonderware Training


Enabling, Silencing, and Disabling AlarmsAlarms can be enabled, disabled, or silenced while an application is running. Setting an object’s alarm state can be set at the Area level, at the container object level, or at the individual object. In addition, individual alarms within a single object can be enabled, silenced, or disabled.

Enabled: All alarms for an object are reported to client applications and saved as historical data. The enabled state is less restrictive than the silenced or disabled alarm states.

Silenced: All alarms for an object are detected, saved to history, and sent to alarm clients. But, alarm clients do not show the alarms. The silenced alarm state is more restricted than the enabled state, but less restrictive than the disabled state.

Disabled: No alarms for the object are detected. The alarm is return-to-normal until the alarm is re-enabled. The disabled state is more restrictive than the silenced and enabled alarm states. A disabled alarm does not require acknowledgement.

<Attribute>.DescAttrName The description of the alarm. The description must be of type String or InternationalizedString, with a maximum length of 329 characters. The DescAttrName attribute can contain a static alarm description or a reference to another string attribute within the same object containing the alarm description. The reference must be in the form: "me.AttrName". If the reference is invalid, the actual reference string is used for the description. If nothing is supplied for the DescAttrName attribute, the object’s ShortDesc attribute is used at run time.

<Attribute>.InAlarm The alarm state. This is exactly the same as the attribute in the host primitive that represents the alarm condition, except when the alarm state is disabled, in which case, InAlarm is set to Off, regardless of the actual condition state.

The quality is set during execute to the quality of the attribute, except when the alarm is disabled, in which case the quality is always GOOD.

<Attribute>.Inhibit If true, the alarm is disabled. This attribute is intended to be written to by a script or user or input extension. Only the individual alarm is disabled. No other alarms are disabled in the same object or in any objects that are assigned to or contained by this object.

<Attribute>.Priority The value for the urgency of the alarm. Valid values are 1 through 999, with 1 being the most urgent.

<Attribute>.TimeAlarmAcked The timestamp indicating the last time this alarm was acknowledged. The date format reflects the current locale setting for the operating system.

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

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

Attribute Description



LogDataChangeEvent()The LogDataChangeEvent() script logs an application change event to the Galaxy Historian. The LogDataChangeEvent() function works only in object scripts, not in symbol scripts.

Syntax: LogDataChangeEvent(AttributeName, Description, OldValue, NewValue, TimeStamp);

A symbol script still compiles if the LogDataChangeEvent() function is included. However, a warning message is written to the log at run time that the function is inoperable.

This example logs an event when a pump starts or stops with a timestamp of the current time when the event occurred.

LogDataChangeEvent(TC104.pumpstate, “Pump04”, OldState, NewState);

Alarm Extensions An alarm extension can be added to a template or instance Boolean attribute in the Extensions tab of the object’s editor. If added to a template attribute, the alarm extension is automatically locked in derived objects. Attribute arrays cannot be extended.

On the Extensions page of the Object Editor, select an attribute from the Extendable Attributes List. The four extension groups dynamically change to allowed extension rules for the selected attribute type.Select the Alarms check box. For Alarm Extension, select a Category from the list.

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

Select to use either the Object Description for Alarm Message or type another alarm message in the Message box. An X appears in the A column of the selected attribute.

Wonderware Training


For Boolean Label Extension, specify text strings for the False state and the True state, if needed. These text strings appear in the Active Alarm State list for you to select.

Lock the values, if needed. The lock symbol is available only when you are extending a template. Otherwise, it indicates the lock condition of the value in the parent object.

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

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

Alarm DB Logger is an Alarm Consumer. You configure it with an alarm query that defines which alarms are to be logged. You use the Alarm DB Logger to specify alarm queries and to log the resultant alarm records. These alarm queries are sent via the Alarm Consumer interface of the Distributed Alarm System.

The Alarm DB Logger also has the ability to auto-reconnect. When the connection to the database is lost, the logger continually checks for the database connection at regular intervals. When the connection is re-established, logging proceeds.

The Alarm DB Logger reports all errors whether running as a service or a normal application to the Wonderware Logger.

The Alarm DB Logger consists of the following two components:

Alarm DB Logger Manager Utility – This utility is a separate executable that solely takes care of starting and stopping the logging operations. It is launched and starts working either as a service or a normal application (depending upon the running mode you select in the Alarm DB Logger Manager). The logging utility retrieves the setting information from the registry and performs the logging.

Alarm DB Logger Configuration Utility – This utility takes care of user input and database configuration. The Alarm DB Logger Manager allows you to select the mode in which the Alarm DB Logger will run (either as a windows service or a normal application).

Note: The Alarm DB Logger Manager only saves the setting values into the registry. The utility is responsible for starting and stopping the Alarm DB Logger. It is also responsible for displaying the status of Smart Cache. When Alarm DB Logger Manager (almlogwiz.exe) is closed while wwalmlogger.exe is running (either by pressing the Esc key or by clicking the “X” button on the upper right of the dialog box), the logging operation does not stop.



The progress control status indicates the percentage fill of the in-memory buffer with alarm records. The alarms are buffered when the SQL Server connection is down, and/or when the alarms are coming at a rate faster than the logging rate of Alarm DB Logger.

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

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

To use the Alarm DB Logger Manager Utilitya. Start up the Alarm DB Logger Manager.

The Alarm DB Logger Manager dialog box appears.

When minimized, the Alarm DB Logger Manager appears as an icon in the system tray. When you right-click the icon, a popup menu appears displaying the following commands:

Wonderware Training


Start – Begins the alarm logging process.Stop – Ends the alarm logging process.Settings – Opens the Alarm DB Logger Manager - Configuration dialog box.Hide Window –Minimizes the Alarm DB Logger Manager dialog box to an icon in the system tray.Show Window – Opens and maximizes the Alarm DB Logger Manager dialog box.Close – Exits the Alarm DB Logger Manager Utility.

b. The Smart Cache Status indicates the percentage fill of the in-memory buffer with alarm records.

c. Click Settings to configure the Alarm DB Logger. The Alarm DB Logger Manager - Configuration dialog box appears.

For more information on configuring the Alarm DB Logger, see “Alarm DB Logger Configuration.”

d. Click Start to begin the alarm logging process.

e. Click Stop to end the alarm logging process.




Wonderware Training


Lab 15 – Configuring Alarms

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


Configure the $WinPlatform object as an alarm provider for the galaxy Configure alarms within objects including using the Alarm Extension Configure and use the Alarm DB Logger Manager Use alarm queries to request real-time alarms from alarm providers



Configure the WinPlatform object as an Alarm Provider a. Configure the GRPlatform instance to be an InTouch alarm provider for all areas in the

galaxy.

Configure the $Mixer.LIT template for alarms b. Configure the $Mixer.LIT template with a Hi level alarm, with a limit of 80.0, a priority of 500

and “Mixer Hi Level alarm” as the alarm message.

c. Lock all level alarms attributes but the Hi Limit.

Configure the Alarm extension d. Add a Boolean Object writeable UDA to the $Mixer.Agitator template named Malfunction.

e. Extend the Malfunction attribute with an Input extension and configure its Source as ---.

f. Extend the Malfunction attribute with an Alarm extension and lock it. Configure its category as Process and leave the default values on the rest of the attributes.

Update auto-configuration script on $Mixer g. Modify the AssignIO script of the $Mixer template by adding the following line of code to the

Configure agitator section of the code: Me.Agitator.Malfunction.InputSource = dataSource + “_AG_Malfunction”;

View the alarm data on Runtime h. Deploy the GRPlatform object on cascade.

i. Using the watch list created in Lab 5, add a new watch window called Alarms and add the following attribute references:

LIT_001.PV LIT_001.InAlarm LIT_001.Hi.InAlarm LIT_001.Hi.Limit LIT_001.Hi.TimeAlarmOn LIT_001.Hi.TimeAlarmOff Agitator_001.InAlarm Agitator_001.Malfunction Agitator_001.Malfunction.InAlarm Agitator_001.Malfunction.TimeAlarmOn Agitator_001.Malfunction.TimeAlarmOff Line1.AlarmOnCnt

j. Save the watch list.


Wonderware Training


Configure and Start the Alarm DB Logger Manager k. Use the Alarm DB Logger Manager to create a a database named WWALMDB on your local

computer. Use the following user information:

l. Configure the Alarm DB Logger Manager to query all priorities from the following alarm query:

\Galaxy!ControlSystem

\Galaxy!Discharge

\Galaxy!Intake

\Galaxy!Production

m. Leave the defaults advanced settings and start Alarm DB Logger Manager.

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


User Name: sa

Password: [Check with your instructor for the correct password]



Configure the WinPlatform Object as an Alarm Provider1. In Model view, double-click the GRPlatform instance to open its configuration editor.

2. Check the InTouch alarm provider attribute and leave the Alarm areas attribute empty.



The Alarm areas field is used to specify a space-separated list of areas to subscribe to. It is used to filter alarms on the network. For example, "Area1 Area2 Area3". If blank, the platform will subscribe to all areas in the Galaxy and act as an InTouch alarm provider for the whole Galaxy.

Wonderware Training


Configure the $Mixer.LIT Template for Alarms 4. Double-click the $Mixer.LIT template to open its configuration editor.

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


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

Level alarms: (locked)

Hi: checked (locked)

Hi Limit: 80.0 (unlocked)

Hi Priority: 500 (locked)

Hi Alarm Message: Mixer Hi Level alarm (locked)



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

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


Data type: Boolean

Category: Object writeable

Wonderware Training


10. Select the Malfunction attribute.

11. Configure the Malfunction extensions as follows:


Input extension: checked

Source: ---

Alarm extension: checked (locked)

Category: Process

Priority: 500

Alarm message: me.ShortDesc

Active alarm state: True

Ensure the Malfunction attribute is selected beforeconfiguring Input extension.



Update Auto-configuration Script on $Mixer 13. Double-click the $Mixer template to open its configuration editor.


15. Select the AssignIO script and add the following line of code to the Configure agitator section of the code:

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


Wonderware Training


The ArchestrA IDE should now look similar to the following:

View the Alarm Data in Runtime 17. Deploy the GRPlatform object with Cascade Deploy checked in the Deploy dialog box.


19. Right-click on the LIT_001 instance and select View in Object Viewer.



Note: If Object Viewer was open during undeployment, you will see the following error message. Click the OK button to close and then re-open Object Viewer from the ArchestrA IDE.

20. Load your saved Watch List.


22. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to Alarms.

23. Add the following attributes to the watch list:

For the LIT_001 object: Hi.InAlarm Hi.Limit Hi.TimeAlarmOff Hi.TimeAlarmOn InAlarm PV

For the Agitator_001 object: InAlarm Malfunction Malfunction.InAlarm Malfunction.TimeAlarmOff Malfunction.TimeAlarmOn

For the Line1 object: AlarmOnCnt


Wonderware Training


Configure and Start the Alarm DB Logger Manager. 25. Start the Alarm DB Logger Manager by selecting Start / All Programs / Wonderware /

InTouch / Alarm DB Logger Manager.

26. In the Alarm DB Logger Manager window, click the Settings button.

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

28. Click the Create button

Server Name: localhost

Database: WWALMDB

User Info:

User Name: sa

Password: [Check with your instructor for the correct password]

Logging Mode: Detailed



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

29. Click the OK button to continue.

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

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

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

From Priority: 1

To Priority: 999

Alarm Query: \Galaxy!ControlSystem

\Galaxy!Discharge

\Galaxy!Intake

\Galaxy!Production

Wonderware Training


32. Click the Next button to continue:



33. At the Alarm DB Logger Manager – Advanced Settings dialog box, leave the default settings.

34. Click the Finish button.

35. In the Alarm DB Logger Manager window, click the Start button to start the Alarm Database Logger.

Wonderware Training


When the Alarm Database Logger is started, the Alarm DB Logger Manager window will look similar to the following:

View the Alarm History Data 36. Start the SQL Server Management Studio by selecting Start / All Programs / Microsoft

SQL Server 2005 / SQL Server Management Studio.

37. Configure the Connect to Server dialog box as follows:

Server type: Database Engine

Server name: localhost

Authentication: Windows Authentication

38. Click the Connect button to continue.



39. In the Object Explorer (left pane) navigate to localhost / Databases / WWALMDB and select Views to get a list of all the database’s Views in the Object Explorer Details (right pane).

Wonderware Training


40. In the Views list (right pane), right-click on the v_AlarmHistory view and select Open View to display the current list of alarms logged in the database.

Your data should look similar to the following:




Wonderware Training


Section 2 – Historization

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

Historization BackgroundThe history system supports historization of process data in distributed history architecture.

One or more Historian products can be installed on the same network as the Application Server Galaxy. The Galaxy can be configured to store history data into one or more of those Historians. Since the Engines use push technology to historize, the Historian box does not have any ArchestrA software requirements.

Each Engine in the Galaxy is configured with the location of the Historian storage node to which its history data is to be sent. This configuration is stored in an attribute within the Engine.

Wonderware Historian requires a Historian tag to be configured in its database for each attribute to be historized by an AutomationObject. Thus, there is a one-to-one relationship between a historized object and a tag in Wonderware Historian.

When an AutomationObject starts up it registers its configuration data with Historian using a Historian supplied interface. If the Historian tag already exists, it means this object has been previously registered. If the Historian tag does not exist, it is created automatically. In either case, the object receives back a unique identifier (handle) for that tag. This is a push-style configuration model, meaning the configuration data for each historized property of an object is dynamically, and automatically, pushed to Historian. The user does not need to run Historian configure and import tags from Application Server (as done with InTouch today).

For storage, the story is similar. When an object decides to store a new VTQ to Historian, it pushes that storage update message, with the new VTQ, to Historian using a Historian supplied interface. The Historian must exist on a different node from the AutomationObject. The history primitive uses the previously-returned unique identifier for the Historian tag that corresponds to the historized property to identify the tag being stored.

History Configuration

Historizable Data Types for Attributes For attribute data to be stored in the historian, a host AppEngine must be configured to send history data to a Wonderware Historian node. For each object, you can configure attributes of the following data types to be saved to the Wonderware Historian.

Float (numerical)Double (numerical) Integer (numerical)Boolean (non-numerical)String – Unicode (non-numerical)CustomEnum (non-numerical) maps to Historian Integer

Section ObjectivesFamiliarize you with the background concept of historization, and Enable you to understand details of historizable configuration.



ElapsedTime (numerical) Maps to Historian Float, converted to secondsArrays or portions of arrays are not supported. Enum type attributes are saved as Wonderware Historian integer ordinal values.IEEE NaN values for float and double data types are converted to null values prior to being sent to the historian. NaN values are associated with a Bad OPC data quality.All numerical attributes sent to the Wonderware Historian are in the engineering units specified for the attribute. The Wonderware Historian does not scale numerical values.

Configuration of a non-numerical Attribute for Historization For an object that has non-numerical historizable attributes, the ArchestrA IDE user can enable history for each attribute. No other configuration data is provided by the user since these attributes are historized upon change of value. Also, a change in data Quality, regardless of whether the Value changed too, always causes a new record to be historized/stored.

Configuration of a numerical Attribute for HistorizationFor an object that has numerical historizable attributes, the ArchestrA IDE user can enable history for each attribute. Once enabled, certain configuration settings can be specified. These settings determine how often data is historized.

The following configuration settings can then be specified:Value Deadband – the threshold value (measured in engineering units) that the absolute value of the difference between the new and last-stored values must differ before storing the new value to history. A value of 0 is valid and is the default and means that some change is required prior to storing the value. A change in Quality always causes a new record to be stored, regardless of whether the Value has changed.

Force Storage Period – this is the time interval, in seconds (floating point), at which the value must be stored regardless of the value deadband setting. In addition to the Value Deadband setting, the value will be stored continuously at this interval. A value of 0 disables this feature.

Trend Hi – specifies the initial maximum trend value for clients.

Trend Lo – specifies the initial minimum trend value for clients.

Dynamic, Automatic Configuration of Wonderware Historian at Object Deploy TimeWhen 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 TimeWhen an AutomationObject that has been historized is redeployed, the object causes a reconfiguration of any changes that were caused by the redeploy to be changed in the Historian product automatically. For example, if the engineering units string for the tag changes from “Deg F” to “Deg C” upon a redeploy, the Historian configuration database must reflect this change.

Wonderware Training


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

Historian Installation and DeploymentWonderware 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 MappingThe update packet to be sent to Historian contains a Value. This value may need to be converted from the value received from Message Exchange if the received datatype is not one of the native Historian datatypes as specified below:

Enum – historize as Integer ordinal value

Strings – Historian strings are limited to 512 characters, so truncation may occur. If so, Quality is set to Uncertain.

NaN Handling For Float and Double attributes, a potential value is the IEEE NaN encoding for the float or double representation. NaN values can be generated for attributes that are to be historized. These NaNs will be accompanied by a Bad OPC Data Quality. In any case, NaN is a valid value that can be generated for floats and doubles. Unfortunately, Historian clients do not handle NaN properly. Therefore, ArchestrA will convert the NaN value to a Null value representation just prior to sending to Historian.

Historian Quality Mapping The Application Server Data Quality is somewhat different than the Historian data quality. The plan is for Historian to support the OPC Quality definition. Thus, the 16-bit value for the OPC Data quality is sent to Historian. Within those 16-bits, the low order byte is the standard OPC part. Wonderware reserves the high order byte. The Good, Bad, Initializing (which is a form of Bad) and Uncertain states are in the low order byte per the OPC standard.

Any change in the OPC Quality, regardless of whether the Value component has changed, will cause storage of a new record to Historian. This means that a point that has an identical value over some period of time with varying qualities will have multiple records stored to Historian. The quality stored in Historian is to be the actual quality of the attribute in Application Server with no modification. However, Historian may insert “artificial” quality (for example 24) and null value in the database when certain situations such as disconnects occur. It does this in cooperation with the ActiveFactory clients to project the right information on the client.

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



Application Server History Storage PerformanceThe link from the Application Server to Historian may fail or be down for any of a number of reasons:

The network connection to Historian goes down unexpectedly.The Historian storage node goes down or fails unexpectedly.The Galaxy Platform and its Engines which are generating history startup prior to Historian node startup in a recovery situation.History data must be preserved in these cases by having it stored locally until the link to Historian has recovered or Historian has started. This is called store/forward. This capability is limited by the hard disk capacity of the system where data is stored before forwarding. The maximum data storage size to be consumed by store/forward must be configurable in the Platform. Also, whether store/forward is enabled/disabled can be configured.When store/forward capacity is consumed, the oldest data is discarded in preference to newer data.

Historian extension

You can assign historical extensions to extended attributes that you select from the Extensions tab of your objects.

After you select the History extension check box to save the data to history associated with the attribute extension you selected, an X appears in the H column of the Extendable Attributes list to indicate its data is saved to the historian.

The following are the common historical attributes that you can configure for your system and application objects.

Force Storage Period: Interval in milliseconds in which an attribute value is saved to the Historian, regardless of whether the value exceeds its value deadband setting or not. An attribute value is saved to the Historian at every Force Storage interval. The default value of zero (0) disables the Force Storage period.

Value Deadband: Threshold value in engineering units, which is the absolute difference between the current and most recent saved historical values. The current value must exceed the absolute deadband to be saved as historical data.

The Value Deadband filters out small, momentary value changes from being saved to the Historian. A new value that is within the range of the deadband is not saved to the Historian. The

Wonderware Training


default value of 0.0 disables the Value Deadband and any change to a value is saved as historical data.

Interpolation Type: List of methods used by the Historian to interpolate analog historical data. The interpolation type determines which analog value is selected during a Historian data retrieval cycle. Interpolation types include System Default, Stairstep, or Linear. The default interpolation type is System Default.

Stairstep: No interpolation occurs. The last known value is returned with the given cycle time. If no valid value can be found, a NULL is returned to the Historian.

Linear: The Historian calculates a new value at the given cycle time by interpolating between the last known value prior to the cycle time and the first value after the cycle time.

System Default: The Wonderware Historian system-wide interpolation setting. The system-wide setting must be either stairstep or linear interpolated.

Rollover Value: Positive integer value that represents a tag’s reset limit when the Historian operates in counter retrieval mode. In counter retrieval mode the Historian uses a tag's rollover value to calculate and return the delta change between consecutive retrieval cycles. The default value is 0.0.

The Rollover value applies only to numeric attributes. The Rollover value is disabled if the historical attribute data type is Boolean or a string.

Trend Hi: Initial maximum trend value in engineering units for clients. The default is 100.

Trend Lo: Initial minimum trend value in engineering units for clients. The default is 0.0.

Sample Count: Integer that indicates the number of samples the Historian should store in the active image for an attribute value. Acceptable range of values is from 0 to 9999. The Historian enforces a sample count of 65 for the active image.

If the current sample count for the active image is 65, and you set the sample count to a value less than or equal to 65, the new sample count setting is not saved to the Historian database, and the active image count remains at 65.

If the current sample count for the active image is greater than 65, and you set the sample count to a value less than or equal to 65, the new sample count is saved to the Historian database and 65 is used by the active image.

Regardless of the current sample count for the active image, if you set the sample count to a value greater than 65, the new sample count is saved to the Historian database and used by the active image.

Enable Swinging Door: A flag that indicates whether the swinging door rate deadband is enabled or disabled. The default is disabled.

Enable Swinging Door is disabled if the historical attribute data type is Boolean or a string.

Rate Deadband: Percentage rate of change deadband based on the change in the slope of incoming data values to the Historian. For example, specifying a swinging door rate deadband of 10 percent means that data is saved to the Historian if the percentage change in slope of consecutive data values exceeds 10 percent.

The default is 0.0, which indicates a swinging door rate deadband is not applied. Any percentage greater than 0.0 can be assigned to the rate deadband.




Wonderware Training


Lab 16 – Configuring History

IntroductionIn this lab you are to configure your galaxy for historization to your local Wonderware Historian server. As an example, the mixer’s level and state of the Inlet Valve 1 is configured, as well as the speed of the mixer’s agitator.

Although ActiveFactory Trend is outside the scope of this class, you will use it this lab as a quick and simple way to retrieve history data from the history database.


Configure the $AppEngine object to store history data to a Wonderware Historian Configure attributes within objects for historization including the History Extension



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

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

Configure the $Mixer.LIT template for History c. Configure the $Mixer.LIT template to historize the PV attribute using the default values for the

history attributes.

d. Lock all history-related attributes for the PV attribute.

Configure the $Mixer.Inlet1 template for History e. Configure the $Mixer.Inlet1 template to historize the PV attribute using the default values for

the history attributes.

f. Lock all history-related attributes for the PV attribute.

Configure the History extension g. Extend the Speed attribute of the $Mixer.Agitator template for historization using RPM as the

engineering units.

h. Lock the history extension.

View the History data with ActiveFactory Trend i. Deploy the GRPlatform object on cascade.

j. Use ActiveFactory Trend to connect to the local Wonderware Historian using Integrated security.

k. Visualize the trend for the following tags: Agitator_001.Speed Inlet1.PV LIT_001.PV



Wonderware Training


Configure the WinPlatform Object 1. Double-click the GRPlatform instance to open its configuration editor.

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

History store forward directory: C:\S&F





Configure the AppEngine Object for History 4. Double-click the AppEngine instance to open its configuration editor.

5. Configure the History section of the General tab as follows:

Enable storage to historian: checked

Historian: [Name of your local computer]

Leave the default values for the rest of the attributes.


Wonderware Training


Configure the $Mixer.LIT Template for History 7. Double-click the $Mixer.LIT template to open its configuration editor.

8. Select the History tab and check the PV box to historize the PV attribute. Leave the default values and lock all attributes by clicking the lock on Historize.


Configure the $Mixer.Inlet1 Template for History 10. Double-click the $Mixer.Inlet1 template to open its configuration editor.

11. In PV section of the General tab, configure the object as follows:

Historize PV: checked (locked)

Force storage period: 0 (locked)

Sample Count: 0 (locked)




Configure the History extension for the $Mixer.Agitator template13. Double-click the $Mixer.Agitator template to open its configuration editor.



16. Check and lock the History extension and configure it as follows:

Engineering units: RPM

Leave the default values for the remaining attributes.


View the History Data with ActiveFactory Trend 18. Deploy the GRPlatform object using the default Cascade Deploy.

19. Start ActiveFactory Trend by selecting Start / All Programs / Wonderware / ActiveFactory / Trend.

Ensure the Speed Attribute is selected before configuring History extension.

Wonderware Training


20. Configure the Server List Configuration as follows and click the Add button:

Server: LOCALHOST

Authentication information:

Use Integrated security: checked

21. After the server has being added to the Server list click the Close button.



22. With LOCALHOST selected on the Servers pane (top-left pane), you will see the attribute references configured for historization in the Tags pane (bottom-left pane).

Wonderware Training


23. In the Tags pane (bottom-left) double-click the following tags to add them to the trend: Agitator_001.Speed Inlet1_001.PV LIT_001.PV

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

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




Wonderware Training

Module 6

SecuritySection 1 – Security Overview 6-3

Lab 17 – Security 6-13

6-2 Module 6 – Security

Module ObjectiveConfigure, deploy, and test security with Application Server.

Wonderware Training

Section 1 – Security Overview 6-3

Section 1 – Security Overview

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

ArchestrA security is designed to prevent users from performing unauthorized activities. This includes users of:

The ArchestrA IDE when configuring and deploying objects.The System Management Console (SMC) when performing maintenance and system administration functions.View (or other GUI client applications) when performing runtime operations including monitoring, control and data entry functions.Other future ArchestrA utilities.

The system is not designed to stop malicious access to the system. The security system is designed to support the normal operating parameters of an automation system. Passwords are encrypted but they are stored in a database that is accessible. So, the system is not designed to stop determined programmers from accessing the system.

If your application requires a higher level of security, this can be achieved by typical IT departments using tools provided by Microsoft®. To facilitate a higher level of security, the security model can be configured to support operating system authentication. In that case, the configuration and runtime permissions can be mapped to the external operating system account. Some options include password timeout and electronic signature authentication.

The ArchestrA Security ModelSee the image below for a visual hierarchical overview of the ArchestrA security model. This shows the relationships of the objects in the Security Model to each other and to the rest of the ArchestrA System.

Each attribute of an AutomationObject is given a security classification. This provides the ability to define who can write to attributes of an object.

Section ObjectiveIntroduce Security with Wonderware Application Server.



For example, a certain attribute of the DiscreteDevice may be set by the operator to change its status while a different attribute may be set by a technician. These attributes are meant for different people, Operator (operate) and Technician (tuning). Configuring access to all users for all AutomationObjects on individual bases would be a time-consuming and repetitive effort. Thus, configured Roles and Security Groups can be applied to Users to enable easier configuration of the Security Model.

Security Groups are simply the grouping of objects that you want to behave in the same way with respect to security. Every AutomationObject belongs to exactly one Security Group. By default all new objects belong to the Default Security Group, which cannot be removed. Roles generalize Users function, such as Intake Operator or Dispatcher. Roles are granted permissions onto a number of Security Groups. If, for instance, a Role is granted Tuning access to a Security Group, then that role has write permissions to all object attributes with a security classification of Tuning (but none other). Roles are also granted utility functions-based permissions, such as Deploy or Can Edit.

For example, a Role of Software Engineer is created. This Role has full permissions to modify the objects in the ArchestrA IDE, and has permissions to deploy as well. To undeploy an object, though, the system requires that the object is offscan. Control of offscan/onscan is controlled by Operation permissions -- not granted to the Software Engineer, so he cannot undeploy any objects in Onscan mode. Only an operator (with Operation permissions) can do so.

Permissions are required to perform most ArchestrA activities. Usually only one permission is required to perform a given activity, but occasionally, two or more permissions may be required for operation-critical actions.

The final aspect of the Security Model is the User. This describes the access to the system allowed by a User. The User can be granted as many Roles as needed to perform their job.

ArchestrA’s security system is configured in the Configure Security dialog box by:

1. Enabling Security

2. Defining your Security Model

3. Mapping Users to the Security Model

4. Mapping AutomationObjects to the Security Model

If the Security is not enabled then Authentication mode is disabled.

Wonderware Training


Authentication Mode



On the Authentication Mode page, choose the mode of Galaxy security: None: The default setting for new Galaxies, this mode is considered Open Security. It leaves all functions open to all users. No authentication is provided for any operations in the ArchestrA configuration or runtime environment. No login dialog boxes are displayed for operating Application Server utilities or runtime processes.Galaxy: This mode uses local galaxy configuration to authenticate the user. Use this setting to create a user security system controlled by the Galaxy database.OS User Based: This mode enables the Authorization of individual OS users. Use this setting to take advantage of the operating system's (NT) user authentication system, on an individual user basis.OS Group Based: This mode enables the Authorization for users based on which OS Groups they have been assigned to. Use this setting to take advantage of the operating system's user authentication system, on a group basis. When you select OS Group Based Authentication mode, the following Configurable Intervals options are displayed:

Login time: This value (in milliseconds) is the timeout period during which the system validates the user's membership against the OS groups selected as ArchestrA Roles. After this timeout period, the login operation defaults to the local cache. The result of a successful login for a value other than 0 (zero) is that local cache is stored/updated. If the login operation times out and the user has performed a previous ArchestrA login on the computer, local cache is used; if the user has never performed an ArchestrA login on the computer, the ArchestrA login fails. Minimum allowed value is 0 (zero); maximum is 9,999,999. Default value is 0 (zero), which switches off this feature (the operation does not time out). The Login time option should be used primarily for intermittent or slow network scenarios. The value you should use in this option is determined by the speed of your network and by the number of groups configured in ArchestrA. In other words, the slower the network or the higher the number of groups, the greater the value should be for Login time.Role update: This value (in milliseconds) is the time between each validation attempt per OS group for the user's membership when a login is attempted. The user membership update is done one role per Role update interval to minimize network usage. Minimum allowed value is 0 (zero); maximum is 9,999,999. Default value is 0 (zero), which switches off this feature (the operation does not pause between validating user membership and groups). This option should be used primarily for intermittent or slow network scenarios. This option operates independently of the Login time option. In other words, even if Login time times out, the role update operation continues in the background and eventually updates user-to-role relationships for this user in the local cache.

Note: When you select Authentication Modes, note the messages relevant to your ArchestrA installation that are displayed in the Note box.

Wonderware Training


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

Note: In both OS-based authentication modes, a user is not presented with a log in dialog box if that user has authorization to use that ArchestrA utility.

A user can have multiple accounts within the security system. For instance, a user may have an account that provides permissions for working with instances but not templates. The same person may have another supervisory account for working with templates and managing users in the ArchestrA environment. To switch between levels of authority, the person must login as the new user. To do this, click Change User on the Galaxy menu.

If the Security is not enabled then Authentication mode is disabled.



OS Group Based Security

If you use OS Group Based Authentication Mode, you should first familiarize yourself indepth with the functions of the Windows operating system, particularly its user permissions, groups and security features. ArchestrA OS Group Based security leverages those Windows features.

Take note of the following behaviors that are unique to OS Group Based Authentication Mode: A newly-added user working on a computer that has no access to the Galaxy node cannot write to an attribute on a remote node if that user has never logged on to the remote node. This is true even if the user has been given sufficient runtime operational permissions to do writes. To enable remote writing capabilities, log on to the remote node at least once.If you log in to ArchestrA on a workstation that belongs to Domain A and Domain Controller A fails, locally cached login data is used on subsequent logins. When the domain controller returns to operation, your login will fail during the time period that trusts are being reestablished by the controller. If during the controller outage, your username/password data was changed, you may be able to use the old login data if you intend to work locally. If you want to perform remote operations, you should attempt to log in with the new login data. If that fails, the trusts are being reestablished by the controller, and you should retry at a later time.

Wonderware Training


If you attempt to log in to ArchestrA on a workstation running Windows 2000, login will fail until you properly set the TCB privilege in Local Security Policies. Do this as follows: On a Windows 2000 Server computer - on the Start menu, point to Programs and then Administrative Tools, and then click Local Security Policies (On a Windows 2000 Professional computer - on the Start menu, point to Settings and then click Control Panel. In the Control Panel, double-click Administrative Tools. In the Administrative Tools utility, double-click Local Security Settings.). In the left pane of the Local Security Settings dialog box, expand the Local Policies folder and click the User Rights Assignment folder. In the right pane, double-click Act as a part of operating system. In the Local Security Policy Setting dialog box, add the user (the user logged in to the computer) by selecting the Local Policy Setting check box, and then click OK. Log off and log in to the computer again to implement the new TCB privilege. You must be an administrator to set TCB privilege.The list of domains and user groups appears differently in the group browser depending on whether you have configured your domain as a Mixed or Native domain. Your unique appearance should map to the list of domains and user groups you see when you use the Windows tool for managing your domain. A domain group that is configured as "Distribution" rather than "Security" cannot be used for security purposes.The user's full name is not available to any client (for instance, an InTouch window) if the domain controller is disconnected from the network when the user logs in to ArchestrA for the first time. If the user previously logged in to ArchestrA when the domain controller was connected, the user's full name will still be available to the client from data stored in cache even if the domain controller is disconnected when the user subsequently logs in to ArchestrA.

User AuthenticationClient utilities like ArchestrA IDE, SMC, and InTouch for System Platform require their users to be authenticated so that the appropriate permissions can be confirmed. An authenticated user is granted the sum of all Permissions within their assumed Roles.

Supported Operating System User ConfigurationsThe following is the list of supported Operating System (OS) user configurations that are supported within the security system:

Login using an OS user who has been authorized and whose password has expired. The user will get the message “Login Failure: The specified account password has expired.” The user will then be able to change the password.If the OS user is a new user and the account has been configured to require the password to be changed on the first logon, on attempting the login they will receive the message “ Login Failure: The password for the specified account must be change before first logon.”

Supported Operating System Security ConfigurationsThe following list of OS security configurations will be supported:

Machines and users participating in a domain.Users being drawn from multiple domains.Machines and users defined within a Workgroup. Note the users/groups have been defined on each machine and imported into the Galaxy Repository (GR) and defined as Local Host.



Minimal Operating System Permissions Required for Starting OS UserThe 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 DialogIf security is enabled within the Galaxy, a client utility Logon dialog will be displayed. Application Server provides a standard login dialog.

The login appears:The user explicitly chooses a Log On option from within the user interface. It is not necessary to explicitly Log Off before logging on using a different User Profile. The previous user will be implicitly logged off.

Username and Password are entered onto this dialog.

If OS Authorization is being used then the user will also be required to select from a list of accessible domain name for the user being logged in.

Wonderware Training


Attribute Security ClassificationsAttribute SecurityClassifications classify Attributes of AutomationObjects (like the previously discussed Command attribute) from a security perspective. They are:

FreeAccess – Any User can write to these attributes to perform safety or time critical tasks that could be hampered by an untimely logon request (for example halting a failing process). This does not require the user to have any privileges.Operate – Operators write to these attributes during normal day-to-day operations. These include Attributes such as Setpoint, Output and Control Mode for a PID Object, Command for a Discrete Device Object, etc. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write.Secured Write – Operators write to these attributes for normal interaction with a highly secured object forces re-authentication. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write. The AutomationObject will reject the write requested via the return status and the user must re-enter the login details.Verified Write – Operators write to these attributes for normal interaction with a very highly secured object. This is similar to Secured Write, however it also requires a second user authentication. The second user must also be assigned to the Security Group of this AutomationObject, to allow the write.Tune – Writing to these attributes is considered a tuning activity. Examples are attributes that adjust alarm setpoints, PID sensitivity, etc. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write.Configure – Writing to these attributes is considered a significant configuration change. For example, a PLC register that defines a Discrete Device input. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write. It also requires that the Object is currently OffScan.Read-Only – The attributes are never written to at runtime, regardless of the user's permissions.

There are two other situations where an Attribute's Security Classifications are specified:When a User-Defined Attribute is configured.When an Engineer overrides the Attribute Security Classification within a Template editor.

Note: Overriding Security Classifications is not permitted within Instances.




Wonderware Training


Lab 17 – Security

IntroductionAs you work with the security settings within the ArchestrA IDE you set up various Roles and Users and configure them with different sets of permissions. You then observe the different behaviors in the Object Viewer as you logon as various users.

In this lab you configure the security settings for your galaxy and test those settings with a sample automation object that has been partially pre-configured for you.

The security configuration used in this lab is based on the following premises:

Operators: these users can acknowledge alarms and operate devices by modifying Operate attributes in the objects (for example, open a valve or start a motor); but they are not allowed to change alarm set points or other Tune attributes. Users in this role do not have access to the configuration data.

Supervisors: these users are only allowed to perform tuning configurations by modifying Tune attributes in the objects (for example, changing an alarm set point). Users in this role do not have access to the configuration data.

Engineers: these users have access to the configuration of the Galaxy through the ArchestrA IDE and configuration of the objects in runtime by modifying Configure attributes in the objects (for example, changing a deadband or an input source). Notice that users in this role do not have Operate permissions, which will prevent them from setting objects off scan before writing to a Configure attribute. It is assumed that the Operators “own” the runtime, so they have to set the objects off scan (put the devices off line) before an engineer can change the configuration on runtime.

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

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

Configure the security classifications for individual attributes within automation objects Configure the security settings for a galaxy Record and view the security audit trail for a galaxy



Import the SecurityTest Object a. Import the object in the $SecurityTest.aaPKG file located in the C:\Wonderware Training

folder.

b. Assign the $SecurityTest object to your toolset.

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

Create and Deploy an Instance of SecurityTest d. Create an instance of $SecurityTest and leave the default name.

e. Assign the new instance to the Discharge area and deploy it.

Configure Security for the Galaxy f. Configure the galaxy’s security Authentication Mode to Galaxy.

g. Add a security group named TestGroup and assign the SecurityTest_001 instance to it.

h. Configure the Default role with the following permissions:

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

No General permissions


Att1_FreeAccess: Free Access

Att2_Operate: Operate

Att3_SecuredWrite: Secured Write

Att4_VerifiedWrite: Verified Write

Att5_Tune: Tune

Att6_Configure: Configure

Att7_ReadOnly: Read Only

On the General permissions section:

IDE Permissions: unchecked

SMC Permissions: unchecked

Can Write to GObject Attribute using ObjectViewer: checked

On the Operational permissions section:

Default: checked

TestGroup: unchecked

Wonderware Training


No Operational permissions for the Default security group

Configure the Operational permissions section for the TestGroup security group as follows:

j. Add a new role named Supervisors with an access level of 1000 and with the following permissions:

No General permissions.

No Operational permissions for the Default security group.

Configure the Operational permissions section for the TestGroup security group as follows:

k. Add a new role named Engineers with an access level of 2000 and with the following permissions:

Configure the General permissions as follows:

IDE Permissions: checked (this will check every box within the node)

Framework Configuration: unchecked

SMC Permissions: checked (this will check every box within the node)

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

l. Configure the Administrator role with all Operational permissions.

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

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

o. Add a new user named WEng with a full name of William Engineer and make it part of the Engineers role. Assign ww as the password.

Can acknowledge Alarms: checked

Can modify “Configure” attributes: unchecked

Can modify “Operate” attributes: checked

Can modify “Tune” attributes: unchecked

Can acknowledge Alarms: unchecked


Can modify “Operate” attributes: unchecked

Can modify “Tune” attributes: checked


Can modify “Configure” attributes: checked





Test General Permissions p. Verify that the WEng user cannot modify the security configuration through the ArchestrA IDE.

Test Operational Permissions q. Login as Administrator and deploy the SecurityTest_001 object.

r. Using the watch list created in Lab 5, add a new watch window called Security and add the following attribute references:

s. Save the watch list.

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

View the Security Audit Trailu. Use SQL Server Management Studio to query all data from the v_EventHistory view.


Object Name Attribute NameSecurityTest_001 Att1_FreeAccessSecurityTest_001 Att2_OperateSecurityTest_001 Att3_SecuredWriteSecurityTest_001 Att4_VerifiedWriteSecurityTest_001 Att5_TuneSecurityTest_001 Att6_ConfigureSecurityTest_001 Att7_ReadOnlySecurityTest_001 ScanStateSecurityTest_001 ScanStateCmd

Wonderware Training


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

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

3. Click the Open button.




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

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

5. Click Close in the Import completed message box.

Wonderware Training


The imported object now appears in the Application toolset:

6. Move the $SecurityTest to the Training toolset.

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


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

10. Select the Free Access security classification from the popup menu.



11. Repeat step 6 to configure the security classifications for the following attributes:


Create and deploy an instance of SecurityTest 13. Using the Template Toolbox and the Model view, create an instance of the $SecurityTest

template.

14. Leave the default name and assign the instance to the Discharge area.

15. Deploy the newly created instance.

Att2_Operate: Operate

Att3_SecuredWrite: Secured Write

Att4_VerifiedWrite: Verified Write

Att5_Tune: Tune

Att6_Configure: Configure

Att7_ReadOnly: Read Only

Wonderware Training


Configure Security for the Galaxy 17. From the Galaxy menu, select Configure / Security to enable and configure security for the

galaxy.

18. Select Galaxy for the Authentication Mode.

Wonderware Training


19. Select the Security Groups tab.



20. Click the plus icon button to add a new security group. Name the new security group TestGroup.

Wonderware Training


21. Select the Default security group and locate the SecurityTest_001 instance in the objects list (right pane).

22. Drag-and-drop the SecurityTest_001 instance to the TestGroup in the security group list (left pane).



23. Select the TestGroup security group to confirm SecurityTest_001 appears as an object in the TestGroup security group.

Important! Make sure that you are moving the object’s instance (SecurityTest_001) and NOT the object’s template ($SecurityTest).

Wonderware Training


24. Select the Roles tab.

25. From the Roles available list, select the Default role and configure the permissions as follows:

Note: The Can Write to GObject Attribute using ObjectViewer permission will allow everyone (the Default role applies to every user) to modify attribute values using Object Viewer.

In the General permissions section:

IDE Permissions: unchecked (this will uncheck all boxes within the node)

SMC Permissions: unchecked (this will uncheck all boxes within the node)

Can Write to GObject Attribute using ObjectViewer: checked

In the Operational permissions section:

Default: checked

TestGroup: unchecked



26. Click the plus icon button to add a new role and name it Operators.

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

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

Can acknowledge Alarms: checked


Can modify “Operate” attributes: checked


Wonderware Training


29. Click the plus icon button to add a new role and name it Supervisors.


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




Can modify “Tune” attributes: checked



32. Click the plus icon button to add a new role and name it Engineers.


34. Configure the General permissions as follows:

:

35. Configure the Operational permissions for the Engineers security group 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)

Can Acknowledge Alarms: unchecked

Can Modify “Configure” Attributes: checked

Can Modify “Operate” Attributes: unchecked


Wonderware Training


36. Select the Administrator role and configure the Operational permissions for the TestGroup security group as follows:

TestGroup: checked (this will check every box within the group)

37. Select the Users tab.



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

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

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

Wonderware Training


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

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

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

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

Old Password: [blank]

New Password: ww

Confirm New Password: ww



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

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

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

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

48. Assign the user to the Engineers role.


New Password: ww


Wonderware Training


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

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

51. In the Change User dialog box, enter the following information.

User name: WEng

Password: ww

52. Click the OK button to log in.

Test General permissions 53. From the Galaxy menu, select Configure / Security.

You will be presented with the following dialog box since WEng does not have permissions to modify security configuration.

54. Click No to dismiss the dialog box.


New Password: ww


Wonderware Training


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

56. Enter Administrator for the User name.

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

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



Test Operational permissions

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

58. Deploy the SecurityTest_001 object.

59. Open Object Viewer by right-clicking the SecurityTest_001 instance and selecting View in Object Viewer. If you closed Object Viewer before, you can use File / Load Watch List to open the file you saved earlier.


61. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to Security.

62. Add the following SecurityTest_001 attributes to the watch list: Att1_FreeAccess Att2_Operate Att3_SecuredWrite Att4_VerifiedWrite Att5_Tune Att6_Configure Att7_ReadOnly ScanState ScanStateCmd


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

65. To log in to Object Viewer with a different user account, select Change User from the Options menu.

Wonderware Training


66. Enter the user’s credentials in the Change User dialog box.

67. Click the OK button.

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

View the Security Audit Trail

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

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

68. Start the SQL Server Management Studio by selecting Start / All Programs / Microsoft SQL Server 2005 / SQL Server Management Studio.

69. Configure the Connect to Server dialog box as follows:

Server type: Database Engine

Server name: localhost

Authentication: Windows Authentication

70. Click the Connect button to continue.



71. In the Object Explorer (left pane) navigate to localhost / Databases / WWALMDB / Views to get a list of all the database’s Views in the Object Explorer Details (right pane).

Wonderware Training


72. In the Views list (right pane), right-click on the v_EventHistory view and select Open View to display the current list of alarms logged in the database.




Wonderware Training

Module 7

Galaxy MaintenanceSection 1 – Exporting and Importing Objects 7-3

Section 2 – Configuring Instances Through a .CSV File 7-13

Section 3 – System Management Console (SMC) 7-21

Section 4 – Network Account Utility 7-35

7-2 Module 7 – Galaxy Maintenance

Module ObjectivesObtain an overview and understanding of:

Exporting and Importing ObjectsConfiguring Instances Through a .csv File Using Galaxy Dump and LoadUsing the System Management Console to manage platformsUsing the Network Account Utility

Wonderware Training

Section 1 – Exporting and Importing Objects 7-3

Section 1 – Exporting and Importing Objects


Exporting Automation ObjectsUse 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.

Section ObjectiveThis section discusses some fundamental functions dealing with Galaxy Maintenance. Specifically, it illustrates how to Export for future use and how to Import a galaxy created previously.



To export an object

a. Select an object in the Template Toolbox or Application Views pane.

b. From the Galaxy menu, select Export/AutomationObject(s).

Note: You can export more than one object with this function by first multi-selecting objects (Shift+Click or Ctrl+Click). If you want to export all of the objects in the Galaxy, point to Export and then click All AutomationObjects.

Wonderware Training


c. The Export Automation Object(s) dialog box appears.

In the Export Automation Object(s) dialog box, browse to the path and filename (.aaPKG extension) of the export file and click Save. Click Cancel to terminate the export function. If you click Save, a progress box is displayed.



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

Note: Export maintains containment relationships that were previously specified. Also, if an object is currently checked out, the last checked in version of the object's configuration is exported.

Exporting All Automation ObjectsThe Exporting All Automation Objects function is much like the Exporting Automation Objects procedure. The key difference being that with the Export Automation Objects function only the objects that are selected are exported into a .aaPKG file. With the Export All Automation Objects function all of the objects and any derived templates are also exported.

The procedure is as follows:

Use the ArchestrA IDE’s export function to share objects with other users or to recreate them in other Galaxies. The resulting file (.aaPKG extension) contains the selected objects, their associated templates and the configuration state of those objects. The export file can later be imported into the same or another Galaxy.

Subsequent exports retain the default folder as last used for the duration of the ArchestrA IDE session. If the designated file already exists, you are prompted to confirm overwrite.

If any of the selected objects are currently checked out, only the checked in versions are exported.

Exporting an entire Galaxy is similar to using the Galaxy Database Manager utility to back up the database. However the change logs for the objects are not exported while they are saved during backup. Also, the backup process retains security model settings for objects while exporting them does not.

Note: When exporting an object that uses a script function, the script function is not transferred with it. You must ensure that the script function libraries are transferred separately.

Wonderware Training


To export all automation objects

a. From the Galaxy menu, select Export/All Object(s).



b. The Export All Automation Objects dialog box appears.

In the Export AutomationObject(s) dialog box, browse to the path and filename (.aaPKG extension) of the export file and click Save. Click Cancel to terminate the export function. If you click Save, a progress box is displayed.

Wonderware Training


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

One key factor to mention is that the security model settings for objects does NOT get exported when using the Export function. In order to export those you would have to use the Backup process in the Galaxy Database Manager in the System Management Console (SMC) discussed in the next Section of this manual.

Importing Automation ObjectsObjects can be reused from another Galaxy in your Galaxy. This saves time if the objects are already set up in another Galaxy.

Importing instances previously exported from a Galaxy retains previous associations, when possible, such as assignment, containment, derivation, and area.

Objects can be imported from exported .aaPKG files or from an .aaPDF file. An .aaPDF file contains the configuration data and implementation code for one or more base templates. It is created by a developer using the ArchestrA Object Toolkit.

Before starting, you cannot have two objects with the same name or more than one copy of the same version of an object in the same Galaxy. When you import an object, these conflicts are identified and you can manage them.



To import Automation objects

a. On the Galaxy menu, select Import/Object(s).

Wonderware Training


b. The Import AutomationObject(s) dialog box appears.

Browse for the file with either a .aaPKG or a .aaPDF extension. You can select more than one file. Click Open.



c. The Import Preferences dialog box appears.

In the Objects from same toolkit and vendor area, select one of the following:

Skip objects with same conflict or newer codebase leaves the existing object unchanged.

Overwrite objects with name conflicts if their configuration version is higher replaces the existing object with the object being imported if the codebases are the same and the imported object has been edited more often than the existing object.

Migrate objects with a newer codebase also overwrites existing objects if the codebases (versions) are the same. In addition, this option will migrate the state of existing objects to the newly imported version if the object supports it. For more information about migrating, see the Application Server Installation Guide.

In the Objects from different toolkits and/or vendor but with same tagname area, select one of the following:

Skip does not import the object when a name match exists in the Galaxy.

Rename Object in Galaxy renames the existing object by appending to its current name the string (up to four characters) you type in the Append to Object Name box. The default value is _old but you can change it to any four- character string.

Rename Importing Object renames the object being imported by appending to its current name the string (up to four characters) you type in the Append to Object Name box. The default value is _new, but you can change it to any four-character string.

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

Click OK to start the import process.

When the import process is complete, you can start using the objects you imported.

Wonderware Training


Section 2 – Configuring Instances Through a .CSV File


Galaxy DumpObject instances and their configuration data can be exported to a comma-delimited format Galaxy dump file (.csv extension).

The Galaxy Dump function only dumps instances. Templates cannot be dumped. The .csv file contains the configuration for the checked in versions of the selected objects as well as the checked-out objects of the user who initiates the Galaxy dump. The file contains only those attributes that are unlocked and configuration time-writeable, one column per attribute. Attributes that are locked, calculated or runtime writeable only are not saved to the file. Attributes that are not text based (for example, type QualifiedStruct) are not dumped. Object Help files are not dumped.

To export objects to a Galaxy dump file:

a. Select an object in the Application Views pane. You can export more than one instance with this function by first multi-selecting objects (Shift+Click). Also, you can dump all instances derived from a template by selecting just the template.

Section ObjectiveThis section discusses some fundamental functions dealing with Galaxy Maintenance. Specifically, it illustrates how to Export a galaxy for future use and how to Import a galaxy created previously.



b. Select Export on the Galaxy menu and then click Galaxy Dump.

The Galaxy Dump dialog box is displayed.

c. Browse to the name and location of the .csv file to which you want to dump the selected instances. Click Save to continue or Cancel to end the export function. The Galaxy Dump progress box is displayed.

Wonderware Training


d. After the Galaxy dump process is finished, click Close. A .csv file has been created containing the selected objects and configuration data.

The actual .csv file has been created.



Galaxy Dump File (.csv) Structure Dumped objects are organized in the resulting .csv file based on the template from which each is derived. A header row per template indicates the instance’s columns’ reference. Comments can be added in the resulting .csv file by adding a line preceded by a semi-colon.

Note: Carriage returns in scripts associated with dumped objects are replaced with “\n” in the .csv file. If you edit the dump file, do not delete the “\n” characters. If you edit scripts in the dump file, use “\n” for a carriage return. This character set is interpreted as a carriage return when the dump file is used in a Galaxy Load function. When editing a script in a dump file, use “\\n” if you want to include the character “\” followed by the character “n” in a script. This character set is not converted to a carriage return in a Galaxy Load function.

Wonderware Training


Galaxy LoadObject instances and their configuration data in an existing Galaxy can be exported to a comma-delimited format Galaxy dump file (.csv extension). A .csv file can be edited in most text editors and spreadsheet programs. Using editing functions like copy and paste, you can create quantities of already-configured objects ready to be imported into your Galaxy.

Note: The contents of the .csv file is determined by the original Galaxy dump. A load file contains only instances. Templates cannot be dumped and loaded.

Important: The Dump contains only Object Instances. For the Load to succeed, the templates from which those objects were derived must already exist in the Galaxy.

To import a .csv file

a. Select Import on the Galaxy menu and then click Galaxy Load.

The Galaxy Load dialog box is displayed.



b. In the Galaxy Load dialog box, browse to locate the .csv file that contains the objects and configuration data you want to import.

Select the file and click Open to continue or Cancel to end the import function.

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

Replace entire instance if an instance of an object with the same name already exists and you want to replace it entirely with the object in the import file.Only update changed attributes if an instance with the same name already exists and you want to replace only the attributes of the object where the values are different.Skip if an instance with the same name already exists and you want to keep the version already in the Galaxy. Stop Galaxy Load if an instance with the same name already exists and you want to cancel the Galaxy Load.

c. Choose the preferred conflict resolution and click OK. A progress box is displayed during the Galaxy load process. Click Cancel to terminate the Galaxy load process.

A Galaxy Load dialog box appears indicating that the Load was successful.

All objects that were changed or created during the Galaxy Load process are checked out to the logged in user.

Note: A comment line in a .csv file created in Microsoft® Excel may create an unintended default-value object. To avoid this scenario, open the .csv file in Notepad to ensure the comment line does not contain quote marks.




Wonderware Training


Section 3 – System Management Console (SMC)

This section provides an understanding of role of the System Management Console and how it can be configured.

About System Management ConsoleThe System Management Console (SMC) provides ArchestrA Application Server application diagnostics by allowing you to view the run-time status of some system objects and to perform actions upon those objects. Actions include setting platforms and engines in an executable or idle mode and starting and stopping platforms and engines.

The System Management Console is used to assist system integrators and system administrators in performing administrative tasks and diagnostics on an ArchestrA application. It provides application infrastructure diagnostics by allowing the viewing of runtime status of some system objects and the ability to perform actions upon those objects. Actions include setting Platforms and Engines in an executable or idle mode and starting and stopping Platforms and Engines.

This tool is one in a series of administrative tools that can be used for diagnostic purposes on ArchestrA applications. Another tool available for performing diagnostics on applications is the Visual Local Message Exchange (VLMX) Test Tool, which allows viewing and modifying of attributes of AutomationObjects. Because the Platform Manager is a Microsoft Management Console (MMC) Snap-in, its interface is integrated into the MMC environment and it appears as a single interface.

Features of the System Management Console Some of the key features of the Platform Manager are that it:

Runs with minimal ArchestrA and operating system requirements, equivalent to "Safe mode" Uses the local platform as the gateway to the ArchestrA application Does not rely on the Galaxy Repository to exist Allows viewing of the layout of the Galaxy Repository, Platforms, and Engines Provides the ability to set Platforms and Engines OnScan or OffScan Provides the ability to start and stop Platforms and Engines

Section ObjectivesEffectively utilize the System Management ConsoleConfigure the System Management Console



To Start the System Management ConsoleStart Windows and click Start. Select All Programs/Wonderware/System Management Console.

The Platform Manager appears under the ArchestrA System Management Console (SMC) root node.

Wonderware Training


If the Galaxy has security enabled, the Platform Manager Login dialog box appears when the user attempts to access the Platform Manager from the System Management Console (SMC).

Console TreeThe console tree has a Windows Explorer-type hierarchical structure layout, with the ArchestrA System Management Console appearing as the root node and the SMC snap-ins appearing below this node. Like Windows Explorer, the console tree can be expanded or collapsed by clicking on the "+" or the "-" symbols that appear next to the snap-in.

The console tree shows the items that are available in the console. The snap-ins that appear below the ArchestrA SMC node will depend upon the software installed:

Galaxy Database Manager (GR Node only)DAServer Manager (DAServer or WinPlatform deployed)Log Viewer (all Wonderware nodes)Platform Manager (all Application Server nodes)Other snap-ins (for example IndustrialSQL Server) will be available when other Wonderware software is installed

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

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

Galaxy Database ManagerSelecting the Galaxy Database Manager on the SMC Menu allows you to view all the galaxies in the Galaxy Repository, as well as the nodes they reside on.

You must have Administrative privileges to use the Galaxy Database Manager.



Galaxy Backup / RestoreBe sure to back up your Galaxies so that if a Galaxy becomes corrupted, you can restore the Galaxy. You can choose a backup file to overwrite an existing, corrupted Galaxy or to reproduce a Galaxy in another Galaxy Repository.

The Galaxy Database Manager is automatically installed on every Galaxy Repository node.

Backup

When running a Galaxy backup, no other applications may write to the GR node. Be sure to perform the backup operation when no database-write operations will occur.

a. Select the Galaxy to backup, and select Action / Backup.

b. Name the .cab file to be created, and click Save.

c. Click Close when the backup is complete.

Create a new galaxy with a galaxy backup (.cab) file

Wonderware Training


You may also create a new galaxy using the .cab file created when a Galaxy backup is performed. You must first copy the backup .cab file to:

C:\Program Files\ArchestrA\Framework\Bin\BackupGalaxies

In the New Galaxy window, create a new galaxy and select your backup Galaxy in the Galaxy type field.

Restore

When you restore a database from backup, any information saved to the database since the backup was performed is overwritten with the restored information. All changes to the database since the backup are lost. Also, any transactions in progress when the backup was performed are rolled back.

a. On the Action menu, click Restore.

b. Click Yes to continue restoring and No to terminate the restore function.



c. Select the name(.cab extension) of the backup file you want to use and click Restore.

If you have an active client connected to the Galaxy Repository, a message appears. You are required to quit those client programs before restore can continue.

A confirmation dialog box displays when the restore function is finished.

DAServer ManagerThe DAServer Manager allows local or remote configuration of the DA Server and its device groups and items, and can monitor and perform diagnostics on DAServer communication with PLCs and other devices.

Like the LogViewer and Platform Manager, the DAServer Manager is a Microsoft Management Console (MMC) snap-in. Many high-level functions and user-interface elements of the DAServer Manager are universal to all DAServers; to understand the DAServer Manager, it is critical to read the documentation for both the MMC and the DAServer Manager.

To read the documentation about the MMC and DAServer Manager, click the Help topics on the SMC Help menu. Both the MMC Help and the DAServer Manager Help are displayed.

Log ViewerThe ArchestrA Logger is a utility that records information regarding the activity occurring on the computer. For example, it records start-up data, error conditions, and DAServer information.

The Log Viewer can:Monitor messages on any machine in the systemSend a portion of the log to notepad or E-mailFilter messages on a flag

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

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

Wonderware Training


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.

These commands are also available by right-clicking an item in either the console tree or the details pane. The available commands are dependent on the current state of the object and your security permissions. If you do not have permission to perform a particular command, then that command is grayed out.

Command Description Configure Allows configuration of the Log Viewer and StorageLog Flags Opens the Log Flag editorOpen Log File Allows the opening of a Log FileConnect Allows either local or remote connections configurationMessages Allows Messages to be exported, purged, or printedRefresh Refreshed the databaseHelp Access to the System Management Console Help files



The following commands are available from the Platform Manager Action menu when you select Log Viewer in either the console tree or the details pane.

Command Description Monitor System messages provide information about the state of the

IndustrialSQL Server historian as it starts up, runs, or shuts down. For more information about system messages, see System Messages.

Open Log File Use this dialog box to locate and open a log file of saved messages.Connect Allows the opening of a Log FileAbout Log Viewer Displays copyright and version informationNew Create a new log file.Refresh Update the contents of the Log File window.Export List You can export the currently shown log messages to a log file. Log files

have an .aaLGX extension. The default file name is LogExport with the current date in the format (mmddyyyy) appended as a suffix. You can edit the name of a log file but not its extension.

Help Access to the System Management Console Help files

Wonderware Training


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.

The Logger and Log Viewer are automatically installed when an ArchestrA component is installed.Logger - This is the background process that stores messages and events in the system. This process occurs without any prompting from or interaction necessary from the user. The logging process can be customized with the LogFlag Editor Snap-In utility. The Logger is installed as a system service, and can be configured to be an Auto Service or Manual Service. As an Auto Service utility, the Logger is started when the PC is booted up. As a Manual Service utility, the Logger requires a manual start through the System Services utility in Windows’ Control Panel. In either case, the logging process is always started when an ArchestrA component begins functioning.Log Viewer - This utility is used to view error and informational messages that are sent by ArchestrA components. The look-and-feel and the format of the user interface can be customized to suit individual needs.

Command Description Filter Allows filtering of Messages, Time Range, or Terminal SessionsFind Search capability on Process ID, Thread ID, Log Flag, Component, or

MessageGo To Allows redirection to a Bookmarked locationBookmarks Allows Adding or removing of a BookmarkMark Allows the entry of a Marker Message to the logChoose Columns Select specific columns to show or hideCustomize Change the appearance of the view



Typical Log Viewer UsageThe Log Viewer is primarily a troubleshooting tool. After initially installing an ArchestrA-enabled program and on occasion, you might check logged messages to determine whether all processes are functioning well. But typically, you would use the Log Viewer to work through problems you encounter with a DAServer, the ArchestrA IDE or other ArchestrA component.

Note: The Log Viewer displays error messages in red-highlighted stripes. These indicate malfunctioning processes and should be resolved quickly. Warning messages are displayed in yellow stripes. These indicate major events in the system.

A good strategy for troubleshooting problems

a. Gather as much information first about the process that is malfunctioning. For instance, you attempted to deploy an object in the ArchestrA IDE and a message was displayed stating the deployment was not completed. Note the function you attempted and the message you received.

b. Open the Log Viewer by clicking Start, pointing to Programs and then to Wonderware, and then clicking System Management Console. In the SMC, select Log Viewer and then the node the ArchestrA IDE is located on. Look for red and yellow messages. Also, use the information you collected about the failed process to search for clues in the logged messages.

c. Use the Find command on the View menu to single out messages by message text or other category of data, or use the Filter command on the View menu to reduce the number of displayed messages based on message, time range or terminal session criteria.

The journey of a Log Message originates with the Application where Log Flags are generated. These are passed to the Logger where they are then stored in the Log Message Storage. They are then available for viewing by the LogFlag Viewer. The LogFlag Editor provides the capability to edit the LogFlags. This is illustrated in the following diagram.

LogFlag ViewerLogFlag Editor

1

23

4

5

6

Wonderware Training


Using BookmarksBookmarks are unique labels you can apply to individual messages for quick access. They differ from marks in that bookmarks are associated with specific messages while marks are messages added below the message that is currently last in the log.

You cannot enter duplicate bookmark names for more than one message, and a message can have only one bookmark.

The message window can display a Bookmark column, which is initially hidden by default. To show the Bookmark column, right-click on the column header of the message window and click Show. In the Choose Columns dialog box, click Bookmarks in the Columns Hidden box, click the Show button to move it to the Columns Shown box and click OK. The Bookmark column is added at the far right of the column header. Click and drag it to another position if you want. When the text of a bookmark in the Bookmark column is partially obscured, point to it to display the entire bookmark like a tool tip.

You can set bookmarks in two ways: adding a regular bookmark that you can name and setting a fast bookmark that is named for you.

To add a regular bookmark to a messagea. Right-click the message and click Add Bookmark on the Bookmark submenu.

b. In the Add Bookmark dialog box, either accept the default name (Bookmarkx where x is a number in an ascending sequence) or overwrite it with something more descriptive. You can change the bookmark name in the Bookmarks dialog box at a later time. See "To manage bookmarks" below.

c. Click OK to set the bookmark or Cancel to terminate the process.

To set a fast bookmark on a messagea. Right-click the message and click Fast Bookmark on the Bookmark submenu. A default

naming sequence is applied to the message (Bookmarkx where x is a number in an ascending sequence). Alternatively, you can set a fast bookmark by selecting the message and clicking the Fast Bookmark icon on the toolbar.

b. Change the bookmark name to something more descriptive, if necessary, in the Bookmarks dialog box at a later time. See "To manage bookmarks" below.

To go to a bookmarked messagea. On the View menu, click Go To.

b. In the Go To dialog box, enter the name of the message’s bookmark by typing it in the box or selecting from the list.

c. Click Go To. The Go To dialog box remains open.

d. Use the Previous and Next buttons to go to the nearest bookmarked message above and below, respectively.

e. When you are done searching, click Close.

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



To manage bookmarksa. On the View menu, click Bookmarks.

b. In the Bookmarks dialog box, you can manage current bookmarks and create new ones. The bookmark list shows the current set of bookmark names and associated Message No. (the same number as the No. column in the message window). The bookmark list provides several functions.

c. For instance, to rename a bookmark, select it, press F2 and type the new name. Note that each bookmark must have a unique name; so you cannot bookmark two messages with the same name.

d. To go to a bookmarked message, double-click on it in the list or select it and click Go To.

e. To remove one or all bookmarks from your logged messages, select a message and click Remove, or click Remove All.

f. To add a new bookmark, select the message you want to bookmark in the message window and click Add. This function is comparable to a fast bookmark. Rename it by pressing F2.

g. When you are done, click Close.

Note: Bookmarks are not saved when you quit the Log Viewer application. To mark your message log more permanently, use the Mark command on the View menu.

Platform Manager Platform Manager is a common component of an Application Server application and it is available from any PC node in the application that has a deployed platform; therefore, you do not need to install it onto each node. This ensures that all nodes used within a galaxy have access to Platform Manager.

When you use Platform Manager, you can access the platforms and engines deployed to the local PC node and to any other PC node in the Galaxy. Platform Manager does not require the GalaxyRepository to be installed on the PC node.

After highlighting a Galaxy or an Engine, you can use the Action menu to start or stop the object, or set it OnScan/OffScan. If the galaxy has security implemented, you must log on as a user configured with the proper SMC permissions to start SMC, Start/Stop engines and platforms, or write from the Object Viewer.

Wonderware Training


Console Menu Commands The following commands are available from the Platform Manager Action menu when you select a Platform in either the console tree or the details pane.

The following commands are available from the Platform Manager Action menu when you select an Engine in either the console tree or the details pane.

These commands are also available by right-clicking an item in either the console tree or the details pane. The available commands are dependant on the current state of the object and your security permissions. If you do not have permission to perform a particular command, then that command is grayed out.




Wonderware Training


Section 4 – Network Account Utility

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 UtilityThe Change Network Account utility is a tool you can use to manage credentials for node-to-node communications between ArchestrA components.

During the initial installation of an ArchestrA component, you are prompted either to create a new user account or to use an already existing account, and provide a user name and password for that account. The same account must be used on each computer that requires communication with others in the ArchestrA environment. Use the Change Network Account utility to change this data, if necessary, on any computer after installation of an ArchestrA component.

WARNING! If you change user account data with this utility, you could adversely affect communications between the computer and others with installed ArchestrA components (including existing Wonderware products that are ArchestrA enabled). All ArchestrA nodes that require communication with others must use the same account, user name, and password. Use this utility only to standardize user account data on all computers requiring communication. Do not delete this account with operating system account management tools. If you do, the ArchestrA IDE will stop functioning properly. If you delete the ArchestrA user account on an ArchestrA IDE node, you must recreate it with the Change Network Account utility.

Node-to-Node Communications All computers that have installed ArchestrA-enabled software must be able to communicate with each other. This communication is enabled through an ArchestrA-specific user account set up during the initial installation of an ArchestrA component on each computer. Subsequent installations of ArchestrA components do not prompt for user account information. They automatically use the account set up during the installation of the initial component.

The user account described in this document only enables node-to-node communications between ArchestrA components. It is not associated with ArchestrA security, which provides user authentication for individual access points to the infrastructure.

Note: You must have Administrator privileges on the computer to make changes with the Change Network Account utility.

Section ObjectivesThis section discusses the role of changing the network account and how to use the Change Network Account Utility to accomplish that task. After discussing this section you will be able to:

Understand the role of the Change Network Account Utility, and;Have an understanding of how it can be configured.



To recreate an ArchestrA user account a. Start the Change Network Account utility by selecting Start/All Programs/Wonderware/

Common/Change Network Account.

The Change Network Account dialog box appears.

Wonderware Training


The data shown in this dialog box are those settings entered during the initial installation of an ArchestrA component on the computer. The password options are shown blank for security reasons.

The Change Network Account utility allows you to change the current data shown in the dialog box, including:

Changing the password of the current account.Creating a new local user account.Using an existing local machine or network domain account.

b. In a single-node ArchestrA system, create any account.

c. In a multi-node ArchestrA system, recreate the same user account with the same user name and password that was created on all other computers that have installed ArchestrA-enabled software.

d. Once you have configured the account, click OK.

Note: After you recreate the user account in the Change Network Account dialog box, the Microsoft Windows security component on your computer may take several minutes to update this information on the ArchestrA Galaxy node. Until that occurs, your ArchestrA IDE may not function properly. Rebooting the Galaxy node causes this update to occur immediately.

When you use the Change Network Account utility to create or use an account that is different from the one originally set up during installation, the old account is maintained (not deleted).

WARNING! After you change any data shown in the Change Network Account dialog box, ensure that all other computers that have installed ArchestrA-enabled software use the same type of user account with the same user name and password.



Error Messages When using the Change Network Account utility, you may encounter the following error messages.

Error Message Action Required Administrative privileges are required to run this utility.

You must have Administrator privileges on the computer to run this utility. Click OK, login as a user with Administrator rights, and start the Change Network Account utility again.

The Password was not correctly confirmed. Please ensure that the Password and Confirmation match exactly.

You mistyped either the password or confirmation password in the dialog box. These two passwords must match to ensure the accuracy of user account data. Click OK, retype both password and confirmation password text, and then click OK again.

Password cannot be empty. Please enter a valid password

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 Confirm Password box, and then click OK again.

User account 'a' already exists. Please enter another user name.

You chose to create a local account by selecting Create Local Account in the Change Network Account utility. This account already exists. Click OK, type a new user name in the Change Network Account utility, and click OK.

Domain/Local Machine name 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 exist. Please enter another user name.

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 Domain/Local Machine Name box is valid and the user name and password you typed are valid for that user account, and then click OK. If this message is displayed again, check with your network administrator about the existence of the account.

The password policy for this account allows the password to expire and to be changed. However the password must not expire or should not be changed for the ArchestrA products to function properly. Do you want to 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 account's 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 Domain name 'dom'. Please enter a valid domain name.

You typed an invalid network domain name in the Domain/Local Machine Name box. Click OK, retype the domain name, and click OK.

Invalid Password for user account 'a'. Please enter the correct password.

You chose to use a network domain user account, but the password you typed does not match the account's password. Click OK, correct the password, confirm the password, and click OK.

Wonderware Training


Multiple NIC Computers Any node in your Galaxy that contains more than one network card must be configured according to the following instructions to ensure communications with other ArchestrA nodes.

Note: If a multiple NIC computer in your Galaxy uses only one NIC, you should disable all cards except the supervisory network.

For any multiple NIC ArchestrA node to communicate successfully with all other Galaxy nodes, you must define the correct order of network connections in the network services of the computer. In the Network Connections dialog box (see image below) you may choose to rename each card with a clearly identifiable function (for instance, “Supervisory Net” and “PLC net”). Different operating systems provide unique access to the Network Connections dialog box.

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

The system will now reboot. Please close all your open applications and press "OK" when you are done.

You changed account information in the Change Network Account utility. The computer must be restarted to implement those changes. Close open applications, and click OK.

User name cannot contain these characters: " / \\ [ ] : ; | , + * ? < > 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 [.] 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 OK again.

Error Message Action Required



Several other parameters must be configured to ensure successful node-to-node communications in the ArchestrA environment. You must configure the IP address and DNS settings according to your network setup.

Wonderware Training

Module 8

Device Integration ProductsSection 1 – Wonderware I/O Servers 8-3

Section 2 – Wonderware Data Access Servers 8-9

Section 3 – Device Integration Objects 8-13

8-2 Module 8 – Device Integration Products


DAServers and DI Objects and how they relate to the connectivity of your application to external data.FactorySuite Gateway and how it can enhance the connectivity of your application.

Wonderware Training

Section 1 – Wonderware I/O Servers 8-3

Section 1 – Wonderware I/O Servers

This section will describe the configuration of a Wonderware I/O Server (Modbus).

IntroductionWonderware I/O Servers are Microsoft Windows application programs that enable other DDE-aware Windows applications (such as InTouch or Excel) access to data in the real world (such as PLCs or RTUs).

Wonderware servers are primarily intended for use with Wonderware's InTouch program; however, they can be used by any Microsoft Windows program capable of acting as a DDE client.

In this section, we will examine the start-up, configuration and use of a Wonderware I/O Server. Because Wonderware's I/O servers are Windows applications, they will all have the same basic appearance and capabilities. Keep in mind that depending on server requirements, additional hardware (network, and so on) may be necessary and the configuration screens may require additional information.

The following information references the Modbus I/O Server as a point-to-point server using the RS-232 serial port to PLCs provided at the Wonderware facility training environment. Your instructor may have you configure the following screens differently.

Note: All I/O Server setup which follows is specific to the Wonderware facility training environment. Your instructor will provide the proper configuration information. It accesses one Koyo DirectLogic O5 PLC via its programming port.

Configuring I/O ServersOnce the I/O Server has been installed, some configuration is required. Configuring the server automatically creates a configuration file named MODBUSDV.CFG. This file stores the configuration information about communication ports and all of the topic definitions (described in detail later).

The configuration file is automatically saved to the directory in which the I/O Server is installed unless a different directory is specified via the Configure / I/O Server Settings command.

a. Select Start / All Programs / Wonderware / IOServers / Modicon MODBUS.

The MODBUS dialog box appears:

b. Click Configure / Com Port Settings.

Section ObjectiveConfigure a Wonderware I/O Server (Modbus)



The Communication Port Settings dialog box appears. This dialog is used to configure the communication port that will be used to communicate with the PLC equipment.

Com Port: Select the communication port that is connected to the PLC equipment.

Reply Timeout: Enter the amount of time (in seconds) that all PLCs connected via this serial communications port will be given to reply to commands from the I/O Server.

Note: This timeout is sustained only when the PLC fails to respond. When the PLC is responding normally, there is no penalty. The default value of 3 seconds should be sufficient for most configurations.

Protocol area: Select the protocol configured for the equipment attached to this communication port. RTU is recommended.

Baud Rate area: Select the baud rate (serial bit rate) setting that matches the equipment connected to this communication port.

Data Bits area: Select the option for the number of data bits that corresponds to the configuration of the equipment on this communication port.

If ASCII is selected for the protocol, use 7. If RTU is selected, use 8.

Stop Bits area: Select the appropriate number of stop bits for the communication port. If the baud rate is greater than 300, the stop bits should be set to 1.

Parity area: Select the setting that corresponds to the configuration of the equipment on this communication port.

Note: All devices on a single communication port must be configured with the same Protocol, Parity, Stop Bits, Data Bits and Baud Rate.

Wonderware Training


For this training class, the following settings must be configured as shown.

c. Save your changes in the suggested directory and click Done to exit.

Note: Click Save to save the current settings entered for the selected communication port. The Communication Port Settings dialog box remains displayed and another communication port can be configured.



Creating Topic DefinitionsThe Configure / Topic Definition command is used to create, modify, or delete topic definitions. One or more topic definitions must exist for each PLC that the I/O Server will communicate with.

Each topic definition must contain a unique name for the PLC associated with it. This unique name is then used as the topic name portion of the DDE Address for all DDE conversations to that PLC.

a. Click Configure / Topic Definition.

The Topic Definition dialog box appears:

Note: Once topics have been defined, their names will be listed in the Topics pane of this dialog box.

b. Click New to add a new topic definition.

The MODBUS Topic Definition dialog box appears:

c. Topic Name: Enter a unique name (up to 32-characters long) for the PLC in the field.

Note: When communicating with InTouch, this exact name is used as the topic name in the Access Name definition.

d. ComPort: Select the communications port to be associated with this topic.

Wonderware Training


e. Slave ID: Enter the Slave ID of the PLC in the box.

f. Slave Device Type: Drop-down list contains slave device types other than the default.

g. String Variable Style: The PLC will use this style to store ASCII strings in its registers.

h. Register Type: Select BINARY or BCD, based on hardware used.

i. Block I/O Sizes: Coil Read: Enter the maximum number of consecutive coils to be read at one time. In this example, the valid coil read values can be between 8 and 2000 and must be an even multiple of 8.

j. Coil Write: Enter the maximum number of consecutive coils that can be written to at one time. In this example, the valid coil write values can be between 8 and 800 and must be an even multiple of 8.

k. Register Read: Enter the maximum number of consecutive registers to be read at one time. In this example, the valid register read values can be between 1 and 125.

l. Register Write: Enter the maximum number of consecutive registers that can be written to at one time. In this example, the valid register write values can be between 1 and 100.

m. Update Interval: Enter the frequency (in milliseconds) that the I/O Server will read (poll) the items/points associated with this topic. Different items/points can be polled at different rates by defining multiple topic names for the same PLC and setting different update rates for each topic.

n. Click OK to accept the entries and close the dialog box.

The Topic Definition dialog box will open with the new topic listed:

o. Click the Done button to close this dialog box and return to the server's program window.

p. Click Modify to change an existing topic definition.

q. Click Delete to delete an existing topic definition.

Note: The previous information is provided for example only. Configuration steps for this class are provided in the following lab.




Wonderware Training


Section 2 – Wonderware Data Access Servers

This section provides familiarization with Wonderware Data Access Server and its use with Application Server.

IntroductionWonderware Data Access (DA) Server is designed to provide simultaneous connectivity between client applications based on Wonderware SuiteLink, OPC and DDE protocols that run on the Microsoft Windows operating system and the data devices supported by the specific protocol being translated.

The Wonderware DAServers also come with an exclusive new user interface called the DAServer Manager, which is installed as a Microsoft Management Console snap-in. Its end-user benefits include simple remote server activation, configuration and operation, and extensive protocol diagnostic troubleshooting.

Several standard features are available with each DAServer, including:Compliance with OPC version 3.0 Stand-alone operation mode Support for hot configuration, device additions and device- and server-specific parameter modifications

A wide range of DAServers support connectivity to numerous protocols and products. A few of the current DAServers Wonderware includes support for are:

Allen-Bradley CIP protocol for ControlLogix Allen-Bradley TCP protocol Allen-Bradley DH Plus protocol Siemens Simatic Net S7 Modbus Serial protocol

Component ArchitectureA DAServer is comprised of three physical parts:

Plug-in Component(s): responsible for communicating with clients, used by all DAServers. Plug-ins provide protocol translation functionality for device integration clients.

Typical Plug-ins use DDE, SuiteLink or OPC protocol, and serve as interfaces between their clients and the DAS Engine. A protocol can be disabled when customizing the installation for your DAServer.DAS Engine: common component used by all DAServers.

The DAS Engine is a middleware component that exposes two sets of unique interfaces, one for communicating with Plug-ins and one for communicating with Device Protocol Layer components. It encapsulates common tasks for the DAServer, like handling the item database, distributing data to clients, propagating clients' requests to the protocol, and providing diagnostics.

Section ObjectiveBecome familiar with Wonderware Data Access Server and its use with Wonderware Application Server.



Device Protocol Layer: Server specific, responsible for communicating with hardware and specific to the DAServer. The Device Protocol Layer provides translation between the hardware- specific protocol such as ModBus and CIP and the DAS Engine interface:

Each physical part of a DAServer is comprised of a set of .EXE and/or .DLL modules. ArchestrA provides the Plug-in and DAS Engine modules.

You must create the Device Protocol Layer (server specific) modules with the DAServer Toolkit, and all three sets of modules are required for a fully functioning DAServer.

DAServer Characteristics

ConfigurationThe DAServer Manager is capable of displaying specific configuration pages for all servers. This utility allows browsing and editing of servers on different nodes.

Recall that DAServers are hot-configurable. In other words, they are configurable while the server is running or even acquiring data. Certain restrictions imposed by the underlying network/protocol/hardware might apply.

For instance, if you uncheck System Items on the global parameters configuration dialog of the DAServer Manager and select Apply, and then re-check System Items and Apply, System Items data is valid only to newly connected clients.

The configuration data format for DAServers is XML. Any XML-enabled program (for example, IE and XML Notepad) can read this format.

RuntimeThe DAS Engine is loaded by the DAServer as an in-process COM object.

It is not statically linked. In other words, a new DAS Engine (feature enhancement or bug fix) would not require re-linking to the other components nor re-QA of those other components. It is deployed to the system and attaches to all existing server components.

Wonderware Training


This is an important added value for the customer to be independent of ArchestrA release cycles, especially for OEM customers with their own release schedule.

Newly deployed Plug-ins do not require re-linking nor re-QA of associated components. Even new Plug-ins would not require any development effort for the other components. In fact, it is feasible to implement new functionality (like Store-and-Forward) in a Plug-in to enhance the server without involvement of the code of the other components.

DiagnosticsThe DAServer Manager diagnostic tool displays generic diagnostic objects common to all servers as well as server-specific/server developer defined diagnostic data.

Hot ConfigurationOne of the big advantages provided by the DAServer is the ability to make your DAServer configurable while the server is running - hot configuration.

The extent to which a specific DAServer is hot configurable varies from server to server. You can choose from a variety of hot configuration responses, from not being hot configurable at all to being configurable of each individual parameter while the server is running.

The DAServer handles most of the hot configuration work. In general, a user will run the DAServer Manager and configure each hierarchy. Any changes she makes that add/delete/update a hierarchy are sent immediately to the running DAServer.

Server-specific code may elect to react to the change. Some parameters cannot be changed while the DAServer is running due to protocol-specific issues, and these can be ignored by the server-specific code.

Here is a complete list of notifications to the server about changes in the configuration:Add configuration hierarchy.Delete configuration hierarchy.Rename configuration hierarchy.Update parameters of configuration hierarchy.Add device group.Delete device group.Rename device group.Update parameters of device group.Clear the current configuration set.Switch to a new configuration set.



Integration to Third Party ApplicationsFactorySuite Gateway (FS Gateway) is a universal translator, capable of translating all major protocols (MX, OPC, DDE, SuiteLink) to any protocol required by a network component.

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

One of the functions of the FS Gateway is to translate between ArchestrA MX protocol and other protocols. For instance, a Wonderware Application Server, which uses MX, previously could not be accessed by third-party clients except through InTouch. Excel, Visual Basic, and other third-party applications were unable to receive data from Wonderware products without using InTouch tags. Using FS Gateway as a protocol translator allows direct connection to a Wonderware Application Server. FS Gateway can replace OPCLink, which translates OPC to DDE or SuiteLink.

FS Gateway is also useful for legacy servers, controllers, and operating systems. Gateway can translate older DDE to the newer SuiteLink protocol, enabling legacy products to connect to newer systems.

Wonderware Training


Section 3 – Device Integration Objects

This section provides familiarization with DI Objects and their use with Wonderware Application Server.

IntroductionDevice Integration (DI) Objects represent the application's network and devices, and mirror the actual device hierarchy. In Application Server, Device Integration (DI) Objects are a subset of Automation Objects available in the Template Toolset of the ArchestrA IDE. As a subset of these Automation Objects, Device Integration Objects consist of two parts:

DI Network Object, which represents the communications port and are thus associated with DA Servers. DI Device Object, which represents the physical devices that make up a network. Examples of DI Device Objects are network bridge devices or PLCs. When the objects are deployed, they represent the network hierarchy. Each level of this hierarchy can be monitored for its individual status.

Device Integration objects are used to represent communications channels and field controllers. As such, they are most often arranged in a hierarchy that models the physical hierarchy of the network and devices on that network.

Device Integration objects are designed to make it very easy to integrate DAServers into the ArchestrA environment.

Therefore, deploying a DI Network actually deploys the DAServer and its associated components within the ArchestrA IDE/Galaxy. This facilitates the DAServer installation process for end-users.

Several DI Objects are delivered and installed by default with your Application Server software. There are also several DI objects available that are for specific DA Servers. These are available on the Wonderware Device Integration DVD.

DI Object AdvantagesDevice Integration Objects (DI Objects) represent communication with external devices. DI Objects may be DINetwork Objects (for example, the Redundant DI Object) or DI Device Objects. DI Objects (and their associated AppEngine) can reside on any I/O, DA, or Automation Object Server node in the Galaxy. DI Objects allow connectivity to data sources such as DDE servers, SuiteLink servers, OPC servers, and existing InTouch applications.

The advantages of using DI Objects are as follows:DI objects allow you to configure, deploy, and monitor DAServers from one centralized location.DI Objects can be used to represent all devices and PLCs in a network, enabling representation of an entire plant, including a hierarchical view of network connectivity.DI objects are so closely tied to the DAServer that when an object is deployed across the network, it remotely installs the DAServer (This means that you can install the DAServer without going to the actual machine, and that the DAServer connects immediately.).

Section ObjectiveBecome more familiar with DI Objects and their use with Wonderware Application Server.



DI objects are very closely tied to the DAServer they are assigned to, so that when an object is deployed, it brings with it all code, including registry, scripting, attributes, and parent.

Note that in a large project, this process may take some time. However, tremendous savings are achieved when comparing centralized deployment with individual tasks should the Servers be separately installed and configured on each node.

DI Objects in the ArchestrA IDEDI objects are located in the Template Toolbox and can also be imported into the Galaxy in the same way as Application Objects. They are imported directly into the Device Integration area of the Template Toolbox:

Scan On Demand Advanced Communication Management minimizes network traffic and CPU usage of a DIObject or DAServer. While the client application is running, scanning for an attribute value is suspended when the owning object no longer appears in the running application. For example, Advanced Communication Management suspends scanning for an object's attribute value when the operator minimizes the application window containing the object. When the operator shows the window containing the object again, Advanced Communication Management resumes scanning and the object's attribute value is updated in the application.

Scanning can be configured using the following options:

ActiveItems are deleted and added to the scan group as requested (referenced) by the clients.Items that exist when a scan mode change occurs are not deleted unless the previous mode was ActiveAll and the items are no longer referenced.The Active scan mode polls all points that are referenced, whether active or inactive.In Active scan mode an attribute is always in the active state. When the last reference to the attribute is unregistered/unadvised, the attribute is deleted.

ActiveAllScanning is continuous and dynamic attributes are never removed when unsubscribed. Items are activated by client requests, but continue to exist even after the client are not interested in them anymore.Items are not removed when the scan mode changes.The scan group polls the field device for all points irrespective of whether they are currently active, inactive, or even subscribed to by items.

ActiveOnDemandWhen the scan mode is configured as ActiveOnDemand, attributes that are not actively being referenced by any client or object are made Inactive and are not scanned.New Items are deleted and added to the scan group as requested (referenced) by clients.

Wonderware Training


Items that exist when a scan mode change occurs are not deleted unless the previous mode was ActiveAll and the items are no longer referenced.ActiveOnDemand scan mode polls the field device for currently active items only. Inactive items are not scanned.




Wonderware Training

Module 9

Multi-Node ApplicationsSection 1 – Application Redundancy 9-3

Lab 18 – Configuring Application Redundancy 9-15

Section 2 – DI Redundancy 9-29

Lab 19 – Configuring the Redundant DI Object 9-33

Section 3 – Multi Node Application 9-45

Lab 20 – Convert to Network Environment 9-49

9-2 Module 9 – Multi-Node Applications


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.

Wonderware Training

Section 1 – Application Redundancy 9-3

Section 1 – Application Redundancy


Redundant ConfigurationRedundancy is important in processes that rely on continuous availability of information. There are two basic types or topologies of redundant configuration:

Redundant Application EnginesRedundant DI Objects

Section ObjectiveThis section covers the concept of redundancy, how it can be configured and key points to more effectively implement this feature.Understand the concept and functionality of Redundant DI Objects



Redundant Application EnginesThe purpose of Application Engine Redundancy is to ensure continuous operation by providing an engine that remains active in the event of a single system component failure. It operates on the principal that with redundant engines, one engine is in an Active Role while the other is in a Standby Role waiting to take control.

The hardware topology required for Redundant Application Engines functionality is simple: two computers with two network interface cards (NIC) each. (Additional network cards could be used for other purposes.)

To configure redundancy, open the Application Engine Object Editor and check “Enable Redundancy” on the Redundant tab.

Wonderware Training


The Application Engine that is enabled is considered the Primary engine of the redundant pair; when you enable this engine, an additional (Backup) engine is automatically created.

Since an engine is required to run under a platform, the platform objects that sponsor the Primary and Backup application engines need to be configured to use the dedicated NIC. This NIC provides a high speed inter-connection link or Redundant Message Channel between the platforms. The Message Channel is vital to keep both engines synchronized with alarms, history, and checkpoint items from the engine that is in the Active Role. Each engine also uses this Message Channel to provide its health, along with status information, to the other.

The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of Application engines determines which of these in the pair will take the Active Role. The first engine deployed takes the Active role while the other one takes the Standby role. The engines maintain their current roles until a failure occurs. (A failure might consist of computer hardware lost or failed, or a network card failure.) If a failure occurs, the engine with the Standby role assumes the Active role and the engine that was in the Active role is given the role of Standby - Not Ready. When the cause of the failure has been remedied, this engine assumes the Standby - Ready role.



Terminology Two sets of terms are critical to understanding the functions of redundant objects. These are described below.

During Configuration Primary object: The object intended as the main or central provider of the functionality in the run-time. For AppEngines, it is the object you enable for redundancy. For data acquisition, it is the DIObject you intend to use first as your data source in the run-time.

Backup object: The object that provides the functionality of the Primary object when it fails. For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary object has been enabled for redundancy. For data acquisition, it is the DIObject you do not intend to use first as your data source in the run-time.

During Run-Time Active object: The object that is currently executing desired functions. For AppEngines, it is the object that is hosting and executing ApplicationObjects. For data acquisition, it is the object that is providing field device data through the RedundantDIObject.

Standby object: The passive object; that is, it is waiting for a failure in the Active object's condition or for a force-failover. For AppEngines, it is the object that monitors the status of the Active AppEngine. For data acquisition, it is the object that is not providing field device data through the RedundantDIObject.

The Primary/Backup and Active/Standby objects form a redundancy pair. For AppEngine pairs, only the Primary and its hierarchy of assigned ApplicationObjects must be created, configured and deployed. The Backup is handled completely by the ArchestrA infrastructure (for instance, it is deployed separately from the Primary). For data acquisition, the Primary/Backup DIObjects (the data sources) must be separately created, configured and deployed. Also, you must create, configure and deploy a RedundantDIObject to control failovers between the two data source objects.

In the AppEngine redundancy environment, the Active and Standby objects monitor each other's status and switch when failure conditions occur. In the data acquisition environment, the RedundantDIObject monitors the status of the two DIObject data sources, and handles the switching from Active to Standby objects.

The relationship between the configuration time (Primary/Backup) and run-time (Active/Standby) object pairs is not static. In the run-time, either the Primary or Backup object can be the Active object at any particular time. Whenever one becomes the Active object, the other automatically becomes the Standby.

Configuration values for Primary and Backup also can be changed after deployment of the objects.

Note: In the case of AppEngine redundancy, ArchestrA supports a one-to-one topology in which the computers hosting the Primary and Backup object sets must be connected by crossover cable and have fixed IP addresses.

Key Points

a. Before placing an engine with redundancy enabled under a platform in the Deployment view, configure the platform Redundant Message Channel; otherwise the engine will show an error.

Wonderware Training


b. In the Application Views panes of the ArchestrA IDE, only in the Deployment view will the Backup engine be visible.

c. The Backup Engine cannot be edited.

d. After editing an engine with redundancy enabled while it is deployed, when it is redeployed the engine which has the Active role will perform this function. It will then update the engine that is in the Standby role.

e. A Backup engine's deployment status can be different from that of the Primary Engine, but operations such as renaming, importing and exporting, GRdump and GR load that are performed on the Primary Engine are automatically performed on the Backup. These operations cannot be performed on the Backup Engine alone.

f. Platforms hosting primary and backup AppEngines should have identical configuration. For instance, it is possible to configure the platform with the Primary to be the InTouch Alarm provider and filter the areas you want to query in the Platform editor. For the Alarm Management system to behave correctly, this same configuration should be implemented in the platform with the Backup. It is recommended that you make the following parameters common to both platforms:

IT Alarm provider-AreasStore Forward directoriesCommon user-defined attributes (UDAs)Common scripting



Dedicated and Shared LoadsThere are two types of redundant engine configuration: Dedicated and Shared load.

Note: Depending on the order of deployment, the Primary or Backup engine may take the role of Active Engine. If either engine is deployed by itself, it assumes the Active Engine role.

In a Dedicated redundant configuration, if the Active Engine fails or is shut down, or if a communication failure occurs, the engine in the Standby Ready role assumes the Active role. In this scenario, the platform with the engine in the Standby Ready role is essentially idling. See the following illustration.

In a Shared redundant configuration, two or more Redundant Engines reside on each of two platforms. Each platform hosts a Primary and a Backup engine. See the illustration below. This scenario operates similarly to the Dedicated configuration, but allows the application load to be shared on two computers until a failure occurs. When a failure occurs, one platform hosts the load of both application engines. The benefits of using this approach is that the time of failover is shortened and that only part of an application process is affected during a failure.

Note: It is important to understand both the CPU and memory load requirements of each engine. Each computer must be capable of supporting these needs when a failure occurs; otherwise, throughput for the application can be compromised

Platform 1

AE_1 (Active)

Redundancy Message Channel

Control Network

Supervisory Network

Backup

AutomationObject Server

Visualization Nodes

Primary

AutomationObject Server

AE_1(Standby)

Platform 2

Wonderware Training


Control Network

Visualization Nodes

Platform 2

Redundancy Message Channel

Supervisory Network

Platform 1

AE1AE1Bck AE2

AE2 BckPrimary Backup Backup Primary

AutomationObject Server AutomationObject Server



What Happens in Run-timeDuring initial deployment to its assigned WinPlatform, first code modules and other files for the Primary AppEngine are deployed, followed by those files for its assigned ApplicationObjects. All of these files are then deployed to the Standby AppEngine by the Active engine’s WinPlatform using the redundancy message channel (RMC).

Note: If some or all of these files already exist on the Standby AppEngine’s WinPlatform (perhaps, assigned to another AppEngine on that platform), only the delta files are deployed to the Standby AppEngine.

AutomationObjects are always assigned to the Primary AppEngine in the configuration environment. But in the run-time, AutomationObjects are always deployed to the Active AppEngine whether or not it was initially configured as the Primary object. All files are then deployed by the Active AppEngine’s WinPlatform to the Backup AppEngine as described above.

In the run-time environment, the Active and Standby AppEngines first attempt to establish communications across the RMC. This occurs when an AppEngine belonging to a redundant pair first starts up. Therefore, if one AppEngine is relocated later to a different WinPlatform, this communication between AppEngines can be reestablished.

During run-time, the Active and Standby engines communicate with each other and monitor each other's status.

In the case of a hardware or software failure on one computer, the Standby AppEngine will become the Active one. Then, if you want to move the new Standby AppEngine from its hosting computer, undeploy this AppEngine by using the On failure mark as undeployed option on the Undeploy dialog box, and then reassign and redeploy it to a WinPlatform that is configured for redundancy on another computer.

AppEngine Redundancy StatesRedundant pairs of AppEngines can have one of the following states at a time:

Active: The state of an AppEngine when it has communication with its partner object, its partner is in Standby-Not Ready, Standby-Sync’ing with Active, or Standby-Ready state. A Standby AppEngine transitions into this state when a failover condition has been detected. In this state, an AppEngine schedules and executes deployed objects, sends checkpoint data and sends subscriber list updates to the Standby AppEngine.Active - Standby not Available: The state of an Active AppEngine when it determines it cannot achieve communications with its partner object. This could mean that checkpoint, subscription and alarm state changes have not been successfully transmitted to the Standby object, a heartbeat ping has not been received from the Standby object, or notification is received that the Standby AppEngine has shutdown or is not running. If an AppEngine is in this state, it 1) continues normal execution of hosted objects, 2) cannot be manually switched to Standby state, and 3) while continuing to attempt communicate with the Standby, does not attempt to send data to the Standby object.Determining Failover Status: The initial state of a redundancy-enabled AppEngine when it is first started. It has not determined yet whether it is the Active or Standby AppEngine. Communication between the two AppEngines is attempted first over the RMC and then over the primary network to make this determination. If communication cannot be made after a certain timeout period, an AppEngine assumes the Active role if it has all of the code modules and checkpoint file data to do so. Continued attempts are made at communicating with its partner.

Wonderware Training


Standby - Missed Heartbeats: The state of an AppEngine when 1) a heartbeat ping has not been received from its Active partner within a configured timeout period, 2) the Active AppEngine fails or hangs up, or 3) the Active AppEngine is shutdown on purpose. When in this state, the Standby object attempts to determine whether or not the Active object has failed. If a manual failover is initiated (by using the ForceFailoverCmd attribute), it will be processed only if the heartbeats were missed over the primary network and not missed over the RMC.Standby - Not Ready: The state of an AppEngine when one of several conditions occurs: 1) its has lost communications with its partner object or it maintains communications with its partner but has missed checkpoint updates or alarm state changes from the Active AppEngine, 2) new objects are deployed to the Active AppEngine and necessary files have not been installed on the Standby AppEngine yet, or 3) the Standby AppEngine has lost communications over the RMC before it could complete synchronizing data. Typically, the AppEngine’s partner is in one of the following states: Active-Standby not Available, Active, or Standby- Missed Heartbeats.Standby - Ready: The state of an AppEngine when is has completed synchronizing code modules and checkpoint data with the Active AppEngine. In this state, the AppEngine monitors for Active AppEngine failure by verifying heartbeat pings received from the Active engine, checks that all files required for execution are in sync with the Active engine, and receives the following from the Active AppEngine: checkpoint change data, subscription-related notifications, alarm state changes, and history blocks.Standby - Sync'ng with Active: The state of an AppEngine when it is synchronizing code modules with the Active object. If code modules exist on the Standby computer that do not exist on the Active node, they are uninstalled, and likewise, any code modules that exist on the Active node but not on the Standby node are installed. Once all code modules are synchronized, the AppEngine transitions to Standby-Sync’d Code state.Standby - Sync'd Code: The state of a Standby AppEngine that has successfully synchronized all code modules with the Active object.Standby - Sync'd Data: The state of a Standby AppEngine when all object-related data, including checkpoint and subscriber information, are synchronized with the Active object. An object in this state typically transitions to Standby-Ready state.Switching to Active: A temporary, transitional state when a Standby AppEngine is commanded to become Active.Switching to Standby: A temporary, transitional state when an Active AppEngine is commanded to become Standby.Unknown: The state of a redundant partner when a communication loss occurs between AppEngines or when the partner AppEngine is not running.

Alarm GenerationWhen failover conditions occur, the ArchestrA system reports alarms to the Logger. These alarms contain the following information:

The name of the AppEngine reporting the alarm.The node name of the AppEngine reporting the alarm.The state of the AppEngine.The node name of the AppEngine’s partner object.

Note: Depending on the scenario that causes a failover, the Standby AppEngine may become the Active in an offscan state and alarms may not be generated. If the Active AppEngine is shutdown



offscan, the checkpointer may transfer that state to the Standby, and when the latter becomes the Active, it will startup offscan. When the AppEngine is put onscan, alarms then are generated.

Alarms reported are the following:

Legend:1 The Active AppEngine monitors the status of the Standby through the RMC to determine when to raise this alarm. Also, if the Active AppEngine is in Active-Standby not Available state, this alarm is not generated.

When a failover occurs, the Standby AppEngine that becomes active will not report alarms outstanding from the old Active AppEngine. The state of those old alarms, though, is reflected on the new Active AppEngine as follows:

Out of alarmUnacknowledgedUnacknowledged-Return to normal Acknowledged-Return to normalAcknowledged

Timestamps are also preserved for alarms, including when:The alarm was acknowledgedThe alarm condition went trueThe alarm condition went false

Finally, the following information is preserved for alarms:An alarm was acknowledgedThe message input by the operator when the alarm was acknowledged

Note: All alarm state information is collected and sent to the Standby AppEngine at the end of a scan cycle and before being sent to alarm clients. Any alarms that occur between scan cycles, therefore, may not be reported to the Standby object if the Active object fails. The sequence of reporting alarms ensures that alarm clients do not report alarms in states that are different from those reported by the Standby AppEngine if the Active one fails.

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

Alarm Previous State

Current State

Alarm Raised When Alarm Cleared When

Alarm Reported By

Standby - Not Ready 1

Active Standby - Not Ready

Standby - Not Ready

Entering Standby - Ready

ACtive Engine

Standby - Not Available

Active Active - Standby Not Available

Active - Standby Not Available

Entering Active Active Engine

Failover Occurred

Standby Becomes Active

During the next scan of the Active Engine

Active Engine

Wonderware Training


Loss of connectivity with the historian does not cause a failover. The Active AppEngine then goes into store-forward mode and caches data every 30 seconds. Store-forward data (when the historian is unavailable) is synchronized with the Standby AppEngine.

When failover conditions occur, no more than 30 seconds of history data should be lost in the transition from Standby to Active status. This is done through a combination of store-forward operations when the historian is unavailable and normal reporting operations when it is available.

Forced FailoverFailover can be forced to occur. Do this through the ForceFailoverCmd attribute of the AppEngine. For instance, you can link multiple conditions in a script or use the Object Viewer utility to trigger a forced failover.

Deployment Primary and Backup AppEngines can be deployed together or individually. When they are deployed together (no matter which object is actually selected for deployment), the Primary always becomes the Active and the Backup becomes the Standby. When they are deployed individually, the first one deployed becomes the Active.

Hosted ApplicationObjects are always deployed to the Active AppEngine. When deploying the first of a redundant pair of AppEngines, you can cascade deploy all objects it hosts. This operation can be paired with deploying both the Primary and Backup AppEngines at the same time.

Note: If you deploy the Backup AppEngine first and then deploy hosted objects to that AppEngine, ensure that network communications to both target computers is good before deploying the Primary AppEngine. Otherwise, errors may occur.

In the run-time environment, either the Primary or Backup AppEngine can become the Active or Standby depending upon failure conditions on either computer.

Before deploying the Primary and Backup AppEngines, all configuration requirements must be met. Each AppEngine must be assigned to a separate WinPlatform. A valid redundancy message channel (RMC) must be configured for each WinPlatform. To deploy the Primary and Backup together, select Include Redundant Partner in the Deploy dialog box. This option is not available when doing the following operations:

Cascade deploy from the GalaxyMultiple object selection deployDeployment of the WinPlatform that hosts the Primary or Backup AppEngine

See the following table for a matrix of allowed operations based on specific conditions.

Condition Deploy Both Primary and Backup Objects

Cascade Deploy Allowed

Backup AppEngine's host WinPlatform configured for failover and deployed.

Yes Yes

Backup AppEngine in error state. Yes Yes Backup AppEngine's host WinPlatform not deployed. No Yes Backup AppEngine's host WinPlatform not configured for failover and deployed.

Yes Yes

Deploy from Galaxy node. No Yes Deploy from WinPlatform hosting Primary AppEngine. No Yes



Undeploying redundancy pairs of AppEngines is similar to any regular object undeployment. The Active and Backup AppEngines can be undeployed separately. Also, they can be undeployed as a pair by selecting one of the objects in an Application View, selecting the Undeploy command, and selecting Include Redundant Partner in the Undeploy dialog box.

Note: Undeployment of any AutomationObjects, including redundant AppEngine pairs, does not uninstall code modules for that object from the hosting computer. Code modules are uninstalled only when the WinPlatform is undeployed.

Errors and Warnings Certain requirements (for instance, the order you configure an object pair for redundancy) are validated by the system infrastructure. If a requirement is not met, you may see error messages that describe the following:

You can configure an AppEngine for redundancy before its associated WinPlatform, but if you do, you will get an error message that the Platform (specifically, the RMC) is not configured yet.If the RMC IP Address parameter is not configured in both hosting WinPlatforms, then the configuration state of both Primary and Backup AppEngines changes to Error, with a message indicating that the host WinPlatform is not configured with the network adapter required for redundant communications. When the RMC IP Address is configured and the WinPlatforms are checked in, the hosted AppEngines are automatically revalidated and the Error state is resolved. If hosted AppEngines are checked out, they are not revalidated.If both Primary and Backup AppEngines are assigned to the same WinPlatform and an attempt is made to deploy both engines, both the Primary and Backup will fail to deploy with a message noting that the Primary and Backup objects must be hosted by different WinPlatforms. Reassign the Backup object to another WinPlatform and deploy it separately.If both the Network Address and RMC IP Address parameters in the WinPlatform's editor address the same network card, you will get a warning message when you save the configuration. These two parameters must address different network cards.

Multiple object selection deploy. No No Backup AppEngine's host WinPlatform not configured for failover and not deployed.

No Yes

Deploy from Backup AppEngine. Yes Yes Deploy from Primary AppEngine. Yes Yes

Condition Deploy Both Primary and Backup Objects

Cascade Deploy Allowed

Wonderware Training


Lab 18 – Configuring Application Redundancy

IntroductionThis lab describes how to configure your galaxy for redundancy starting with the necessary network configuration in Windows to properly handle a second network connection as the galaxy’s redundant message channel.

Using the ArchestrA IDE, the galaxy is configured to become a two-node redundant system that will failover between the two nodes when a failure occurs in the system.

Note: It is assumed that the required second network card is installed in both computers and the crossover cable for the RMC is connected

Note: Because of the additional hardware and network requirements necessary, this lab is usually executed as an Instructor demonstration only.


Configure a second network connection in Windows as the redundant message channel Configure the $WinPlatform and $AppEngine object for redundancy Create a deployment model for redundant engines Force a failover on a redundant system



Configure Windows network connections

Note: The following configuration needs to be done on BOTH computers.

a. Rename the network connections as follows:

Local Area Connection to ArchestrA

Local Area Connection 2 to RMC

b. Use the network connections Advanced Settings to make sure that the ArchestrA connection is access before the RMC connection.

c. Assign an IP address to the RMC in a different subnet than the ArchestrA connection.

Important! The IP address for the RMC connection on both computers must be different but in the same subnet.

d. On the Advanced setting for TCP/IP, configure the RMC connection to not Register this connection’s addresses in DNS.

Configure the Galaxy for Redundancy e. Undeploy the galaxy.

f. Configure the GRPlatform object’s Redundancy message channel IP address with its own RMC IP address.

g. Create a new instance of the $tWinPlatform template named Platform_001 and assign it to the ControlSystem area.

h. Configure the Platform_001 object with the name of the second computer and its own RMC IP address for the Redundancy message channel IP address.

i. Configure the AppEngine object for Redundancy and assign its backup to the Platform_001 object.


Wonderware Training


Test Redundancy j. Deploy the galaxy.

k. Using the watch list created in Lab 5, add a new watch window called Redundancy and add the following attribute references:

l. Save the watch list.

m. Force a failover in the system and monitor the data using Object Viewer and the different watch windows created during the class.


Instance AttributeAppEngine HostAppEngine Redundancy.IdentityAppEngine Redundancy.StatusAppEngine Redundancy.PartnerPlatformAppEngine Redundancy.PartnerStatusAppEngine Redundancy.FailoverOcurredAppEngine Redundancy.ForceFailoverCmd



Configure Windows network connections

Note: The following configuration (steps 1-13) needs to be done on BOTH computers.

1. Open Windows Network Connections by double-clicking on Start / Control Panel / Network Connections.

The Network Connections window appears.

2. Rename network connections as follows:

This is an optional step that enables you to easily identify each connection in this class environment.


Local Area Connection to ArchestrA

Local Area Connection 2 to RMC

Wonderware Training


3. From the Advanced menu, select Advanced Settings.

4. In the Advanced Settings dialog box, Adapters and Bindings tab, make sure that the ArchestrA connection is listed before the RMC connection and then click the OK button to close the dialog box.

Note: You can use the and buttons to arrange the access order.



5. Right-click on the RMC connection and select Properties.

6. In the RMC Properties dialog box, General tab, select the Internet Protocol (TCP/IP) item and click the Properties button.

7. At the Internet Protocol (TCP/IP) Properties dialog box select the Use the following IP address option and assign an IP address in a different subnet than the ArchestrA connection.

Wonderware Training


Important! The IP address for the RMC connection must be different on each computer but in the same subnet, and on a different subnet than the ArchestrA node.

Note: In this example the first computer will have an IP address of 192.168.1.1 and the second computer will have an IP address of 192.168.1.2. Both will be have a subnet mask of 255.255.255.0.

8. Click the Advanced button to continue.



9. In the Advanced TCP/IP Settings dialog box, select the DNS tab.

10. Uncheck the Register this connection’s address in DNS box.

11. Click the OK button to close the Advanced TCP/IP Settings dialog box.

12. Click the OK button to close the Internet Protocol (TCP/IP) Properties dialog box.

13. Click the Close button to close the RMC Properties dialog box.

Wonderware Training


Configure the Galaxy for Redundancy 14. Undeploy the GRPlatform object.

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

16. In the Redundancy panel, Redundancy message channel IP address field, enter the IP address assigned to the RMC connection you used for the first computer in step 7. In this example the first computer has an IP address of 192.168.1.1


18. Create a new instance of the $tWinPlatform template named Platform_001.



19. Assign the new Platform_001 instance to the ControlSystem area.

20. Double-click the Platform_001 instance to open its configuration editor.

21. In the Network address field, enter the name of second computer.

22. In the Redundancy panel, Redundancy message channel IP address field, enter the IP address assigned to the RMC connection you used for the second computer in step 7. In this example the second computer has an IP address of 192.168.1.2

Wonderware Training



24. Double-click the AppEngine instance to open its configuration editor.

25. Select the Redundancy tab and configure the object as follows:

Enable redundancy: checked


27. In Deployment view, assign the automatically created AppEngine (Backup) object to the Platform_001 instance.



Test Redundancy 28. Deploy the galaxy by right-clicking the name of the galaxy and selecting Deploy.

29. Open Object Viewer by right-clicking the AppEngine instance and selecting View in Object Viewer.

30. Load your saved Watch List.


32. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to Redundancy.

33. Using the watch list created in Lab 5, add a new watch window named Redundancy with the following attributes from the AppEngine instance:

HostRedundancy.IdentityRedundancy.StatusRedundancy.PartnerPlatformRedundancy.PartnerStatusRedundancy.FailoverOccurredRedundancy.ForceFailoverCmd



Wonderware Training


35. Force a failover to the second computer by writing true to the ForceFailoverCmd attribute of the AppEngine.

You can use the Mixer1 watch window to verify that the objects are running properly.

36. Failover the system doing any of the following on the second computer: Unplug the power cable Shut down Windows Disconnect both network cables at the same time.

You can use the Mixer1 watch window to verify that the objects are running properly.




Wonderware Training


Section 2 – DI Redundancy


Redundant DI ObjectsApplication Engines can host Redundant Device Integration Objects (DI Objects). The RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike redundant AppEngines, individual DIObject data sources do not have redundancy-related states. For all intents and purposes, they function as standalone objects.

Only one DIObject data source provides field device data through the RedundantDIObject at a time. Both data sources must have commonly configured DAGroups which are reflected in and channeled through the RedundantDIObject, which monitors the two DIObject data sources and determines which one is Active at any given time. Both data sources must also have the same item address space.

The Redundant DI Object is a DINetwork Object used to enable continuity of I/O information from field devices. The Redundant DI Object provides the ability to configure a single object with connections to two different data sources. If the primary data source fails, the Redundant DI Object automatically switches to the backup data source for its information. There is a one-to-two relationship between an instance of the Redundant DI Object and the running instances of the source DI objects; that is, for each Redundant DI Object, a pair of source DI Objects is deployed.

Section ObjectiveThis section covers the concept of redundancy, how it can be configured and key points to more effectively implement this feature.Understand the concept and functionality of Redundant DI Objects



Configuration RedundantDIObjectsConfigure redundancy in data acquisition objects in the ArchestrA IDE through their editors. Data acquisition redundancy objects (two DIObjects and the RedundantDIObject) do not have redundancy-related deployment statuses.

In data acquisition redundancy, you must configure all three components: a Primary DIObject data source, a Backup one, and a Redundant DIObject.

Because data acquisition redundant components are essentially standalone objects, all valid operations that apply to any other ApplicationObjects apply to the three objects. All ArchestrA IDE commands, Galaxy Dump and Load functions, and import and export operations are valid on the two DIObject data sources and the RedundantDIObject.

The main focus of RedundantDIObject configuration is:Setting the Primary DI Source and Backup DI Source on the General tab of the object’s editor.Setting up the common scan groups, and block read and block write groups on the respective tabs of the object’s editor.

Note: You must configure at least one scan group before you can deploy the RedundantDIObject. Also, only scan, block read, and block write groups shared by the Primary and Backup DIObjects should be configured in the RedundantDIObject.

��

�� !"��#��

$%&

$'��(��)�

��

&��'!"��#��'��!��

��*��*��

!��!+,-��

��.� ��.�

��.��.�

)*+�,��

Wonderware Training


DeploymentDeployment for data acquisition redundancy is the same as individually deploying unrelated objects. No special conditions apply to each DIObject data source and the RedundantDIObject.

What Happens in Run-timeThe three objects in the data acquisition redundancy scheme (RedundantDIObject and its two DIObject data sources) function like any other ArchestrA object with respect to deployment, alarming and historization. They have no special redundancy-related states or restrictions with respect to deployment, undeployment and redeployment.

During run-time, the RedundantDIObject monitors the status of the DIObject data sources, and handles the switching from Active to Standby object when failure conditions arise.




Wonderware Training


Lab 19 – Configuring the Redundant DI Object

IntroductionThis lab describes the steps necessary to configure your galaxy for redundancy at the communication level with the field by using two similar device integration objects connected to the same field device, such as a PLC.

Note: Because of the additional hardware and network requirements necessary, this lab is usually executed as an Instructor demonstration only.


Create a deployment model for redundant DI object Configure and use the $RedundantDIOObject Force a failover on a redundant DI system



Configure DI Redundancya. Create two new instances of the $tAppEngine template, name them AppEngineDI1 and

AppEngineDI2 and assign them to the ControlSystem area.

b. Host AppEngineDI1 on the GRPlatform platform and AppEngineDI2 on Platform_001 platform.

c. Rename the InControl instance as DIO1 and host it on the AppEngineDI1 engine.

d. Create a copy of the DIO1 object by repeating Lab 6 but naming the object DIO2. Assign the new object to the ControlSystem area and host it on the AppEngineDI2 engine.

e. Derived a new template from the $RedundantDIObject object, name it $tRedundantDIObject, and assign it to the Training template toolset.

f. Create an instance of the $tRedundantDIObject template and name it InControl.

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

h. In the Scan Group tab, copy the common scan groups and attributes from the primary or backup DI sources.

i. Host the InControl instance on the AppEngine object.

Test the Redundant DI Object j. Deploy the AppEngineDI1, AppEngineDI2, DIO1, DIO2 and InControl objects.

k. Using the watch list created in Lab 5, add a new watch window called RDIO and add the following attribute references:

l. Save the watch list.


Primary DI source: DIO1

Backup DI source: DIO2

Instance AttributeInControl DISourcePrimaryInControl DISourceBackupInControl DISourceActiveInControl DISourceStandbyInControl StatusPrimaryDISourceInControl StatusBackupDISourceInControl ConnectionStatusInControl SwitchReasonInControl ForceFailoverCmd

Wonderware Training


m. Force a failover in the system and monitor the objects using Object Viewer and the different watch windows created during the class.




Configure DI Redundancy1. Create two new instances of the $tAppEngine template.

2. Name the new instances AppEngineDI1 and AppEngineDI2 and assign them to the ControlSystem area.

3. In the Deployment view, host AppEngineDI1 on the GRPlatform platform and AppEngineDI2 on Platform_001 platform.

4. Undeploy the InControl instance.

5. Rename the InControl instance DIO1.


Wonderware Training


6. Host the DIO1 object on the AppEngineDI1 engine.

7. Use Lab 6, “Connecting to the Field” to create another device integration object, but name it DIO2 instead of InControl. Assign it to the ControlSystem area.

Note: You can export your object, rename the original, and then import the object to create a copy of the object with all of the original object’s configuration attributes.



8. In the Deployment view, host the DIO2 object on the AppEngineDI2 engine.

9. Create a derived template from the $RedundantDIObject template named $tRedundantDIObject and assign it to the Training template toolset.

10. Create an instance of the $tRedundantDIObject template named InControl and assign it to the ControlSystem area.

Wonderware Training


Note: The template name InControl is used here to match the existing attribute references that were configured in the objects and scripts in previous labs.

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

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

Primary DI source: DIO1

Backup DI source: DIO2



13. Select the Scan Group tab and click on the Copy Common Scan Groups button.

14. In the Copy Common Scan Groups dialog box, click the OK button to accept tagname as the scan group for the new InControl object.

Wonderware Training


15. Click on the Copy Attributes From Primary button.




17. In the Deployment view, host the new InControl object on the AppEngine engine.

Test the Redundant DI Object 18. Deploy the AppEngineDI1 object on cascade.

19. Deploy the AppEngineDI2 object on cascade.

20. Deploy the InControl object.

21. Open Object Viewer by right-clicking the InControl instance and selecting View in Object Viewer. If you closed Object Viewer before, you can use File / Load Watch List to open the file you saved earlier.


23. Right-click in the Watch List (bottom section of Object Viewer) and select Rename Tab to rename the watch list to RDIO.

Wonderware Training


24. Add the following attributes from the InControl instance to the watch list: DISourcePrimaryDISourceBackupDISourceActiveDISourceStandbyStatusPrimaryDISourceStatusBackupDISourceConnectionStatusSwitchReasonForceFailoverCmdSwitchCnt



26. Force a failover to the second device integration object by writing true to the ForceFailoverCmd attribute of the Redundant DI Object. You can use the Mixer 1 watch window to verify that the objects are running properly.

27. Failover the system doing any of the following on the second computer: Unplug the power cable Shut down Windows Put the DIO2 object off scan



You can use the Mixer 1 watch window to verify that the objects are running properly.

Wonderware Training


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.

Standalone to Network ConfigurationEarlier we discussed the standalone configuration you have been using up to this point. At this time you want to migrate over to a network configuration that will reflect four nodes accessing one Galaxy Repository. This will allow us to utilize a networked configuration to convey more complex concepts relating to connectivity, exporting objects and templates and other multi-node environmental considerations.

Each of the nodes contains the Bootstrap, the ArchestrA IDE, and a Galaxy Repository. Once you have reconfigured the environment there will be one machine (Node1) that will contain the Bootstrap, the ArchestrA IDE, and a Galaxy Repository. Three other nodes will be connected to the Galaxy on Node1. Those other three nodes will contain only the Bootstrap and the ArchestrA IDE.

In the networked architecture a common Galaxy Repository will be shared between a set of PCs allowing multiple users to simultaneously work on the same application.

The existing standalone environment is illustrated as follows:

Section ObjectiveThis section deals with migrating from a standalone configuration to a network configuration. At the conclusion of this section you will have an understanding of the steps necessary to migrate to a network environment.



The networked environment that you are migrating to is illustrated as follows:

Wonderware Training


Multi User Conversion ConsiderationsWhen migrating from a Stand Alone environmental configuration to a networked configuration there are some factors that must be taken into consideration. One of the key ones being that certain functions take place on the Galaxy Repository node BEFORE they take place from the connecting nodes.

There a need for only one PLC so the one residing on the resulting Galaxy Repository node is the one that is most likely the one desired for the network. Therefore, that is the one and only one that is to be exported in preparation for the network environment.

The node that contains the Galaxy Repository must do several tasks before any other nodes can connect. These include:

Create the Galaxy to which all other nodes will connect.Create Platforms for other galaxy members.Rename the node.Name and deploy their own Platform as the first Platform deployed on the Galaxy Repository node.

Failure to follow these key steps before others connect and start deploying objects can produce less than desirable results.




Wonderware Training


Lab 20 – Convert to Network Environment

IntroductionThis lab describes the steps necessary to convert to a Networked Configuration. In this lab you team up with your classmates to create a galaxy that spans across multiple nodes. In the networked environment a common Galaxy Repository is shared between a set of PCs allowing multiple users to simultaneously work on the same application.

To speed up the process, templates you created in the class are re-used.

Since there can only be one Galaxy Repository per galaxy, your team needs to designate one of the team members’ computer to become the sole Galaxy Repository for the galaxy. This person/computer is designated as the Galaxy Master. The Galaxy Master has specific extra steps to perform.


Configure a galaxy for a multi-node environment.



Note: For this lab there are no detailed steps on the following pages. Only general guidance is given to allow you the chance to put what you have learned into practice.

Preparationa. Undeploy your galaxy.

b. Rename the Training toolset, adding your initials to the beginning. In this example, the Training toolset will be renamed ABTraining.

c. Rename all of your template objects, preceding each object name with your initials.

For example, Ann Brown’s initials are AB. Ann Brown would rename her Platform template to ABtWinPlatform, her AppEngine template to ABtAppEngine, and so on.

d. Export all your templates to a file called MyTemplates.aaPKG.

Export the InControl instance and create a New Galaxy e. Export the InControl instance to a file called InControl.aaPKG.

Note: If you did Lab 19, then export both the I/O 1 and I/O 2.

f. Create a new galaxy named MultiNodeGalaxy.

g. Import the MyTemplates.aaPKG and InControl.aaPKG files.

h. Create an area instance named ControlSystem and assign the InControl object to it.

i. Create a platform instance named ABPlatform where AB is your initials and assign it to the ControlSystem area.

j. Create an engine instance named AppEngineDI and assign it to the ControlSystem area.

k. On the Deployment view:

Host AppEngineDI on ABPlatform.

Host InControl on AppEngineDI.

Host ControlSystem on AppEngineDI.

l. Deploy the ABPlatform object on cascade.

m. Configure the galaxy’s security Authentication Mode to Galaxy.

n. Create a user account that belongs to the Administrator role for each member of the team.


This section is to be performed by everyone.

This section is to be performed by the Galaxy Master only.

Wonderware Training


Setup the Platforms o. Use the ArchestrA IDE to connect to the MultiNodeGalaxy galaxy in the Galaxy Master’s

computer using your designated user account.

p. Import your MyTemplates.aaPKG file.

q. Create a platform instance named ABPlatform where AB is your initials, and configure it with your local computer’s name. Assign it to the ControlSystem area.

r. Deploy the ABPlatform object on cascade.

Test the Galaxy s. Create an engine instance named ABAppEngine, assign it to the ControlSystem area and

host it on your ABPlatform object, where AB is your initials.

t. Create an area instance named ABLine and host it on your ABAppEngine object, where AB is your initials.

u. Create an instance of your mixer template and name it properly with the valid 3-digit mixer ID at the end (ABMixer_1XX) as identified in Lab 2. Host it on your ABLine area, where AB is your initials.

v. Deploy your ABAppEngine object on cascade, where AB is your initials.

w. Use Object Viewer to verify that all objects are running properly and are getting data from the field.

Note: Feel free to experiment and play around with the multi-node system to reinforce the knowledge acquired during this class.

This section is not to be performed by the Galaxy Master.

This section is to be performed by everyone.




Wonderware Training

Appendix A

Wonderware Application Server Glossary

A-2 Appendix A – Wonderware Application Server Glossary


Wonderware Training

Appendix A – Wonderware Application Server Glossary A-3

Application

A collection of objects within a Galaxy Repository that performs an automation task. Synonymous with Galaxy. There may be one or more applications within a Galaxy Repository.

Application Engine (AppEngine) A scan-based engine that hosts and executes the runtime logic contained within AutomationObjects.

ApplicationObjectAn AutomationObject that represents some element of your application. This may include things such as (but not limited to) an automation process component (for instance, a thermocouple, pump, motor, valve, reactor, or tank) or associated application component (for instance, function block, PID loop, Sequential Function Chart, Ladder Logic program, batch phase, or SPC data sheet).

Application ServerThe supervisory control platform. Application Server uses existing Wonderware products such as InTouch for visualization, the Wonderware Historian for data storage, and the device Integration product line like a Data Access Server (DAServer) for device communications.An Application Server can be distributed across multiple computers as part of a single Galaxy Namespace.

Application ViewsThe Application Views pane displays the object-related contents of the Galaxy in different ways: Model view, Deployment view, Derivation view and Operations view. The Model view is the default display when the ArchestrA IDE is first opened.

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

ArchestrA Object Toolkit A programmer’s tool used to create new ApplicationObjects and Device Integration Object Templates, including their configuration and run-time implementations. Includes a developer tool used to build DI Objects and create unique Domain Objects that interact with DI Objects in the ArchestrA environment.

AreaA 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 ObjectThe System Object that represents an Area of your plant within a Galaxy. The Area Object acts as an alarm concentrator, and is used to place other Automation Objects into proper context with respect to the actual physical automation layout.

Assignment The designation of a host for an AutomationObject. For example, an AppEngine AutomationObject is assigned to a WinPlatform AutomationObject.

Attribute An externally accessible data item of an AutomationObject.

Attribute Reference String A text string that references an attribute of an AutomationObject.



AutomationObject A type of object that represents permanent things in your plant (such as Application Objects or Device Integration Objects) as objects with user-defined, unique names within the Galaxy. It provides a standard way to create, name, download, execute, and monitor the represented component.

Automation Object Server (AOS)A computer that hosts one or more application engines and associated automation objects. A Wonderware Application Server Galaxy Namespace can contain several Automation Object Servers, each which requires a Platform.

Backup Application EngineThe object created by the ArchestrA infrastructure when the Primary object has been enabled for Redundancy. See Redundancy for further detail.

Base TemplateA root template at the top of a derived hierarchy. Unlike other templates, a base template is not derived from another template but developed with the Application Object Toolkit and imported into a Galaxy. Base templates and derived templates always have a $ before their name in the IDE.

Block Read Group A DAGroup that is triggered by the user or another object. It reads a block of data from the external data source and indicates the completion status.

Block Write Group A DAGroup that is triggered by the user or another object after all the required data items have been set. The block of data is then sent to the external data device. When the block write is complete, it indicates the completion status.

BootstrapThe base ArchestrA service which is required on all ArchestrA computers. It provides the base software environment to enable a platform and allows a computer to be included in the Galaxy Namespace.

Change Log The revision history that tracks the life cycle activities of ArchestrA Objects, such as object creation, check-in/check-out, deployment, and import/export.

Change PropagationThe ability to create templates which will allow each component template to support changes such that a change in one of the elements can be automatically propagated to all — or select, related — instances.

Check-In IDE operation for making a configured object available for other users to Check-Out and use.

Check-Out IDE operation for the purpose of editing an object. It makes the item unavailable for other users to Check-Out.

Checkpoint The act of saving to disk the configuration, state, and all associated data necessary to support automatic restart of a running AutomationObject. The restarted object has the same configuration, state, and associated data as the last checkpoint image on disk.

Compound Object. An Application Object that contains at least one other Application Object.

Wonderware Training


Contained Name An alternate naming convention that when combined with the tag name of the root container object, results in the Hierarchical Name. For instance, for a given object, it’s Hierarchical Name = Line1.Tank1.InletValve and its Contained Name= InletValve

Containment A hierarchical grouping that allows one or more AutomationObjects to exist within the name space of a parent AutomationObject and be treated like parts of the parent AutomationObject. This functionality allows for relative referencing to be defined at the template and instance level.

DAGroup A data access group associated with Device Integration Objects (DIObjects). It defines how communications is achieved with external data sources. It can be a ScanGroup, Block Read or Block Write groups.

DAServer Manager (DAS Manager)The System Management Console (SMC) snap-in supplied by the DAServer that provides the required user interface for activation, configuration, and diagnosis of the DAServer.

Data Access Server (DAServer) The server executable that handles all communications between field devices and client applications. Similar in function to I/O Servers but with more advanced capabilities.

Data Access Server Toolkit (DAS Toolkit) A developer tool used to build Data Access Servers (DAServers).

Deployment The operation which instantiates an automation object instance in the AutomationObject Server. This action involves installing all the necessary software and instantiating the object on the target platform with the objects default attribute data from Galaxy Repository.

Deployment ViewThe 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 ViewThe 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 TemplateAny template with a parent template.Device Integration Object (DIObjects)An AutomationObject that represents the communication with external devices or software. DIObjects run on an Application Engine, and include DINetwork and DIDevice objects.

DIDevice Object An object that represents the actual external device (for example, a PLC or RTU) that is associated with a DINetwork Object. It provides the ability to diagnose and browse data registers of the DAGroups for that device.

DINetwork Object An object that represents the network interface port to the device via the Data Access Server or the object that represents the communications path to another software application. It provides diagnostics and configuration for that specific network card.



ElementBasic shapes, such as rectangles, lines, and text elements, and controls you can use to create an ArchestrA Symbol to your specifications.

Engine ObjectAn 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 GatewayFactorySuite 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 ManagerThe 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 ToolboxThe part of the IDE main window that shows a hierarchy of graphic toolsets, which contain ArchestrA Symbols and client controls.

Hierarchical NameThe name of the object in the context of its container object. For instance, Tank1.OutletValve, where an object called Tank1 contains the OutletValve object.

Historical Storage System (Historian)The time series data storage system, used to compress and store high volumes of time series data for latter retrieval. For the Wonderware Application Server, the standard Historian is IndustrialSQL Server.

HostThe parent instance of a child instance in the deployment view. (Example: a Platform instance is a Host for an AppEngine instance).

Wonderware Training


ImportThe act of reading a .aaPKG File and using it to create AutomationObject instances and Templates in the Galaxy Repository.

Wonderware Application ServerRefers to the Wonderware A2 Supervisory Control Platform, commonly known as the Application Server. The Wonderware Application Server is sized by (a) the number of Workstation / Server Platforms, (b) by real I/O in the system, and (c) the number of Terminal Services sessions. The Application Server license is per Galaxy. An Application Server can be distributed across multiple computers as part of a single Galaxy Namespace. The Wonderware Application Server is designed to leverage existing Wonderware products such as InTouch for visualization, Industrial SQL as its historian, and the device Integration product line (I/O Servers) for device communications. The Wonderware Application Server uses InTouch v8.0 or InTouch View v8.0 for visualization with the addition of Platforms to the visualization node.

InstanceAn object, which is a unique representation of a template that can exist in runtime.

Instantiation The creation of a new object instance based on a corresponding Template.

Integrated Development Environment (ArchestrA IDE)The Integrated Development Environment (IDE) is the user interface for the configuration side of Application Server. It is used to manage templates, create object instances, deploy and un-deploy objects and a host of other functions associated with the development and maintenance of the system. It is only available as part of the Wonderware A2 Development License.

InTouch View InTouch View Clients are InTouch Runtime Version 8.0 clients that solely use of the Wonderware Application Server for its data source. In addition, standard InTouch v8.0 runtimes can leverage the Wonderware Application Server with the addition of a Platform license.

I/O CountNumber of I/O points being accessed into the Galaxy. I/O points are real I/O and are not equivalent to InTouch tags. I/O count is based on the number of I/O points that are configured through an OPC Server, I/O Server, DA Server or InTouch Proxy Object, over the whole Application Server Namespace, regardless of how many PCs are in the system.

Life Cycle CostThe 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 ModeAn action in ActiveFactory that enables the configuration of a Runtime application to be refreshed at a designated interval.

Log ViewerA 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 ViewThe part of the Applications View in the IDE that shows how objects are arranged to describe the physical layout of the plant and supervisory process being controlled.



ObjectAny 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 ExtensionsThe 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 ViewerA 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 CountNumber 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 ManagerThe Platform Manager provides Galaxy application diagnostics by allowing you to view the run-time status of some system objects and to perform actions upon those objects. Actions include setting platforms and engines in an executable or idle mode and starting and stopping platforms and engines. This utility is an extension snap-in to the ArchestrA System Management Console (SMC).

Platform Object An object that represents a single computer in a Galaxy, consisting of a system wide message exchange component and a set of basic services. This object hosts all Application Engines.

PLCProgrammable logic controller.

Primary Application EngineThe object created by the ArchestrA infrastructure when the Backup object has been created through Redundancy. See Redundancy for further detail.

Wonderware Training


Properties Data common to all attributes of objects, such as name, value, quality, and data type.

Proxy ObjectA Proxy Objects is an Automation Object that represents an actual product for the purpose of device integration with the Wonderware Application Server or InTouch® HMI. For example, there is a Proxy Object that enables the Wonderware Application Server to access an OPC server.

Redundancy

During ConfigurationPrimary object: The object intended as the main or central provider of the functionality in the run-time. For AppEngines, it is the object you enable for redundancy. For data acquisition, it is the DIObject you intend to use first as your data source in the run-time.Backup object: The object that provides the functionality of the Primary object when it fails. For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary object has been enabled for redundancy. For data acquisition, it is the DIObject you do not intend to use first as your data source in the run-time.

During Run-TimeActive object: The object that is currently executing desired functions. For AppEngines, it is the object that is hosting and executing ApplicationObjects. For data acquisition, it is the object that is providing field device data through the RedundantDIObject.Standby object: The passive object; that is, it is waiting for a failure in the Active object’s condition or for a force-failover. For AppEngines, it is the object that monitors the status of the Active AppEngine. For data acquisition, it is the object that is not providing field device data through the RedundantDIObject.

Redundant DI ObjectThe RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike redundant AppEngines, individual DIObject data sources do not have redundancy-related states. For all intents and purposes, they function as standalone objects.

Redundant Message Channel

The Redundant Message Channel (RMC) is a dedicated Ethernet connection which is required between the platforms hosting redundant engines. The RMC is vital to keep both engines synchronized with alarms, history, and checkpoint items from the engine that is in the Active Role. Each engine also uses this Message Channel to provide its health and status information to the other.

ReferenceA string that refers to an object or to data within one of its attributes.

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

RuntimeThe InTouch (WindowViewer) function that provides the viewing of data from the configuration of the application in InTouch development (WindowMaker).



Scan Group A DAGroup that requires only the update interval be defined and the data will be retrieved at the requested rate.

Scan StateThe Scan State of an object in run-time. This can be either off-scan or on-scan.

SecurityWonderware Application Server security is applied to the ArchestrA IDE, the System Management Console (SMC), and the runtime data level. At the runtime data level which centralizes the definition of all permissions to the ApplicationObjects. These ApplicationObjects can be accessed by a variety of clients but the security is centrally defined allowing ease of maintenance. The users that are allowed to modify these ApplicationObjects at runtime are mapped to the objects by user defined roles. These roles can be mapped directly to existing groups in a Microsoft Domain or workgroup.

SmartSymbolsSmartSymbols are objects that integrate object-oriented technology with InTouch graphics to transform them into reusable templates. Changes made to the templates automatically propagate throughout an application – even across multiple networked PC nodes. They are created from a graphic in an InTouch window that has been made into a cell and converted into a SmartSymbol. In addition, libraries of SmartSymbols can be exported to other applications and plants, enabling companies to standardize on graphics throughout the entire organization.

System Management Console (SMC) The central runtime system administration/management user interface in which all required runtime administration functions can be accomplished.

System ObjectsObjects that represent an Area, Platform or Engine.

TagName The unique name given to an object. For instance, for a given object, its TagName = V1101 and its HierarchicalName = Line1.Tank1.InletValve.

Template An object containing configuration information and software templates used to create new Derived Templates and/or Instances.

Template ToolboxThe 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 objectAn 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 objectAn object that represents a single computer in a Galaxy, consisting of a system-wide message exchange component, a set of basic services, the operating system, and the physical hardware. This object hosts all AppEngines.

Wonderware Training

Appendix B

Plant Model Planning Diagrams

B-2 Appendix B – Plant Model Planning Diagrams


Wonderware Training

B-3

The Plant Model Planning Diagrams are displayed on the following pages.



Wonderware Training

B-5



Wonderware Training

B-7




Wonderware Training

SystemPlatformPart1RevA GOLD EntireManual

Documents

Transcript of SystemPlatformPart1RevA GOLD EntireManual