Ias 2 0 Revc Gold Manual

Training ManualRevision CJune 2005

Part Number 05-2056

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

Industrial Application Server

2.0 Course

INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE.

© 2004 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 Wonderware Corporation or Invensys Systems, Inc., license. These terms include provisions that limit your rights such as use restrictions, disclaimers of warranties and limitations of Wonderware and Invensys liability. A copy of the applicable license will be displayed upon initial installation of the software. If a copy of the license is not displayed or you require an additional copy of the license, you may obtain one from Invensys' Wonderware business unit upon request by calling 1.949.727.3200 or by sending an e-mail to [email protected].

Invensys; Wonderware; ActiveFactory; ArchestrA; DT Analyst; FactorySuite; FactorySuite A2; InBatch; InControl; IndustrialSQL Server; InTouch; InTrack; QI Analyst; SCADAlarm; SuiteLink; SuiteVoyager; WindowMaker; WindowViewer; WonderWorld; Every system in your plant, working in concert; the Visualize, Analyze, Optimize symbols; SPCPro and Visualize, Analyze, Optimize are trademarks or service marks of Invensys plc, its subsidiaries and affiliated companies. All other brands and product or service names may be the trademarks or service marks of their respective owners.

(rev. 0105)

Table of Contents iii

Table of Contents

Module 1 Introduction .................................................................................1-1Section 1 – Course Introduction......................................................................... 1-3Section 2 – ArchestrA ...................................................................................... 1-13Section 3 – IAS System Requirements............................................................ 1-21Section 4 – Architectural Overview .................................................................. 1-23Section 5 – Installation and Licensing.............................................................. 1-35

Module 2 Application Planning and the Plant Model ...............................2-1Section 1 – Plant Modeling ................................................................................ 2-3Section 2 – Object Oriented vs. Tag Based Supervisory Control ...................... 2-9

Module 3 The Galaxy ...................................................................................3-1Section 1 – The Galaxy...................................................................................... 3-3

Lab 1 – Creating a Galaxy........................................................................... 3-5Section 2 – Tour of the IDE.............................................................................. 3-11Section 3 – Facility Modeling ........................................................................... 3-31

Lab 2 – Facility Model ............................................................................... 3-33Section 4 – Objects and Object Instances ....................................................... 3-37

Lab 3 – Create and Deploy a Platform ...................................................... 3-43Lab 4 – Create and Deploy an Engine ...................................................... 3-55

Module 4 Modeling Equipment...................................................................4-1Section 1 – Application Objects ......................................................................... 4-3

Lab 5 – DeviceIntegration Object ................................................................ 4-7Lab 6 – Analog Devices ............................................................................ 4-19Lab 7 – DiscreteDevices - Valve Instance................................................. 4-29

Module 5 Complex Object Modeling – Extending the Objects ................5-1Section 1 – Object Relationships ....................................................................... 5-5

Lab 8 – Modeling Complex Objects ............................................................ 5-9Section 2 – Object Change Control and Propagation ...................................... 5-37

Lab 9 – Change Control and Propagation................................................. 5-39Section 3 – UDAs and Scripts.......................................................................... 5-49

Lab 10 – Object Reuse.............................................................................. 5-79Lab 11 – Averager..................................................................................... 5-87

Section 4 – Extensions and Output Functionality ............................................ 5-99Lab 12 – Extensions................................................................................ 5-103

Section 5 – Additional Application Objects .................................................... 5-109

Module 6 Alarming and History..................................................................6-1Section 1 – Alarming.......................................................................................... 6-3

Lab 13 – Alarming ....................................................................................... 6-9Section 2 – Network Account Utility ................................................................. 6-23Section 3 – Historization .................................................................................. 6-33

Lab 14 – Historization................................................................................ 6-37

Module 7 Securing the Galaxy....................................................................7-1Section 1 – Security Overview ........................................................................... 7-3

Lab 15 – Application Server Security Settings .......................................... 7-13

Module 8 Galaxy Maintenance....................................................................8-1

Industrial Application Server 2.0 Course

iv Industrial Application Server 2.0 Course

Section 1 – Exporting and Importing a Galaxy ...................................................8-3Lab 16 – Exporting/Importing CSV Files....................................................8-13

Section 2 – System Management Console (SMC)........................................... 8-29

Module 9 DAServers and DI Objects ......................................................... 9-1Section 1 – DAServers .......................................................................................9-3Section 2 – DI Objects........................................................................................9-7Section 3 – FactorySuite Gateway .....................................................................9-9

Lab 17 – FactorySuite Gateway................................................................ 9-15Section 4 – Intermittent Network Configuration................................................ 9-25

Module 10 Visualization.............................................................................. 10-1Section 1 – Visualization .................................................................................. 10-3

Lab 18 – Properties Visualization ............................................................10-13Lab 19 – Alarm Connectivity in InTouch ..................................................10-33Lab 20 – Tank System Visualization........................................................10-39Lab 21 – InTouch Tag Connectivity .........................................................10-67

Module 11 Multi-Node Galaxies ................................................................. 11-1Section 1 – Redundancy and Redundant DI Objects.......................................11-3

Lab 22 – Redundancy .............................................................................11-19Section 2 – Converting to a Multi User Galaxy...............................................11-33

Lab 23 – Convert to Network Environment .............................................11-37

Appendix A ArchestrA Licensing ..................................................................A-1

Appendix B FactorySuite Support Tools ......................................................B-1

Appendix C Industrial Application Server Glossary ....................................C-1

Wonderware Training

Module 1

IntroductionSection 1 – Course Introduction 1-3

Section 2 – ArchestrA 1-13

Section 3 – IAS System Requirements 1-21

Section 4 – Architectural Overview 1-23

Section 5 – Installation and Licensing 1-35

1-2 Module 1 – Introduction

Module ObjectiveBe introduced to the FactorySuite Industrial Application Server and understand its architecture, environment, and requirements for installation and licensing.

Wonderware Training

Section 1 – Course Introduction 1-3

Section 1 – Course Introduction

Course OverviewFactorySuite Industrial Application Server is a 4-day instructor led course designed to teach the basic functionality of the Wonderware FactorySuite Industrial Application Server. The purpose of this course is to give students the knowledge necessary to develop applications for their specific environment.

The following modules are included:

Module 1 – IntroductionModule 2 – Application Planning and the Plant ModelModule 3 – The GalaxyModule 4 – Modeling EquipmentModule 5 – Complex Object Modeling – Extending the ObjectsModule 6 – Alarming and HistoryModule 7 – Securing the GalaxyModule 8 – Galaxy MaintenanceModule 9 – DAServers and DI ObjectsModule 10 – VisualizationModule 11 – Multi Node Galaxies

Main Course ObjectiveUpon completion of this course, students should be able to:

Understand how to develop an application using the Industrial Application Server and Work with objects that have been created using the Industrial Application Server Toolkit.

PrerequisitesIt is expected that prior to taking this course the student will have a basic knowledge of InTouch®.

Section Objective

This section will familiarize you with the objectives and agenda for the FactorySuite® Industrial Application Server course as well as the key basics of the Industrial Application Server.



Agenda

Module 1 – IntroductionIntroduction

What is ArchestrA?BootstrapPlatformLMX, NMXToolkits

What is Industrial Application Server?EngineObjects

DISystem(Area)ApplicationAnalog, Discrete

Why use ArchestrA?Global Name Space(example)Advanced Communications Capabilities(example)Pervasive, Flexible Security(example)True Object Methodology

Single point of configuration(alarms,history,security)Reuse of engineering effortChange control/propagation

When to use?Number of I/OArchitecture

Installation / LicensingHardware RecommendationsSoftware RecommendationsLicensing SchemeFS Compatibility

Module 2 – Application Planning and the Plant ModelPlant Modeling

The need for a project workflowunderstanding area devicesidentification of functional requirementsnaming conventions

Wonderware Training


Object Oriented vs. Tag Based Supervisory ControlThe difference between Object Oriented development process and Tag Based development processTypes of objectsobject-oriented tools in manufacturing applicationsPlant Model for Developing (IAS) Course Application

Module 3 – The GalaxyIndustrial Application Server IDE

What is a Galaxy Repository?Selecting a GR Node

What is a Galaxy?Selecting a GalaxyDeleting a GalaxyCreating a Galaxy

Instructor lead – view Galaxy db after createSingle User / Multi User Environment

Lab 1 - Creating a Galaxy

Tour of the IDETool barsViewsImport/ExportConfigure SecurityChange UserChange GalaxySet User PreferencesRight Click – Object Information

AttributesErrors/WarningsCross ReferenceChange Log

Facility ModelingAreas as Logical Groupings of Process

AlarmsEvents

Devices as InstancesDevelop device list

Common Devices as TemplatesImpose standards at this level

Lab 2 – Facility Model



Objects and Object InstancesCreating an Instance (Platform Object)Check Out/ Check InInformation / Warning IconsDeploying / Options - User PreferencesPlatform PropertiesObject ViewerEngine PropertiesArea PropertiesDevice Integration Properties (OPC & SL Proxy)

Lab 3 – Create and Deploy a Platform

Lab 4 – Create and Deploy an Engine

Module 4 - Modeling EquipmentApplication Objects

Analog Device PropertiesDiscrete Device Properties

Lab 5 – DeviceIntegration Object

Lab 6 – Analog Devices

Lab 7 –Discrete Devices – Valve Instance

Module 5 – Complex Object Modeling - Extending the ObjectsObject Relationships

Area (Alarm Modeling)Host (Resource Modeling)Containment (Process Modeling)

Templates

Extending & Enhancing Your Object ModelsUser Defined Attributes

Data Types SupportedExtensions

Input ReferenceOutput ReferenceAlarmHistorize

Lab 8 – Modeling Complex Objects

Object Change Control and PropagationTemplate Property Locking

Propagate on check in

Wonderware Training


Lab 9– Change Control and Propagation

Object ReuseKeywords for Reuse

MeMy HostMy ContainerMy Area

Contained Names

UDAs and ScriptsScript TypesData Types SupportedDim TypesAliasesProperty BrowserFunction BrowserType Browser

Import/Export

Lab 10 – Object Reuse

Lab 11 – Averager

Extensions and Output Functionality

Lab 12 – Extensions

Additional Application Objects

Module 6 – Alarming and History Alarming

What is an Alarm/Event?What types of things are Alarmed?How does ArchestrA handle Alarms?

Platforms alarm to Application Server

Lab 13 – Alarming

Network Account Utility

HistorizationHow does ArchestrA Historize?Engines Historize

InSQL MDASInSQL node does not require any ArchestrA software

Pushed at the engine’s scan rate



Lab 14 – Historization

Module 7 – Securing the GalaxySecurity Models

NoneGalaxyOS UserOS Group

Securing the IDE and SMCCreating Roles – Assigning PermissionsCreating Users – Assigning to Roles

Securing the Objects in RuntimeCreating Security GroupsAssigning Roles to Group Access

Lab 15 – Application Server Security Settings

Lab 16 – Authentication

Module 8 – Galaxy MaintenanceExporting/Importing a Galaxy

As an aaPackage (Object)As a CSV (Galaxy Dump)

Lab 17 –Exporting/Importing CSV Files

Using the System Management Console (SMC)Starting / Stopping Engines and PlatformsBacking up the Galaxy DatabaseThe ArchestrA LoggerNetwork Account Utility

Lab 18 – SMC Operation

Module 9 – DAServers and DI ObjectsDAServers

ConfigurationComponent ArchitectureDAServer Characteristics

DI ObjectsDI Network Objects

Wonderware Training


DI Device Objects

FactorySuite GatewayIntegration to Third Party ApplicationsOther Connectivity Tools

Lab 19 – FactorySuite Gateway

Intermittent Network Configuration

Module 10– Visualization Visualization

InTouch IntegrationTag BrowserData Type SupportLMX, NMX – Client abstraction layer

Lab 20 – Properties Visualization

Lab 21– Alarm Connectivity in InTouch

Lab 22– Tank System Visualization

Lab 23 – InTouch Tag Connectivity

Module 11 – Multi-Node GalaxiesRedundancy and Redundant DI Objects

Lab 24 – Redundancy

Converting to a Multi-User GalaxyExport Tank TemplateUndeploying all Existing PlatformsPointing the IDE to a remote GR NodeDeploy Platforms from remote GRImport Tanks and DeployCheck State of Platform using SMC

Lab 25 – Convert to Network Environment



FactorySuite A2™ Products

The next generation of Wonderware FactorySuite® product line, FactorySuite A2™ products are the first to take advantage of the power and performance of Invensys' new ArchestrA® plant automation and information software architecture. The following FactorySuite A2 products offer increased functionality and flexibility and extensive connectivity:

Industrial Application Server platform for system-wide, real-time data acquisition, alarm and event management, centralized security, data manipulation, remote deployment, and collaborative engineering

InTouch® human-machine interface (HMI) software for process visualization and controlIndustrialSQL Server™ plant data historianInTrack™ resource and WIP tracking softwareInBatch™ flexible batch management softwareInControl™ real-time control softwareDT Analyst™ equipment downtime tracking and performance management software

SuiteVoyager® industrial portal software for Internet/intranet visualization and content managementInTouch for Terminal Services software for remote hosting of InTouch applicationsData Access Servers offering a library of hundreds of I/O servers and DAServers

Wonderware Training


QI Analyst™ using real-time and historical data to monitor, analyze, and predict potentially harmful process variations, allowing for online adjustments for improved production quality and consistencyActiveFactory™ for accelerating and improving decision-making at all levels within the plant through a suite of advanced data analysis clients that leverage data stored in IndustrialSQL ServerSCADAlarm™ event notification software for real-time alarm notification, data acquisition, and remote control from telecommunication devices to industrial automation software systems

This industry-leading toolset features the robust, best-of-breed software modules that help users effectively develop and manage automation applications for continuous, discrete, process, hybrid and batch manufacturing environments. In addition to the usual outstanding features and benefits offered by our traditional FactorySuite modules, the FactorySuite A2 product line takes full advantage of Invensys’ new, ground-breaking Architecture by ArchestrA™. The FactorySuite A2 product line is yet another example of how Wonderware powers intelligent plant decisions in real time.

Industrial Application Server 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:

Integrated development environment Version management License management and centralized deployment System diagnostics and system administration Internationalization Data visualization and monitoring Event based processing, scripting, and calculation capabilities Alarm and event management, historization, and security Data acquisition and field device integration Inter-object communications and name service



Reporting and ad-hoc query capability Support for industry standards such as OPC and SQL

The ArchestrA Framework consists of: Configuration and Deployment Related Components: which include the centralized object repository (called Galaxy Repository), integrated development environment (IDE) and object deployment services (called Bootstrap). These components are installed just like any other 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.

Wonderware Training


Section 2 – ArchestrA

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

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.

Section ObjectivesUnderstand the concept of ArchestrA and how it relates to the manufacturing environment.Understand the benefits of migrating to an ArchestrA architectural environment.



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.

Wonderware Training


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



Manufacturing Collaboration

Plant Intelligence

Production

Supervisory

Plant Floor Connectivity

Wonderware Training


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

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



Wonderware Training

Section 3 – IAS System Requirements 1-21

Section 3 – IAS System Requirements

System Requirements for Industrial Application Server/Galaxy RepositoryTo run the Application Server, the following hardware and software are recommended.

Software Requirements

FactorySuite A² Development seat – IDE with Galaxy Repository (Project Database)Microsoft® SQL Server 2000 Service Pack 4 andMicrosoft® .NET Framework 1.1Microsoft® Internet Explorer 6.0 SP1 andMicrosoft® Windows® Server 2003 or Microsoft® Windows® 2000 Server with Service Pack 4 or Microsoft® Windows® 2000 Advanced Server with Service Pack 4

Important! The Microsoft SQL Server login for BUILTIN\Administrators group must be present and enabled.

FactorySuite A² Development seat – IDE with no Galaxy Repository (Project Database)Microsoft® .NET Framework 1.1 andMicrosoft® Internet Explorer 6.0 SP1 andMicrosoft® Windows® Server 2003 or Microsoft® Windows® 2000 Professional with Service Pack 4 or Microsoft® Windows® 2000 Server with Service Pack 4 or Microsoft® Windows® 2000 Advanced Server with Service Pack 4 or Microsoft® Windows® XP Professional with Service Pack 2

FactorySuite A² Application Server RuntimeMicrosoft® .NET Framework 1.1 andMicrosoft® Internet Explorer 6.0 SP1 andMicrosoft® Windows® Server 2003 orMicrosoft® Windows® 2000 Professional with Service Pack 4 orMicrosoft® Windows® 2000 Server with Service Pack 4 orMicrosoft® Windows® 2000 Advanced Server with Service Pack 4 orMicrosoft® Windows® XP Professional with Service Pack 2

Hardware RequirementsPC with 2 gigahertz (GHz) or higher processor clock speed1 gigabyte (GB) of RAM or higher (512 MB minimum supported; may limit performance and some features)8 gigabytes (GB) of available hard disk spaceSuper VGA (1024 × 768) or higher-resolution video adapter and monitor

Section ObjectivesUnderstand the necessary system requirements for a successful installation



CD-ROM or DVD driveKeyboard and Microsoft Mouse or compatible pointing device

Note:Support for Windows Server 2003Industrial Application Server 2.0 leverages the Microsoft operating system, Windows Server 2003. Version 2.0 of Industrial Application Server has been thoroughly tested on this new OS enabling the user to immediately take advantage of its functionality.

Wonderware Training


Section 4 – Architectural Overview

Architectural Overview Possible architecture configurations that you can create with FactorySuite A2 components include:

Peer-to-peer configurationIn a peer-to-peer configuration, there are several nodes sharing data and eventually running multiple programs on each node. This configuration is intended for medium-sized applications where the processing requirements of each software component can be easily handled by the nodes providing the projected performance support. Client/server configurationIn a client/server configuration, the system is fully distributed. Server components centralize the data collection and processing and provide data to client stations. This architecture facilitates the system maintenance, since all of the configuration data resides in dedicated servers. Terminal services configurationFactorySuite A2 leverages Terminal Services technology. Terminal Services provides the capability to run several sessions of the same InTouch application or different applications in a Terminal Server. Since no programs are required to be loaded on the client station accessing the application, the software and hardware requirements for the client node are minimum.

Note: Industrial Application Server 2.0 has been thoroughly tested and is supported in Domains implementing DHCP servers.

Section ObjectivesBecome familiar with the architecture of ArchestrA under different configurationsBecome familiar with the architecture for the Training course



Configuration Components

Before you explore the different architecture topologies that are suitable in a FactorySuite A2 environment, you should understand the role of the main components in the architecture and how they can be implemented based on requirements and functionality. The main components are:

Configuration Database NodeApplication Object Server NodeVisualization NodeI/O Server NodeEngineering Station NodeHistorian NodeWeb Server Node

A Galaxy consists of the whole supervisory control application, which is a complete system consisting of a single logical namespace and a collection of Platforms, AppEngines, and objects. The Galaxy defines the namespace in which all components and objects reside.

The following network diagram shows a configuration containing FactorySuite A2 components. Use this architecture to identify each component required in any of the recommended topologies.

PLC Network

Visualization NodeVisualization NodeVisualization Node

AppServerAppServer Historian

IO/OPC /DA Server

Engineering StationConfiguration Database

Web Server

Wonderware Training


Configuration Database Node The configuration database node consists of the Galaxy Repository (GR). The Galaxy Repository manages the configuration data associated with one or more Galaxies. This data is stored in individual databases, one for each Galaxy in the system. Microsoft® SQL Server 2000 is the relational database used to store the data.

Technically, the Galaxy Repository can reside on a dedicated node, an Application Object Server node, or an engineering station node.

ApplicationObjects, DeviceIntegration Objects (DI Objects), and System Objects are categorized as Domain Objects. The configuration database node is accessed when an application is created/modified as the Domain Objects are configured or edited. The Galaxy Repository is also accessed when objects are deployed/undeployed on any Platform in the Galaxy.

In normal operating conditions, if Application Object Servers do not require access to the configuration database node, you can combine the configuration database node and engineering station node on a single computer. The configuration database node must be available for the Galaxy when any of the Platforms need to access configuration data in the Galaxy Repository.

If you have large distributed applications, as a practical resource, you could install the Galaxy Repository on a laptop computer and carry it to remote sites in order to maintain applications. To expedite the process of deploying/undeploying objects and creating and configuring templates, you could connect the portable configuration database node to the local node via a dedicated LAN connection.

If the Galaxy Repository is not available on the network, existing objects cannot be deployed or undeployed to/from any Platform in the Galaxy.

Configuration and run-time components for a configuration database node are described in the following table:

Application Object Server Node The Application Object Server provides the processing resources for AppEngines, Areas, ApplicationObjects, and DeviceIntegration (DI) Objects.

The Application Object Server node requires a Platform to be deployed. The Application Object Server can also run other objects, such as AppEngines, Areas, DeviceIntegration Objects, and ApplicationObjects.

Depending on the process requirements and system capabilities, the functionality of an Application Object Server node can be combined with a visualization node. A peer-to-peer topology takes advantage of this type of configuration to provide flexibility to the system.

Configuration Components Run-Time Components Integrated Development Environment (IDE)Galaxy Repository*Microsoft SQL Server 2000*

Bootstrap (Base installed)Platform (Deployed)



Configuration and run-time components for an Application Object Server node are described in the following table:

Visualization Node A visualization node is a computer running InTouch 9.0 SP2 or higher on top of a Platform. The Platform provides for communication with any other Galaxy component via the Microsoft Message Exchange (MX) protocol.

Configuration and run-time components for a visualization node are described in the following table:

I/O Server Node An I/O Server node functions as the data source for the Industrial Application Server system. Running on this node are I/O data servers that can communicate with external devices. Communication protocols supported by the system are DDE, SuiteLink, and OPC.

On the Industrial Application Server side, DeviceIntegration Objects manage the communication between ApplicationObjects and the I/O data servers.

DeviceIntegration Objects require a Platform and an AppEngine to be deployed. These objects can reside either on the I/O Server node or on any Application Object Server node in the Galaxy. If the DeviceIntegration Objects run on the I/O Server node, then a Platform is required to communicate with any other Platform in the Galaxy.

Configuration and run-time components for an I/O Server node are described in the following table:

Configuration Components Run-Time Components Integrated Development Environment (IDE) Bootstrap (Base installed)

Platform (Deployed)Application Engine (Deployed)Areas (Deployed)ApplicationObjects (Deployed)DeviceIntegration Objects (Deployed)

Run-Time ComponentsBootstrap (Base installed)Platform (Deployed)InTouch 9.0 SP2 or higher OR InTouch View 9.0 SP2 or higher (Base installed)

Configuration Components Run-Time Components System Management Console (SMC) Bootstrap (Base installed)

Platform (Deployed)Application Engine (Deployed)IO/DA/OPC Server (Deployed)

Wonderware Training


Engineering Station Node All of the recommended topologies include a dedicated engineering station for maintenance purposes. The engineering station node contains an Integrated Development Environment (IDE) and InTouch WindowMaker. (These development tools are provided with a FactorySuite A2 development package.)

The configuration database could reside on this node. Thus, you could implement any required changes in the system from the engineering station node using the IDE, which would then access the local configuration database. This configuration provides you flexibility in maintaining remote sites, as you can use a laptop computer as the engineering station and configuration database node and gain access to the Application Object Server node via a LAN connection. If you need to deploy or undeploy large applications, network traffic in the Galaxy would not be affected.

The engineering station node also hosts the development tools to modify InTouch applications using WindowMaker.

Configuration and run-time components for an engineering station node are described in the following table:

Historian Node The historian node is used to run IndustrialSQL Server. IndustrialSQL Server stores all of the historical data and also provides real-time data to clients such as ActiveFactory, SuiteVoyager, and so on.

The historian node does not require a Platform. The Application Object Server pushes the data to be historized to the IndustrialSQL Server using the manual data acquisition service (MDAS).

Note: MDAS uses DCOM to send data to IndustrialSQL Server. For both the MDAS and IndustrialSQL Server computers, make sure that DCOM is enabled (not blocked) and that TCP/UDP port 135 is accessible. The port may not be accessible if DCOM has been disabled on either of the computers or if there is a router between the two computers that is blocking the port.

For most applications, it is recommended that you combine the historical and alarm database on the same node sharing the data storage system. Configure the alarm system using the Alarm Logger utility, which creates the appropriate database and tables in Microsoft SQL Server. For requirements and recommendations for this configuration, see Alarms and Events.

Configuration and run-time components for a historian node are described in the following table:

Configuration Components Run-Time Components IDESMCBootstrap (Base installed)

InTouch WindowMaker 9.0 SP2 or higher

Configuration Components Run-Time Components Microsoft SQL Server 2000*

* Required component

IndustrialSQL SQL Server 8.0 or higher (Base installed)



Web Server Node A web server consisting of SuiteVoyager Server could be included in any Galaxy. You can use the Win-XML Exporter to convert InTouch windows to XML format, so that SuiteVoyager clients can access real-time data from the Galaxy.

In order to provide the means for the SuiteVoyager Server to access the Galaxy, a Platform is required to be deployed on the web server node.

Peer-to-Peer Configuration A peer-to-peer configuration combines different components on the same computer, allowing the visualization and Application Object Server functionality to coexist in the same node (called a workstation).

The following network diagram illustrates the software components and their distribution in the configuration.

Client operating systems such as Windows XP Professional can manage up to 10 simultaneous active connections with other nodes.If the system is larger than 10 nodes, Windows 2003 Server must be used for all nodes.

WorkstationIn this configuration, the visualization and Application Object Server are combined on the same node. Both components share the Platform, which handles communication with other nodes in the Galaxy. The Platform also allows for deployment/undeployment of ApplicationObjects.

Run-Time Components Bootstrap (Base installed)Platform (Deployed)SuiteVoyager 2.0 SP1 or higher (Base installed)

PLC Network

HistorianWorkstation Web ServerEngineering StationConfiguration Database

IO/DA/OPC Server

Workstation

Wonderware Training


If you are planning to combine the visualization and Application Object Server on the same node, you should consider the amount of resources that each component would require to operate. On the visualization side, consider the number of active tags per window, ActiveX objects displayed, alarm displays, and history trending. The implementation of features such as these could require a considerable amount of resources from the computer and may impact the performance of the Application Object Server running on the same node.

I/O, OPC, and DA ServersI/O Server applications do not require a Platform. They can reside on either a stand-alone node or a workstation node. However, DI Objects such as the DDESuiteLinkClient object, OPCClient object, and InTouchProxy object are required to be deployed to an AppEngine on a Platform. These generic client objects are not required to be installed on the same node as the data server(s) they connect to. The objects can connect to the servers locally or remotely.

The DDE SuiteLinkClient object, OPCClient object, and InTouchProxy object are DI Objects that obtain data from any I/O data server using DDE, SuiteLink, and OPC protocols, as well as data from InTouch legacy systems. For DAServer-specific objects (for example, ABCIP DINetwork object, ABTCP DINetwork object, and so on), both the DAServer and corresponding DI Objects must reside on the same computer hosted by an AppEngine.

The following diagram illustrates the combination of I/O Servers on the workstation node:

If you install I/O Servers on separate nodes without the DIObjects on the same computer, you should use dedicated Network Interface Cards (NICs) to manage the communication between the I/O Server node and the Application Object Server. This configuration is recommended when a failover strategy is required at the I/O Server level. For more information, see I/O Server Redundancy.

Client operating systems such as Windows 2000 Professional and Windows XP can manage up to 10 simultaneous active connections with other nodes. If the system is larger than 10 nodes, Windows 2000 Server must be used for all nodes.

PLC Network

Historian Web ServerEngineering StationConfiguration DatabaseWorkstation

I/O ServerWorkstationI/O Server



HistorianThe IndustrialSQL Server must run on its own computer, collecting historical data from any workstation in the Galaxy and providing it to client applications.

Engineering Station and Configuration Database The engineering station node hosts the IDE and InTouch WindowMaker to allow for maintenance of the Industrial Application Server and InTouch applications.

As a configuration database node, it contains the SQL Server database that stores the configuration data for the Galaxy.

Web Server A web server node running SuiteVoyager Server provides real-time and historical data to clients over the web.

Client/Server Configuration A client/server configuration includes dedicated computers running Application Object Servers, while visualization tasks are performed on separate computers. This architecture optimizes usability, flexibility, scalability, and system reliability.

The client components (represented by the visualization nodes) provide the means to operate the process with applications that are mainly providing data updates to process graphics. The clients have a very light load of data to process.

The Application Object Servers share the load of data processing, alarm management, communication to external devices, security management, and so on.

Wonderware Training


The following network diagram illustrates a client/server configuration:

This architecture can be scaled to include a greater number of servers, if required for increased data processing and a higher load of I/O reads/writes. The number of clients could also be increased if additional operator stations are needed.

Terminal Services Configuration You can leverage Terminal Services technology in a FactorySuite A2 architecture. Terminal Services allows for the communication of thin client computers to a Terminal Server node, where multiple instances of InTouch applications run simultaneously.

A dedicated Terminal Server node is recommended for this configuration. This node requires the following software components:

The Terminal Server node should be configured in Application Server mode for Terminal Services.

Only one Platform runs in a Terminal Server node, regardless of the number of sessions executed. However, the number of sessions affects the size of the license for the system.

You should consider different options when using Terminal Services, such as whether to run Terminal Services on the same node as the Application Object Server or on dedicated computers.

Run-Time Components Bootstrap (Base installed)Platform (Deployed)Terminal Services for InTouch 9.0 SP2 or higher (Base installed)

PLC Network

Visualization NodeVisualization NodeVisualization Node

AppServerAppServer Historian

IO/OPC /DA Server

Engineering StationConfiguration Database

Web Server



Training ArchitectureFor the purposes of this training class the architecture will initially be structured in a Standalone configuration. Later in the class the architecture will be modified to reflect a networked configuration to convey more complex concepts relating to connectivity, exporting objects and templates and other multi-node environmental considerations (see the following diagrams).

Hardware and Associated Software

Application Server

Galaxy Repository

InTouch Station

Standalone Configuration

Present on each machine

BootstrapIDE

InTouch 9.0Galaxy Repository (GR)

Contains

Contains

Contains

PLCBootstrap

IDEInTouch 9.0

Galaxy Repository (GR)

BootstrapIDE


BootstrapIDE


BootstrapIDE


BootstrapGalaxy Repository (GR)

BootstrapInTouch 9.0

Wonderware Training


Networked ConfigurationIn the networked architecture a common Galaxy Repository will be shared between a set of PCs. It will allow multiple users to simultaneously work on the same application. The architecture is illustrated in the following diagram.

Note: To better facilitate the clarity of individual work in this training environment, because of the Global Naming Space, ALWAYS preface the object name with your FIRST and LAST initial.(e.g., if the user is John Burns, Valve would be JBValve)

PLCBootstrap

IDEInTouch 9.0

BootstrapIDE

InTouch 9.0

BootstrapIDE

InTouch 9.0

BootstrapIDE


Application Object Server ,Galaxy Repository, and

InTouch

Industrial Application Server and InTouch

Galaxy 1 Node4G1N4

Galaxy 1 Node3G1N3

Galaxy 1 Node2G1N2

Galaxy 1 Node1G1N1



Wonderware Training


Section 5 – Installation and Licensing

InstallationIndustrial Application Server is the next generation architecture for Supervisory Control and Manufacturing Information systems. It is an open and extensible system of components based on a distributed, object-oriented design.

This section describes how to install one or more components of the Industrial Application Server infrastructure including the main configuration tool, the Integrated Development Environment (or IDE), and how to configure a Galaxy. Although the installation process is very straight-forward it is beneficial in illustrating the procedure.

The Industrial Application Server installation routine includes options for installing all components of the system or just individual ones. These include:

Bootstrap IDE Galaxy Repository

To begin the Industrial Application Server installation, the CD is inserted into the appropriate CD drive. The Welcome dialog box will appear.

The Industrial Application Server requires Microsoft .NET Framework. If this has not been installed on your machine you will see the following prompt for its installation:

Clicking OK will initiate the Microsoft .NET Framework installation.

Once the Microsoft .NET Framework is installed, installation of Industrial Application Server can continue.

Section ObjectivesUnderstand the necessary system requirementsInstall the product and Configure the Galaxy.



If the installation does not auto start, then double click on the Setup.exe file to initiate the install.

Clicking Next to continue the installation causes the Licensing Agreement dialog box to appear.

A printout of the License Agreement is available by clicking Print License. Doing so opens the License Agreement in Notepad, from which you can print the document.

Selecting the ‘I accept the License Agreement’ option and clicking Next to accept the terms of the license agreement causes the Wonderware Industrial Application Server Setup dialog box to appear.

Wonderware Training


Note the important information provided in the Feature Description box as you select individual features.

Clicking the icon next to the feature causes the following options to be presented. The options presented for the Bootstrap feature are as follows:

The options presented for all other features are as follows:

These options are provided since not all nodes will necessarily have the IDE or the Galaxy Repository residing locally. The Bootstrap feature, however, is required for all installations.

The default destination is the \Program Files\ArchestrA folder. Clicking the Browse button allows you to designate a destination target for the installation other than the default location



Clicking the Disk Cost button displays the Disk Cost dialog box:

Use the Disk Cost button to determine the best location for the installation, depending on the space on available drives.

Clicking the Reset button on the Selected Features dialog box changes all screen choices to the default settings.

Selecting the Installation Guide button will activate the information pertaining to installation and setup.

Clicking Next to continue initiates the dialog box for verification of the Prerequisites.

If a Prerequisite is not present the following dialog boxes will appear:

Wonderware Training


Once the prerequisites have been satisfied, the Industrial Application Server installation can continue.

Clicking Next to continue initiates the Install.



This dialog is a progress indicator that provides visual and textual information about the file copying and system configuration activities going on. It also provides a time estimate for finishing this part of the installation routine.

Wonderware Training


Once the installation is complete the following dialog box appears:

This dialog alerts you that installation has successfully completed.

Observe the status of the Launch Application Server IDE checkbox. If you leave it checked (the default setting), the IDE is launched immediately.

Clicking the View Readme button will allow you to read the product Readme file.

When the Industrial Application Server opens there will be a prompt to connect to a Galaxy. If an attempt is made to connect with a Galaxy that was created with an earlier version of Industrial Application Server the following prompt will appear:

Clicking Yes will allow all the data in the older Galaxy version to automatically be migrated to the new version.



Licensing

Note: A detailed License Guide for the Industrial Application Server is provided as an Appendix to this manual, see Appendix A, “ArchestrA Licensing”.

Access to the Galaxy Repository is controlled by a license. If a license-related message is displayed when you are attempting to open the IDE, you have a problem with your license. This message may indicate one of the following conditions:

No license has been installed.Your license has expired.You may have exceeded the licensed I/O count or number of WinPlatforms.

Use the License Utility to correct these problems. Until the problem is resolved, you cannot: Open the IDE.Connect to existing Galaxies.Create new Galaxies.

After you have updated your license, you should be able to connect to your Galaxy and open the IDE with no further problems.

Note: If a license expires while you are using the IDE, you are not allowed to connect to the Galaxy the next time you open the IDE.

To check your current license, expiration date (if any) and limitations (if any), double-click the License icon at the bottom of the IDE’s Main Window to open the License Information dialog box.

Wonderware Training


The License Information dialog box is comprised of the following options: Galaxy Client Access License group

Number: License number.Vendor: Name of software vendor.Product Text: The software name and version number.Expiry Date: Expiration date for your license.Notice Text: Information about the software vendor.

Platform groupCurrent Count: Number of deployed WinPlatforms in your Galaxy.Max Count: Maximum number of deployed WinPlatforms allowed by your license.Status: Relationship between the current and maximum WinPlatform count values.

IO Point groupConfigured Count: Number of configured I/O points in your Galaxy.Max Count: Maximum number of configured I/O points allowed by your license.Status: Relationship between the configured and maximum I/O point count values.



Wonderware Training

Module 2

Application Planning and the Plant ModelSection 1 – Plant Modeling 2-3

Section 2 – Object Oriented vs. Tag Based Supervisory Control 2-9

2-2 Module 2 – Application Planning and the Plant Model

Module ObjectiveUnderstand the concept and need of developing a Plant Model before configuring the Industrial Application ServerBecome familiar with key factors necessary for building successful applications.

Wonderware Training

Section 1 – Plant Modeling 2-3

Section 1 – Plant Modeling

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

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

Suggested Project WorkflowJust as there are many different criteria for FactorySuite A2 projects, there are many different ways to design and implement a supervisory and control system. The suggested project workflow is designed to help you plan and implement your projects. By providing this workflow, we intend to ease your work and facilitate the completion of the project. 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 ObjectivesUnderstand the need for a project workflow, an understanding of area devices, identification of functional requirements and naming conventionsUnderstand the concept of ArchestrA and how it relates to the manufacturing environment.Understand 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.

The following diagram shows a simple P&ID:

Wonderware Training


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 ArchestrA IDE, references are created using this naming convention:

<objectname>.<attributename>

For example:

YY123XV456.OLS

� ��

��

��

��

��

�� !"

�� !"#��$

�� !"#��$

�� !"#��

�� !"#��%

�� !"#&��

'��$

'��$

'��

'��%

'&��

For more information refer to the InTouch to IAS Migration document

Wonderware Training


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 Dispatch Area. You will need to define and document all of the Areas of your plant that will be part of your application.

Each object will need to be assigned to a particular Area. When you install the Industrial 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.

Object 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 IDE to create instances from templates.

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



Wonderware Training


Section 2 – Object Oriented vs. Tag Based Supervisory Control

IntroductionThere 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, and then a script is executed to switch the tags being viewed in run-time. Furthermore, because of the flat structure of the application, changes need to be sought out and analyzed as to the affect on the rest of the application.

Use of the word "Object-oriented" with 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 Databases

Section ObjectivesUnderstand how Object Oriented relates to SCADAUnderstand the difference between Object Oriented development process and Tag Based development process

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



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

Wonderware Training


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.

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 lastThe Industrial Application Server and the ArchestrA Integrated Development Environment (IDE) have brought a new era to SCADA Software development through the ability to create a complete plant device model. The developer is abstracted from the complexities of the computing environment and allowed to concentrate on "modeling" how the production facility is laid out and the different manufacturing cells and processes that comprise plant-wide supervisory control. Once the plant model is captured, it is easy to implement supervisory control functions. A small investment in creating Templates yields big results in engineering productivity. The ten easy steps to creating a supervisory application using the Industrial 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.

Wonderware Training


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

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.



1_PV

Plant Model for Developing (IAS) Course ApplicationIn this course, the manufacturing environment that we will be modeling centers on a Plant with various Tanks and assorted Tank related components. We will initially focus on one Area of the Plant and model that Tank System in the Integrated Development Environment (IDE) of the Industrial Application Server (IAS). Templates will then be developed which will allow for the simple creation of multiple instances of our Tank System.

The following Figure illustrates the Tank System Model that will be created in the application developed throughout the course of this class.

Transfer Pump

TransferPump 01_CmdStartTransferPump 01_AuxContact

TANK

TANKXXYXX = Student # {01,02,03…}Y = Tank # {0,1}

Tank Level

Inlet Valve

Outlet Valve

LIT0

Valve02_CLSValve02_OLSValve02_CmdOpen


Wonderware Training

Module 3

The GalaxySection 1 – The Galaxy 3-3

Lab 1 – Creating a Galaxy 3-5

Section 2 – Tour of the IDE 3-11

Section 3 – Facility Modeling 3-31

Lab 2 – Facility Model 3-33

Section 4 – Objects and Object Instances 3-37

Lab 3 – Create and Deploy a Platform 3-43

Lab 4 – Create and Deploy an Engine 3-55

3-2 Module 3 – The Galaxy

Module ObjectiveObtain an understanding of Galaxy and the Integrated Development Environment (IDE)Understand Plant Modeling as it relates to Objects and Object Instances

Wonderware Training

Section 1 – The Galaxy 3-3

Section 1 – The Galaxy

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

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

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

Creating a GalaxyEach IDE session requires connection to a specified Galaxy. In other words, the IDE cannot be started in a Galaxy-neutral state. When you attempt to start the 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

Section ObjectivesObtain an understanding of what a Galaxy is and how it relates to the Galaxy Database and the Galaxy RepositoryUnderstand how a Galaxy is created



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 IDE, you must either browse for a Galaxy on another node or create a new Galaxy.

All new Galaxies are created with no security. They also have the following characteristics: two users (DefaultUser and Administrator, both with full access to everything), two security roles (Default and Administrator, both with full privileges) and one security group (Default).

If you previously created one Galaxy on the GR node shown, the Galaxy’s name is automatically shown. Click Connect to start the 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 IDE and to connect to that Galaxy.

Wonderware Training


Lab 1 – Creating a GalaxyIntroductionThis lab will illustrate the steps necessary to create a Galaxy and enter the Integrated Development Environment (IDE).

ObjectivesUpon completion of this lab the student should be able to:

Create a Galaxy.Re-enter the Galaxy.

Note: To better facilitate the clarity of individual work in this training environment, because of the Global Naming Space, ALWAYS preface the object name with your FIRST and LAST initial.(e.g., if the user is John Burns, Valve would be JBValve)



Creating a GalaxyOnce we have the Industrial Application Server IDE installed we cannot use it until we create the Galaxy. Launch the IDE by selecting Start/Programs/Wonderware/ArchestrA IDE. When initially launching the IDE we will be prompted for a Galaxy connection. This will display the following Connect to Galaxy dialog box

1. Select the Galaxy Node Name or browse to it using the icon.

Then select a Galaxy Name. Since there is no Galaxy Name available from the drop down list then click the New Galaxy button to create one.

The New Galaxy dialog box appears:

2. Enter the Galaxy Name for the Galaxy.

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

Wonderware Training


In the Galaxy Name field type in a name. For this training environment we will use XYGalaxy. utilizing the naming convention of XY representing your first and last initials. This is the database name so including the word Galaxy in the name will enhance reference efficiency.

3. Click Create to continue.

This will bring up a dialog box that indicates the process of creating the new Galaxy.

As soon as this process completes, the Connect To Galaxy dialog box with the Galaxy Name displays.



4. Click Connect. This will close the Connect to Galaxy dialog box and display the IDE.

Re-entering a Galaxy5. To re-enter the IDE after it has been configured, navigate to the IDE through the Start/

Programs/Wonderware/ArchestrA IDE

Wonderware Training


6. The Connect to Galaxy dialog box displays where you can select a particular Galaxy.

7. After an initial Galaxy has been created, additional Galaxies can be created from the IDE menu as follows:

In the IDE, select Galaxy/Change Galaxy.

The Connect To Galaxy dialog box appears where an additional Galaxy can then be created.



Wonderware Training


Section 2 – Tour of the IDE

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

Using the 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 IDEs.

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

Key Functions of the 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

Section ObjectivesFamiliarize you with the IDE environment, and Enable you to orchestrate the operation of additional functionality.



IDE ConfigurationSet user preferencesCreate a Tool Box

As we identify and discuss the main aspects of the IDE Main View (e.g., Menu options, Toolbars, Template Toolbar and Application Views, etc.) we will elaborate in greater detail how these Key Functions can be used

The IDE User Interface

Main View

The Main Window of the IDE is composed of the following components:Title barMenu barToolbarTemplate ToolboxApplication ViewsObject Editor Client AreaStatus bar

When you first log in to the 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.

Wonderware Training


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

Menu BarThe 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.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 IDE, this command opens the 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 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 IDED settings. This menu includes the following commands:

Wonderware Training


Application View – For bringing focus to the Application Views part of the Main Window.Template Toolsets – For bringing focus to the Template Toolbox part 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.See separate section for additional information regarding this feature.Status Bar – For toggling on/off the Status Bar of the Main Window.

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 3-18 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 IDE Help menu includes the following commands:

Help Topics – Standard Help command, used for opening the 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.

Wonderware Training


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.

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 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 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 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 check 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 IDE. Using this command opens the Configure User Information dialog box.

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

Template Toolbox – For toggling on/off the Template Toolbox part of the Main Window.

Application Views – For toggling on/off the Application Views part of 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 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 IDE is first launched. Subsequent 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.

Galaxy Name

Wonderware Training


The top of the tree will be the GalaxyObject, This will be 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.

Deployment ViewThe 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 ApplicationEngine. Also, an ApplicationEngine 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 will contain all templates and instances. The tree will be displayed in alphabetical order at each level within the tree.

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

Wonderware Training


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.

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:

Icon DescriptionUndeployed (see AnalogDevice_001 and DDESuiteLinkClient_001 in example above)

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

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



Configuration status indicators include:

Redundancy status indicators include:

Checking Out/Checking In ObjectsUsers of the 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 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 will appear 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 IDE.

To check out unreserved objects

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

b. On the Object menu, click Check Out.

Icon DescriptionConfiguration warning

Configuration error

(no indicator) Configuration good

Icon DescriptionAppEngine undeployed, its redundant pair not undeployed.

AppEngine deployed, its redundant pair not deployed.

Wonderware Training


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

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.

Wonderware Training


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

Uploading Runtime Configuration to GalaxyChanges to certain attributes (Writeable_UC, Writeable_UC_Lockable, Writeable_USC, Writeable_USC_Lockable) can be made in the configuration environment and then later changed at runtime. As a result, the values of these attributes can differ between the runtime and configuration environments.

You can upload runtime configuration changes to the Galaxy database so that the attribute values in the database match those in the runtime. This feature provides the advantage that if the uploaded object is ever redeployed, or undeployed and then deployed, its runtime configuration changes are deployed with it.



To upload runtime configuration to the Galaxy

a. Select the object in the Model or Deployment View. Multi-select is allowed with Shift+Click or Ctrl+Click. For instance, you could select an entire hierarchy from AppEngine down.

b. On the Object menu, click Upload Runtime Changes. The runtime attributes of the selected objects are copied over those in the Galaxy database.

If you choose an object that is currently checked out to you, a warning is displayed during runtime upload. If you choose to 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 runtime attributes are copied to the Galaxy database.

Note: Performing this function on objects checked out to other users is not allowed.

Objects whose configuration has been successfully uploaded have a new version number and a change log entry for the upload operation. The runtime object’s version number also has a new version number, and that version number matches the version in the configuration database.

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

Wonderware Training

Section 3 – Facility Modeling 3-31

Section 3 – Facility Modeling

Modeling of the FacilityWith the ArchestrA Industrial 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 standards.Deploy applications across multiple plants or projects.

This provides universal application development capabilities. Additionally, it provides the ability to build industrial applications that ensure consistent engineering quality and operational best practices.

Section ObjectivesUnderstand the importance of having a model of the plant facility.Understand the concept of how to utilize ArchestrA Industrial Application Server to model a specific facility.

SectionPlant Production Line

Area Manufacturing Cell



Wonderware Training


Lab 2 – Facility Model

IntroductionWhen you begin to consider an industrial automation job, the first thing you are presented with is the physical layout of the plant. This is the stage where the plant tour occurs and a list of process facilities identifies who is responsible for what and how alarms, events and data is transferred throughout the plant. Industrial Application Server facilitates this stage with the Area object and the Model View environment.

This lab will illustrate the steps necessary to model your facility by creating a Plant area with additional areas called Intake, Discharge, Production, Line1 and Line2. Since we are modeling our plant the views will be solely from the Model View.


Create instances of Areas.Rename the Areas and organize them in a way that models the facility.

Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.(e.g., if the user is John Burns, Valve would be JBValve) This will eliminate problems when we deploy our objects in a common galaxy later in the course.



Tasks

Create Area Instance1. Select the Model View pane.

2. Drag and drop the object $Area from the Template Toolbox to the Application View to create an instance of an Area.

Once the instance has been created it will display as follows:

Notice we are looking at the Model View.

Wonderware Training


3. Create five (5) more instances of an Area so that there are a total of six (6) Areas.



4. Rename the Areas as PlantIntakeProductionDischargeLine1Line2

Remember to use the naming convention discussed earlier.

5. At this point we will organize the Areas in a way that more accurately reflects the model of our facility.Drag and drop each of the Areas so that hierarchy appears in the following order:

Plant

Discharge

Intake

Production

Line1

Line2

6. Now add an additional Area, rename it XYSystem (where X and Y are your first and last initial respectively). We will place the XYSystem area at the same level as the Plant Area.

Wonderware Training


Section 4 – Objects and Object Instances

TerminologyThis section contains a description of key terms to facilitate the ease of reference to the various aspects of ArchestrA and AppServer in particular. These are categorized by Product Names and Component Names.

Product NamesArchestrAObject Toolkit (AppObject Toolkit)– a programmer’s tool used to create new ApplicationObjects Templates, including their configuration and run-time implementations. In addition, it is the toolkit for Device Integration Solutions primarily for use with the Application Server system. This toolkit includes the Data Access Server and the ApplicationObject Toolkit, enabling the user to create the:

1. DINetwork Object

2. DIDevice Object

Application Server (AppServer) – This is the product name given to the new Wonderware FactorySuite A2 Application Server, which will run the objects as a blind node, allowing a product to be loaded on top of existing systems to extend value. This product has an execution engine (app eng) which hosts the application objects performing the functionality, and then stores this into a history storage system, which is also included in the product.

ArchestrA Data Access Server Toolkit (DAS Toolkit) – This is the toolkit for building Data Access Servers, which are the next generation of I/O servers, and are the I/O server executable. These are OPC servers, and this toolkit is to be a product which enables Wonderware and third parties to develop powerful OPC servers which could go to third party clients and Application Server clients.

Data Access Server (DAServer) – Refers to the Server executable that interfaces to the device serving data to the DINetwork Object and DIDevice Object, via standard client protocols OPC, or to any third party client. These replace our current I/O Servers.

Components of a DAS Toolkit:Client Plug-ins: These are the components which are added to a DAS server to enable communication with clients. Examples are: OPC 2.03, DDE/Suitelink, etc.DAS Engine: This is the .DLL which contains all the common logic to drive data access (this used to be called “Core toolkit”).Device Protocol: This is custom code set up by the user to define the communication with a particular device. DAS Control Client: This is the MMC snap-in supplied with the DAServer that provides the necessary UI for activation and configuration.

Section ObjectivesUnderstand the terminology associated with the various objects in the IDE.Understand the various types of objects utilized in the IDE.Become familiar with when and how they are used.Understand how to create and configure instances of objects.



DAS Diagnostic: This is part of the DAS Control Client MMC snap-in-that provides a set of diagnostic information for DAServers within the systemDAS Configuration: This is part of the DAS Control Client MMC snap-in which enables configuration of the DAServer either locally or remotely.DAS Activation: This is part of the DAS Control Client MMC snap-in which enables the user to start and stop the DAServer.

DAS AppWizard: This is the C++ Wizard that generates the framework of the DAServerGeneric State Engines: These are engines which enable the device protocol developer to build the particular functions:

Device Engine Serial EngineTCP/IP Engine

Component NamesArchestrA AutomationObject Toolkit – This is the toolkit for developing core ApplicationObjects, in a C++ environment, which will be imported into the Galaxy via the IDE.

Area AutomationObject – the AutomationObject that represents an Area of a plant within an Application Server Galaxy. The area object acts as an alarm concentrator and is used to put other AutomationObjects into the context of the actual physical automation layout.

ApplicationEngine (AppEngine) – a real-time Engine that hosts and executes AutomationObjects.

ApplicationObject – An AutomationObject that represents some element of a user application. This may include things such as (but not limited to) an automation process component (e.g. thermocouple, pump, motor, valve, reactor, tank, etc.) or associated application component (e.g. function block, PID loop, Sequential Function Chart, Ladder Logic program, batch phase, SPC data sheet, etc.).

AutomationObject – A type of Object that represents permanent things such as hardware, software or Engines as objects with a user-defined, unique name within the Galaxy. It provides a standard way to create, name, download, execute or monitor the represented component.

ContainedName – This is the final portion of the HierarchicalName that defines the name of the object within that containment level, i.e. HierarchicalName = Line1.Tank1.InletValve, TagName = V1101 ContainedName = InletValve

Device Integration Objects (DIObject) – AutomationObjects that represent the communication with external devices, which all run on the application engine local. The objects for example are:

DINetwork Object – Refers to the object that represents the network interface port to the device via the Data Access Server, providing diagnostics, and configuration for that specific card.DIDevice Object – Refers to the object that represents the actual external device (e.g. PLC, RTU) which is associated to the DINetwork Object. Providing the ability to diagnose, browse data registers, and DAGroups for that device.

Framework – An infrastructure consisting of a common set of services, components and interfaces for creating and deploying Automation objects that collect, store, visualize, control, track, report and analyze plant floor processes and information.

Galaxy – complete Application Server system consisting of a single logical name space (defined by the Galaxy Repository) and a collection of Platforms, Engines and Objects that are included within it. One or more networked PC’s that constitute an automation system. It defines the name

Wonderware Training


space that all components and objects live in and comply with a common set of system level policies. This is the whole application.

GalaxyDatabase – the relational database containing all persistent configuration information for all Templates and Objects in an Application Server Galaxy.

GalaxyRepository – the software sub-system consisting of the Galaxy Repository Engine, Package Server, Repository Interface, and the Galaxy Database.

HierarchicalName – This is the name that is created by the system that positions the object within any containment i.e. HierarchicalName = Line1.Tank1.InletValve, TagName = V1101

Integrated Development Environment (IDE) – The IDE is an Integrated Development Environment consisting of various configuration editors that are used to configure the total system, aimed for the application engineer, and general use.

Objects – AutomationObjects (all types), AutomationObject, UserProfiles, Displays, Symbols, DisplaySets, ActivityObjects are collectively referred to as Objects. Common characteristic of all Objects is that they are stored as separate components in the GalaxyRepository.

ObjectTemplate – a specific state of an Object in which the Object is a generic template from which instances can be generated.ObjectInstance – a specific state of an Object in when the Object has been substantiated to the actual unique instance of the object that will run in the system.

Platform Object– a representation of the physical hardware that the Application Server software is running on. Platform Objects host Engine Objects (see WinPlatform).

QuickScript .NET – this is the name of the scripting language component that is an enhanced version of InTouch QuickScript with new language features and integration with Microsoft® .NET.

System Management Console (SMC) – This is the central runtime system administration / management user interface, where all required runtime administration functions like new users, redeployment, license management will occur.

TagName – This is the unique name given to a Object. i.e. HierarchicalName = Line1.Tank1.InletValve, TagName = V1101

WinPlatform – a single computer in an Application Server galaxy consisting of Network Message Exchange, a set of basic services, the operating system and the physical hardware; hosts Application Server Engines and is a type of Platform Object.

ObjectsSome of the primary objects that are integrally a part of the Integrated Development Environment (IDE) in AppServer are the:

WinPlatform ObjectAppEngine ObjectArea ObjectAnalogDevice ObjectDiscreteDevice ObjectFieldReference ObjectSwitch ObjectUserDefined Object



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

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

Wonderware Training


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

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 - 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 we are looking at the Deployment View.




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

Creating an Instance - 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


Lab 3 – Create and Deploy a Platform

IntroductionAt this point in the modeling process, you need to think about the physical architecture as well as alarm/event reporting. A platform object represents a physical entity and we will have to go into Deployment View when we are ready to allocate this physical piece of equipment. However we always start in Model View as we are organizing our objects in alarm groups and associating process entities as they are associated in the process environment.

This lab will illustrate the steps necessary to create a Platform instance from the Template Toolbox, configure the objects and deploy them.


Create an instance of the Platform.Configure the instance of the objects using the object editor.Deploy the instances.Save and close the editor.




Tasks

Create Instance of the Platform1. Select the Model View pane.

2. Drag and drop the object $WinPlatform from the Template Toolbox to the Application View to create an instance of a Platform.

Notice we are looking at the Model View

Wonderware Training



3. Rename the object as XYPlatform. Remember to use the naming convention discussed earlier.




At this point we will work with XYPlatform and configure it.

4. Double-click on the XYPlatform to open the Editor.

There is nothing to configure at this point. The Network Address is to be the name of the computer where we want to deploy the platform. This is the first Platform created so it will pick up the Node Name by default. Any subsequent platforms that are created will need to have the Network Address configured.

Accept the default values for the other parameters

Wonderware Training


5. To properly close an editor when no changes were made, or when the changes made are to be discarded, it is better to use the X Close button (the lower one) than the ‘Save and Close the editor’ button.

6. In the Model View, assign the Platform to the System Area.

Deploying the Object7. Go to the Deployment View. Right-click on the Platform object and select Deploy.



8. Verify the Initial Scan state is set to OnScan and click OK.

9. Click Close to close the dialog box once deployment is complete.

The Application Views will now display the object in its deployed state.

Wonderware Training


Using the Object Viewer - Platform10. Open the Object Viewer by right-clicking on the Platform and selecting View in Object

Viewer.

Or

Select Object/View in Object Viewer from the Object menu.



Upon opening the Object Viewer tool we can see the three panes comprising the layout.

11. Right-click in the Attribute Monitoring section and select Rename Tab.

Attributes sectionIndividual attributes of the object.

Attribute Monitoring section Location for monitoring attribute activity.

Deployed Objects sectionObjects deployed on the Platform.

Wonderware Training


12. In the Rename Tab dialog box type in Platform1 Statistics and click OK. (Leading initials are not needed here.)

13. Right-click on the attribute Area in the Attribute section of the Object Viewer and select Add to Watch.



14. Right-click on the following additional attributes in the Attribute section and select Add to Watch.

CPULoadDiskSpaceFree (enter a -1 as an array index to get all disks on the system)RamAvailableAvg

15. Select File/Save Watch List from the File menu.

Note: It is necessary to click the Attribute Monitoring section for this to be available.

16. Select Program Files/ArchestrA/Framework/Bin and click Save to save the file as XYWatchWindows01 where XY are the initials of your first and last name.

Note: Your instructor may have you save this in a different location.

Wonderware Training


Wonderware Training


Lab 4 – Create and Deploy an Engine

IntroductionAn Engine object is not a physical entity. Rather it represents a logic engine that hosts your process devices. It is important to start with this object in Model View as it represents the base object on which all the process devices will be placed. When you have modeled all the process devices that the engine will host, you can then go into deployment view to assign the engine to a platform.

This lab will illustrate the steps necessary to create an Engine instance from the Template Toolbox, configure the objects and deploy them.


Create an instance of an Engine.Assign the instance of the Engine to the System area in Model View and to the Platform in the Deployment View.Deploy the instances.Save and close the editor.




Tasks

Create an Instance of an Engine1. In the Model View, create an instance of AppEngine by dragging and dropping an

AppEngine from the Template Toolset to the Application Views area.

2. Rename the Engine using the agreed upon naming conventions.

Wonderware Training


3. In the Model View, reassign the Engine to the XYSystem Area.

4. In the Deployment View, reassign the Engine to the Platform.

5. In the Deployment View, reassign the Plant and all the areas to the Engine since all Areas must run on an Engine.

6. Double click on the Engine to view its editor.



On the General tab, notice the Scan period. This is indicating how often the Engine will try to execute all objects underneath it. This can be quite important depending on the size of your application

You can now close the editor.

Now that an Engine has been created we are ready to deploy the object.

Deploying the Object7. Right-click on the Engine object and select Deploy.

Wonderware Training


8. Verify that OnScan and Cascade Deploy are checked and click OK.


The Application Views will now display the objects in their deployed state.



Using the Object Viewer – Engine Statistics10. Open the Object Viewer for the Engine again by right-clicking on the Engine and selecting

View in Object Viewer.

Wonderware Training


Or


11. If you previously closed the Object Viewer, then from the Menu bar select File/Load Watch List and select the Watch List saved from the previous lab, XYWatchWindows01.

12. Right-click in the Attribute Monitoring section and select Add Watch Window.

13. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab

dialog box enter Engine1 Statistics and click OK.



14. Right-click on the following attributes in the Attribute section and select Add to Watch.AreaHostScanStateScanStateCmd

15. Select File/Save Watch List from the File menu and click Save.

Note: Your instructor may have you save this in a different location.

Wonderware Training

Module 4

Modeling EquipmentSection 1 – Application Objects 4-3

Lab 5 – DeviceIntegration Object 4-7

Lab 6 – Analog Devices 4-19

Lab 7 – DiscreteDevices - Valve Instance 4-29

4-2 Module 4 – Modeling Equipment

Wonderware Training

Section 1 – Application Objects 4-3

Section 1 – Application Objects

Introduction

AnalogDevice ObjectThis 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.Controller 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.

Section ObjectivesBe familiar with Automation Objects that represent some element of your application.Understand their hosting and containment relationships.



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

The meaning of the states depends on the kind of Discrete Device. In the case of a pump, the states might be configured as “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).

Device Integration ObjectsA DeviceIntegration object (DIObjects) is an AutomationObject that represents the 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.

Wonderware Training

Section 1 – Application Objects 4-5

Hosting and Containment RelationshipsHost relationships are displayed in Deployment View.

Galaxy

Plant

Engine

Area

Application Objects

DI ObjectsContainment relationships are displayed in Model View.

Areas

Areas

Application Objects

Application Objects



Wonderware Training


Lab 5 – DeviceIntegration Object

IntroductionThis lab will illustrate the steps necessary to create a DeviceIntegration Object instance and configure its connectivity. From the IDE, the Template Toolbox, the Application View and the object editor will be used to create and configure the required DeviceIntegration Object


Create an instance of the DeviceIntegration Object.Configure the instance of the object using the object editor.Save and close the editor.

Note: FOR THIS LAB ONLY!!! This time we will NOT preface the object name with your FIRST and LAST initial. Again, this is for THIS LAB ONLY!



Tasks

Create Instance of DeviceIntegration ObjectIn order for application objects to communicate with external devices such as PLCs, DeviceIntegration objects need to be properly configured. To accomplish the communication of our Application Objects we use the $DDESuiteLinkClient object.

There needs to be an instance created of the object $DDESuiteLinkClient. This object will be assigned to our System Area and renamed InControl.

Note: For this object DO NOT preface it with your initials. When we deploy our objects in a common galaxy later in the course there will be only one instance of a PLC on a given Galaxy and all references need to be to the object without any initials.

1. In the Model View, create an instance of the DDESuiteLinkClient object.

2. Rename the object InControl.

Wonderware Training


3. Double-click on the DDESuiteLinkClient object to open the DDESuiteLinkClient editor.

4. With the General tab selected, configure as follows:

Server Node: <ask your instructor>Server Name: RTEngineCommunication Protocol: SuiteLink



5. Select the Topic tab.

6. At the Available Topics section, click on the icon and add a topic called Tagname.

Wonderware Training


7. We are now going to import a set of attributes from a csv. file. Your instructor will advise you as to the location of the file. At that point you will want to copy the file to your hard drive for easier access.

At the Associated Attributes for Tagname section, click on the

Tagname.ItemList icon . The Open dialog box will appear.

Select the IAS InControl Address List.csv file and click Open.

A list of attribute names and InControl addresses will be loaded into the DDESuiteLinkClient object.



8. Save and close the editor.

Wonderware Training


9. The Check In dialog box appears.

10. Enter Initial configuration and setup in the Comment field and click OK.



11. In the Model View, assign InControl to the XYSystem Area.

12. In the Deployment View, assign InControl to the XYAppEngine.

13. Deploy InControl.

Wonderware Training


14. Verify the Initial Scan State is set to OnScan and click OK.



Upon completion of the deployment the object will appear as follows:

15. Right-click on InControl and select View in Object Viewer.

Wonderware Training



17. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab dialog box enter InControl and click OK.

18. In Object Viewer add the following attributes to the Watch List to verify the correct values:ServerNodeServerNameCommunicationProtocolScanGroupList (enter a -1 as an array index to get all Lists on the system) ConnectionStatus




Wonderware Training


Lab 6 – Analog Devices

IntroductionAt this stage of the automation project, you have a device list and will begin to model the process devices. Model View is the most important at this stage as it will allow you to describe the relationship between complex objects like tanks and valves.

This lab will illustrate the steps necessary to create an Application Object instance from a AnalogDevice template and connect to InControl. From the IDE the Template Toolbox, the Application View and the object editor will be used to create and configure the required AnalogDevice.


Create an instance of the AnalogDevice.Configure the instance of the object using the object editor.Save and close the editor.

Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.e.g., if the user is John Burns, Valve would be JBValve) This will eliminate problems when we deploy our objects in a common galaxy later in the course.



Tasks

Create and Configure an Analog Device Instance1. In the Model View, create an instance of AnalogDevice by dragging it from the Template

Toolbox to the Application Views pane, and rename it XYLIT.

2. Assign the AnalogDevice object to Line1.

3. In the Deployment View, verify the AnalogDevice object will deploy on the Engine as assigned to Line1.

Wonderware Training


4. Double click on the AnalogDevice object to open the AnalogDevice editor.



5. Select the I/O tab.

6. Click the ellipsis button to open the Attribute Browser dialog box.

Wonderware Training


7. From the left pane select the InControl object.

From the right pane select Tagname.Txxy_LT_PV where xx is your Student number and y is the Tank System number (0 or 1 only). Then click OK.

The PV input source should now contain InControl.Tagname.Txxy_LT_PV.


9. The Check In dialog box will appear. Enter Initial configuration and setup in the Comment field. Then click OK.



10. Right-click on the Analog Object and deploy it.

Wonderware Training


11. Select OnScan then click OK.





13. Open the Object Viewer by right-clicking on the Analog Device and selecting View in Object Viewer.

Or


Wonderware Training



15. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab dialog box enter LIT and click OK.

16. In Object Viewer add the following attributes to the Watch List to verify the correct values:PV




Wonderware Training


Lab 7 – DiscreteDevices - Valve Instance

IntroductionThis lab will illustrate the steps necessary to create an Application Object instance from a DiscreteDevice template and connect to InControl. From the IDE the Template Toolbox, the Application View and the object editor will be used to create and configure the required DiscreteDevice.


Create a new instance of the Application objects from the Template Toolbox.Configure the instance for proper I/O.Use the Object Viewer to verify the configuration of objects.




Tasks

Create Valve1. Create an instance of the DiscreteDevice object by dragging it from the Template Toolbox to

the Application Views section.

2. Rename the object XYInletValve.

Wonderware Training


3. In the Model View, assign XYInletValve to XYLine1.

4. Double-click on the XYInletValve instance to open its editor.

5. On the General tab, enable XYInletValve for Inputs and Outputs. Check the box for Enable inputs and Enable outputs.



6. Select the States tab.

Wonderware Training


7. Configure the States as follows

Check the Enable transition state box.

Configure the State names as:

Passive state: Closed

First Active state: Opened

Transition state: Traveling

Fault state: Fault

8. Select the Inputs tab.



9. Configure the Inputs as follows

Number of Inputs:2

Combinations

Input 2

Input Name: CLS

Input Source Reference: InControl.Tagname.Txxy_IV_CLS

Where XX = student # {01, 02, 03…}

Y = Tank # {0, 1}

Input 1

Input Name: OLS

Input Source Reference: InControl.Tagname.Txxy_IV_OLS


Y = Tank # {0, 1}

Input to PV Map

0 0 Traveling

0 1 Opened

1 0 Closed

1 1 Fault

Wonderware Training


10. Select the Outputs tab.

Configure the Outputs as follows

Number of Outputs: leave as 1

Commandable States

Output1

Output Name: CmdOpen

Output Destination Reference: InControl.Tagname.Txxy_IV_CmdOpen

WhereXX = student # {01, 02, 03…}

Y = Tank # {0, 1}

Opened check box checked

Wonderware Training


11. Save and Close the editor.

12. The Check In dialog box will appear. Enter Initial configuration and setup in the Comment field. Then click OK.



Wonderware Training


13. Right-click on XYInletValve and select Deploy.



14. Verify OnScan is select then click OK.

Note: Now that the Initial Scan state of On Scan has been circled to point out its location a few times, it is expected that in subsequent Deployments that you not need the circle to remind of its location.


Wonderware Training



16. Open the Object Viewer by right-clicking on the Valve and selecting View in Object Viewer.



Or



18. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab dialog box enter InletValve and click OK.

19. Verify XYInletValve is selected and view the attributes associated with this object.

Add the following attributes to the Watch List and verify their values:CLS.ValueOLS.ValuePVCmd

Wonderware Training


20. Double-click the Cmd attribute to open it’s editor.

21. Change the state of the Valve and click Apply, then OK.

Notice the other changes as a result of this modification.

Note: the PV.CLS.Value and PV.OLS.Value attributes holds the actual values coming from the ‘field’ and are being mapped to the PV attribute.




Wonderware Training

Module 5

Complex Object Modeling – Extending the ObjectsSection 1 – Object Relationships 5-5

Lab 8 – Modeling Complex Objects 5-9

Section 2 – Object Change Control and Propagation 5-37

Lab 9 – Change Control and Propagation 5-39

Section 3 – UDAs and Scripts 5-49

Lab 10 – Object Reuse 5-79

Lab 11 – Averager 5-87

Section 4 – Extensions and Output Functionality 5-99

Lab 12 – Extensions 5-103

Section 5 – Additional Application Objects 5-109

5-2 Module 5 – Complex Object Modeling – Extending the Objects

Wonderware Training

5-3

Module ObjectivesBe able to comprehend how templates can be derived and understand the effect of locking the attributes of those templates.



Wonderware Training

Section 1 – Object Relationships 5-5

Section 1 – Object Relationships

Planning for Object TemplatesOne of the major benefits of Industrial 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 Industrial 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.

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

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

Section ObjectivesThis section will familiarize you with how to derive a template and lock its attributes.



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

Section 1 – Object Relationships 5-7

Leveraging of Template Instances

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

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

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

3. Rename the derived Template.

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

Template ContainmentTemplate containment allows more advanced structures to be modeled as a single object. For example, you might derive from the UserDefined template a new template called "Tank" and use it to contain ApplicationObjects that represent aspects of the tank, such as pumps, valves, and levels. You could derive two DiscreteDevice template instances called "Inlet" and "Outlet" and configure them as valves, derive an AnalogDevice template instance called "Level," and then contain them within the Tank template. The containment hierarchy would be as follows:



Wonderware Training


Lab 8 – Modeling Complex Objects

IntroductionThis is the point in the automation project that you begin to develop tools to save you time. You have noted that the device list has many duplicates and you can use this to your advantage by building all those common properties into a template device then using it as a cookie cutter to quickly build all the similar objects.

This lab will illustrate the steps necessary to create new toolsets and derive templates. An instance of a newly created template will then be created and deployed. The Object Viewer will be used to monitor the activity once the instance has been deployed.

We will derive a TankSystem template from a set of new templates which we will create. Initially we will create a Valve from a Discrete Device template, a Pump from a Discrete Device template and a LevelMeter from an Analog Device template. Then we will derive our InletValve and OutletValve template from our Valve template, a TransferPump template from our Pump template and an LIT template from our LevelMeter template. These objects will be used to model our TankSystem from which we will then create an instance of the template and configure it with the desired IO and monitor the results in the Object Viewer.

For this lab we will use a simple Tank System as shown in the following diagram. We will build our base templates first (e.g., Valve), then build our specialized templates (e.g., InletValve, OutletValve).

Transfer Pump

TransferPump 01_CmdStartTransferPump 01_AuxContact

TANK

TANKXXYXX = Student # {01,02,03…}Y = Tank # {0,1}

Tank Level

Inlet Valve

Outlet Valve

LIT01_PV






Create a new Toolset.Derive a TankSystem Template, an InletValve Template, an OutletValve Template, a TransferPump Template and an LIT TemplateConfigure the TemplatesCreate instances of the Templates.Use the Object Viewer to verify the configuration of objects.


STOP!You’ve read the Note above about prefacing your object names with your initials when you began every other Lab. For this lab it is ABSOLUTELY IMPERATIVE that you adhere to this naming convention. Later in this course when we migrate to a multi-user galaxy each Tank that is built from this Lab must have a unique name. Therefore, please remember to preface the Tank you are building in this Lab with your initials.

Wonderware Training


Tasks

Create New Toolset1. Select Galaxy/New/Template Toolset to create a new Toolset in the IDE on the menu bar

or

Right-click on the Template Toolbox Group heading and select New Toolset.

This will display the New Toolset dialog box.

2. Enter XYToolset in the Toolset Name field where X is your First initial and Y is your Last initial.

Click OK.

The new Toolset object is now displayed in the Template Toolbox.



Create a Valve TemplateInstead of creating an instance of a template we now are going to derive a template from a $DiscreteDevice object.

3. Right click on $DiscreteDevice in the Template Toolbox and select New/Derived Template.

Wonderware Training


4. Rename the object to XYValve (where XY are your initials) and move it to your Toolset.

Note: There’s no need to type the $ character at the beginning of the name. It will be added automatically by the IDE.



5. Double-click on the Valve template to open its editor.

6. On the General tab, check the box for Enable inputs and Enable outputs to enable the Valve to Inputs and Outputs.

Wonderware Training


7. Select the States tab. Configure the States as follows

Check the Enable transition state box.

The State names as:

Passive state: Closed

First Active state: Opened

Transition state: Traveling

Fault state: Fault



8. Select the Inputs tab. Configure the Inputs as follows

Number of Inputs:2

Combinations

Input 2 CLS

Input 1 OLS

Input to PV Map

0 0 Traveling

0 1 Opened

1 0 Closed

1 1 Fault

Wonderware Training


9. Select the Outputs tab. Configure the Outputs as follows

Number of Outputs: leave as 1

Commandable States

Output1 CmdOpen



At the Check In dialog box, enter Initial configuration and setup in the Comment field and click OK.



Create the Pump Template11. Right click the $DiscreteDevice template in the Template Toolbox and select New/Derived

Template.

12. Rename the new template XYPump (where XY are your initials) and move it to your Toolset.

13. Double-click on the Pump template to open its editor. On the General tab, check the Enable inputs box and the Enable outputs box

Wonderware Training


14. Select the States tab. Configure the States as follows

Configure the State names as:

Passive state: Stopped

First active state: Running

Fault state: Fault



15. Select the Inputs tab. Configure the Inputs as follows

Number of Inputs: leave as 1

Combinations

Input1 AuxContact

0 Stopped

1 Running

Wonderware Training


16. Select the Outputs tab. Configure the Outputs as follows

Number of Outputs: 1

Commandable States

Output1 CmdStart

Running check box checked





Create a LevelMeter Template18. Right click on the $AnalogDevice template in the Template Toolbox and select New/Derived

Template.

19. Rename the new template XYLevelMeter (where XY are your initials) and move it to your Toolset.

Wonderware Training


Note: No specific configuration is necessary at this point for the LevelMeter template. Subsequent labs will use this template to customize other parameters for the Level Meter.



Build Containment to Represent the Tank SystemsNow we will make a containment assignment by assigning several of our templates to a TankSystem. Derived templates from Valve, Pump and Level Meter are created to build the TankSystem even when there’s no customization on the new objects. Valve, Pump and Level Meter are left as ‘general’ templates to implement other valves, pumps and level meters in the application.

Note: As a general rule and a good practice, never use ‘empty’ objects in your model. Our TankSystem will be extended later.

20. Right click on the $UserDefined template in the Template Toolbox and select New/Derived Template.

Rename the new template XYTankSystem (where XY are your initials) and move it to your Toolset.

21. Right click on the $XYValve template in the Template Toolbox and select New/Derived Template.

Name your new template $XYInletValve.

Move $XYInletValve into $XYTankSystem. $XYInletValve is now contained in $XYTankSystem.

Wonderware Training


22. Right click on the $XYValve template in the Template Toolbox and select New/Derived Template.

Name your new template $XYOutletValve and move it into $XYTankSystem

23. Right click on the $XYPump template in the Template Toolbox and select New/Derived Template.

Name your new template $XYTransferPump and move it into $XYTankSystem

24. Right click on the $XYLevelMeter template in the Template Toolbox and select New/Derived Template.

Name your new template $XYLIT and move it into $XYTankSystem



Create and Configure a TankSystem Instance25. Create an instance of the $XYTankSystem object by dragging it from the Template Toolbox

to the Application Views pane, and leave the default name XYTankSystem_001. Verify that you are in the Deployment View of the Application Views.

Note: Notice that all of the contained objects have a name in square brackets following the object name.

26. Assign XYTankSystem_001 to the XYLine1 Area.

Wonderware Training


Configure the InletValve27. Double-click on the XYInletValve_001 to open its editor. Notice that all the configuration

made at the $XYValve template is present in the derived instance.

Select the Inputs tab. Configure the Input Source Reference as follows

Input Source References

Input 2 CLS

Input Source Reference InControl.Tagname.TXXY_IV_CLS

Input 1 OLS

Input Source Reference InControl.Tagname.TXXY_IV_OLS


Y = Tank # {0, 1}



28. Select the Outputs tab. Configure the Output Destination Reference as follows

Output Destination References

CmdOpen InControl.Tagname.TXXY_IV_CmdOpen


Y = Tank # {0, 1}


Wonderware Training




Now you can see as represented by the icon for XYInletValve that the reference has been resolved.

Configure the OutletValve30. Double-click on the XYOutletValve_001 to open its editor. Select the Inputs tab. Configure

the Input Source Reference as follows


Input 2 CLS InControl.Tagname.TXXY_OV_CLS

Input 1 OLS InControl.Tagname.TXXY_OV_OLS


Y = Tank # {0, 1}



Wonderware Training



Output Destination References

CmdOpen InControl.Tagname.TXXY_OV_CmdOpen


Y = Tank # {0, 1}






Configure the TransferPump33. Double-click on the XYTransferPump_001 to open its editor. Select the Inputs tab.

Configure the Input Source Reference as follows


AuxContact InControl.Tagname.TXXY_TP_AuxContact


Y = Tank # {0, 1}


Output Source References

CmdStart InControl.Tagname.TXXY_TP_CmdStart


Y = Tank # {0, 1}

Wonderware Training




Configure the LIT Object36. Double-click on the XYLIT_001 to open its editor. Select the I/O tab.

Configure the PV input source as InControl.Tagname.TXXY_LT_PV



Now all the references have been resolved as indicated by the icons represented for each of the objects.



Deploy and Test the TankSystem Object38. Right-click on your XYTankSystem_001 instance and select Deploy.

Verify that Cascade Deploy is checked and the Initial Scan state is set to On Scan. Then click OK.

39. Right-click on the XYTankSystem_001 and select View in Object Viewer to view the object attributes in Object Viewer.


41. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab dialog box enter Tank and click OK.

Wonderware Training


42. Add the following attributes to the Watch List to test the object.

For XYInletValve_001 add:CmdPV

For XYOutletValve_001 add:CmdPV

For XYTransferPump_001 add:CmdPV

For XYLIT_001 add:PV


44. Experiment with the objects double clicking the Cmd attributes to command the InletValve, OutletValve and TransferPump. Note the changes in the other attributes as a result of these operations.



Wonderware Training

Section 2 – Object Change Control and Propagation 5-37

Section 2 – Object Change Control and Propagation

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 ObjectivesFamiliarize you with the concept of attribute locking, and Enable you to understand how locking attributes can propagate to previously derived instances.



To lock a Template attribute, do the following:

1. Select the desired Template in the IDE and launch its editor.

2. Enter a value in an attribute field in the object’s editor.

3. Select the locking mechanism for that attribute. Some editors may have lock icons associated with certain edit fields, but this possibility is within the scope of the developer of the object’s editor.

4. Save and close the object editor.

The locked attribute in any derived templates and instances created from this template are locked and unavailable. To test this, you can derive a new template or create an instance from the original template, and then check the new object’s editor. The locked attribute is unavailable for editing.

Unlocking an AttributeTo unlock a Template attribute, do the following:

1. Select the desired Template in the IDE and launch its editor.

2. Select the locking mechanism for the locked attribute in the object’s editor. Some editors may have lock icons associated with certain edit fields, but this possibility is within the scope of the developer of the object’s editor.

3. Save and close the object editor.

The previously locked attribute in any instances created from this template are now unlocked. The previously locked attribute in any templates derived from this template are now Locked (in me). The previously locked attribute in any instances of derived templates remain in Locked in Parent.

Wonderware Training


Lab 9 – Change Control and Propagation

IntroductionThis lab will illustrate how simply by locking certain attributes, we can propagate that change to the objects that were derived from it.


Modify template attributes by locking them for change propagation.Monitor the changes that are propagated to the object instances that were derived from the template object.




Tasks

Lock the Valve1. Double-click the $XYValve template to open the DiscreteDevice editor.

On the General tab lock:Enable inputsEnable output

2. On the States tab lock:Enable second active stateEnable transition stateState names

Wonderware Training


3. On the Inputs tab lock:Number of InputsInput NameInput to PV Map



4. On the Outputs tab lock:Number of outputsOutput NameClosedOpened

Wonderware Training




Notice that the instances that were created from this template have icons now indicating configuration has changed and the object needs to be redeployed. We will deal with this later.



Lock the Pump6. Double-click the $XYPump template to open the DiscreteDevice editor.

On the General tab lock:Enable inputsEnable output

7. On the States tab lock:Enable second active stateEnable transition stateState names

Wonderware Training


8. On the Inputs tab lock:Number of InputsInput NameInput to PV Map

9. On the Outputs tab lock:Number of outputsOutput NameStoppedRunning




At the Check In dialog box, enter Initial lock configuration in the Comment field and click OK.

Lock the LevelMeter11. Double-click the $XYLevelMeter template to open the AnalogDevice editor.

On the General tab lock:TypeEnable analog outputEnable PV overrideEnable I/O scaling


At the Check In dialog box, enter Initial lock configuration in the Comment field and click OK.

Wonderware Training


Check and re-deploy the existing instanceAs we pointed out earlier, notice that the derived instances have a re-deploy status icon.

13. Open the editor for any of the instances and check that you can't modify the locked attributes.

14. Close the editor.

15. Re-deploy XYTankSystem_001. Verify that the Cascade Deploy is checked and the Initial Scan state is set to On Scan.



All instance references have now been reconciled with the changes we made in our template from which those objects were derived.

Wonderware Training


Section 3 – UDAs and Scripts

User Defined Attributes (UDAs)UDAs (User Defined Attributes) are part of the ApplicationObject script environment. They allow users to not only add logic to an existing ApplicationObject but also to expose new behavior via added (user defined) attributes. More specifically, they allow users to:

Add a new attribute to an object.Configure its data type.Specify the attribute category.Set initial values and locks on the new attribute.Set whether the new attribute is an array and how many elements comprise it.Set alarms and historization for the new attribute (done on the Extensions page).Define security and references to other objects (done on the Extensions page).

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

Section ObjectiveThis section will familiarize you with an understanding of the scripting environment and the various scripting configuration attributes of the ApplicationObject.



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

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


The ApplicationObject ScriptAn ApplicationObject script is developed for the purpose of adding behavior to a specific ApplicationObject. It will execute only when a deployed object containing the script is on scan. The script isn’t directly callable from other scripts (although changing the value of an object attribute may allow the script’s execution trigger conditions to command script execution). A script doesn’t have the concept of returning a specific value upon execution completion.

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

If the user selects an Execute type script, the script editor exposes one edit field for an expression and another edit field for the script code.

The script expression acts as a filter for the invocation of Execute script execution. The expression is evaluated every time the object that the script is attached to is executed. Dependent on the evaluation the actual script is triggered or not.

This model is fine for simple scripts that just do some simple calculations. However, as soon as it is necessary to instantiate external objects and keep them alive across multiple executions of the script, the simple model falls apart. In order to support those more complex scenarios the script writer can fill in script code for the Startup() and Shutdown() methods. External objects would be instantiated in the Startup() method and destroyed in the Shutdown() method. If finer granularity is needed the OnScan() and OffScan() methods can be used respectively. OnScan() and OffScan() are invoked whenever the scan state of the object changes to OnScan and OffScan, respectively.

In order to support the just described scenarios the script offers a way to mimic static variables (e.g., variables holding an instance of an object alive across different execution cycles). This is accomplished by using a Dim statement in the upper Declarations section of the script editor. Variables so dimensioned stay alive for the lifetime of the object.

In contrast, Variables dimensioned in the script section are destroyed between calls to the Object’s script. In either case, dimensioned variables are only accessible from within the script. Other scripts cannot access those variables. Also, there is no means to expose those variables as attributes of the associated object (e.g., for debugging purposes). To expose these member variables, they can be set to a UDA.

Due to this tight link between scripts and UDAs, a script has more open access to UDAs (of the object that the script is attached to) than to any other attribute on the object. It could be said that UDAs are owned by a script

A script can also leverage UDAs to persist values across different script runs. Therefore, UDAs allow users that do not want to get exposed to the complexity of script member variables to still mimic static variables for data types that fit into Application Server attributes.



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.

Browsing for COM Objects

Similar to browsing for script functions, the user can also browse for COM objects that have been imported using the IDE.

Language Syntax Validation

Script language syntax validation is performed by selecting the red check mark above the script window.

This operation will identify and inform/warn the script developer of any syntax errors in the script. A script with syntax errors can be saved. However, an object leveraging such a script cannot be deployed.

Support Script Code Comments

The user can insert comments to document the script code (compare with InTouch QuickScript comments {your comment here}).

Specifying Attributes within a ScriptThe following sections describe how internal attributes (attributes of the object that the script is attached to) as well as external attributes (attributes on other objects) can be referenced from within a script.

References to both internal as well as external attributes have in common that typically the part specifying the property is omitted meaning that the value property is meant. In this case only the value property and the associated quality can be accessed via this attribute reference.

Specifying Internal AttributesFor internal attributes the syntax: me. + <fully qualified local part of the attribute reference> needs to be specified.

Example: If me.PV==”Open” Then

{Do something}Endif;

Script ExamplesThe following script examples may be used for reference.

Wonderware Training


Note: Many additional script examples may be located in the 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"]);

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"")]");

Specifying External AttributesThe script developer can specify external attributes in two distinct ways:



Inline SpecificationSpecifying external attributes inline in the script code is equivalent to how internal attributes are used. The only difference is that in the case of external attributes the fully qualified name including the global part (i.e. the object name) is required. Relative (e.g., MyContainer.PV) and hierarchical names (e.g., Tank1.Inlet.Cmd) are also supported in addition to the ‘native’ name (e.g., Valve101.PV).

There are cases when the attribute name cannot be specified within the script code without clashing with the existing script syntax. This case often applies when attributes of a Device object referring to a data point in an actual physical device need to be referenced. Those attributes typically use a native item syntax which often makes use of special characters (!, :, ;, etc.) that can collide with the syntax rules of the scripting language.

To account for those cases QuickScript .NET supports the specification of an attribute reference in the form:

Attribute(“<attribute name>”)

The following script snippet demonstrates its usage:If Attribute(“PLC5.Fast.N10:5”) == True Then {Do something}Endif;

While inline specification of external attributes is very convenient (you just type in the name or pick the right name using the attribute browser), it imposes restrictions when used in scripts attached to templates.

Consider the following script snippet:Valve101.ControlMode=Auto;Valve101.Cmd=”Open”;Valve101.ControlMode=Cascade;

If this script is attached to a template and the script code (script text) is locked in the template, then any instance of this template can only meaningfully work if there is a Valve101 – obviously a bad design of the script.

The script environment offers two solutions for this problem:

1. Usage of relative names in the script code (e.g., MyContainer.ControlMode=Auto). While this approach works perfectly in scripts which are locked in a template, it severely constrains the number of attributes that can be accessed this way.

2. Using aliases in the script code that link to a reference table. This option is discussed in more detail in the next section.

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

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

Wonderware Training


First the user has to specify an alias for an external reference (e.g., 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 we 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 we need to read the Value property and the UpperBoundDimension1 property of the external attribute Valve101.PV. Let’s further assume that we want to use inline references. The corresponding code snippet is:

A = Valve101.PV; {reads the Value property}B = Valve101.PV;.UpperBoundDimension1 {reads the UpperBoundDimension1 property}

The two references Valve101.PV and Valve101.PV.UpperBoundDimension1 are treated as two completely different references.

Note: Even though the two references Valve101.PV and Valve101.PV.Value (explicitly specifying the Value property) refer to the same property, they too are treated as two separate references. Therefore the user should avoid mixing both ways of referring to the Value property in a given script.

Accessing Array References Arrays can be accessed either by referencing an individual element of an array or by referencing the entire array. The individual element is specified by specifying the element within the square brackets as follows:

Tag.ArrayAttribute[3]

To get an entire array, either of the following syntaxes works:

Tag.ArrayAttribute[-1]

Or

Alias ReferencePVofInletValve Valve101.PV… …



Tag.ArrayAttribute

Script Execution ConfigurationEach script editor enables configuration of a script’s execution settings. These settings include, where applicable, execution trigger conditions, execution mode, and execution ordering.

Execution Trigger Conditions Each script will have a set of execution trigger conditions associated with it. The script type will determine a set of valid condition types.

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

Script Trigger - Periodically The script will be executed based on a time interval specified by the user. Although this cannot be determined at configuration time, at run-time, when going on-scan, the execution period will be rounded up to the nearest multiple of the Application Engine scan period.

A time interval of zero means that the script is executed during every scan.

Note: There is no condition (or expression) specified for periodic script execution. It is executed at the interval specified, unconditionally.

Script Trigger - While TrueWhile a user configured expression evaluates TRUE.

A time interval is also specified. If non-zero, then at the time interval specified, the configured expression is evaluated to determine if the script is to be executed. A time interval of zero renders the time interval unused and causes the expression to be evaluated at the AppEngine scan period.

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

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

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

Wonderware Training


Script Trigger – While FalseWhile a user configured expression evaluates FALSE.

A time interval is also specified. If non-zero, then at the time interval specified, the configured expression is evaluated to determine if the script is to be executed. A time interval of zero renders the time interval unused and causes the expression to be evaluated at the AppEngine scan period.

Execution ModeOnExecute() 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.

Asynchronous Scripts Only Apply to Execute() Only script code written for the Execute() method of an object can be declared asynchronous.

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

Asynchronous Script Execution Ordering with an Object Specification of execution order for asynchronous scripts within an object is allowed. However, this ordering just impacts condition evaluation, not execution ordering since asynchronous scripts are run in separate threads from each other.

Asynchronous Script Worker Threads The hosting engine creates a pool of worker threads at startup time. These threads are used for processing asynchronous scripts simultaneously when they are due and their trigger condition is



true. Only one script can execute on one thread at a time. If an asynchronous script comes due and no worker thread is available, it is immediately queued for execution and awaits a free worker thread. As soon as the worker thread is free from its previous script, it executes the newly queue script.

A default number of worker threads is to be provided. This is a configurable attribute of the Engine.

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

Asynchronous Scripts Diagnostics and Attributes Asynchronous scripts require some additional attributes within the script to provide the following behavior:

Kill attribute - terminates the asynchronous script when written to. Shutdown attribute – simply a Boolean flag that requests the asynchronous script to shut down on its own. A well-written script will check this command before and after 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).Asychronous 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.

Watchdog Timeout The execution time of both synchronous as well as asynchronous mode scripts is monitored against a timeout period. All synchronous scripts on an AppEngine share the same timeout period which is exposed as a configurable attribute of the AppEngine.

In the case of asynchronous scripts a timeout period that is shared for all asynchronous scripts does not make sense since the needed execution time can vary by orders of magnitude between different asynchronous scripts. In order to account for this, the timeout period can be separately configured for each asynchronous script. It is exposed as an attribute of the script.

Attribute Access Support In order to understand the philosophy of attribute access from within a script it is important to look at the context that an ApplicationObject Script runs in: All objects running on an AppEngine can be thought of as a big PLC program. At the beginning of a new scan cycle of the AppEngine all external input values (values coming from other engines) are read in one block. Then all objects including any associated scripts are executed. Outputs to objects on other engines are queued up and are written out once at the end of the AppEngine’s scan cycle.

Following this philosophy scripts need to have direct read / write access to all attributes exposed by objects on the same AppEngine that the script is running on. Let’s use the following script snippet to further clarify the behavior:

Wonderware Training


PID.Mode=AutoPID.SetPoint=50PID.Mode=Cascade

This script will work independent on whether the PID object resides on the same AppEngine that the script is executing on (on-engine) or not (off-engine). Each set operation is immediately executed. If the PID object is on-engine then the set operation changes the value of the corresponding attribute right away. If the PID object is off-engine then all set operations are queued up in exactly the order they were issued and are executed at the end of the scan cycle of the AppEngine (asynchronous set).

‘Get’ operations work accordingly. Let’s consider the following script code snippet:

{For this example we assume that PID.SetPoint==30 at the start of the script} If PID.SetPoint==30 then PID.Mode=AutoPID.SetPoint=50PID.Mode=CascadeEndif;If PID.SetPoint==50 then

{Do something else}Endif;

Granted that the PID object exists and its SetPoint can be set to 50 then the second ‘if’ statement will always evaluate to true if the PID object is on-engine. However, in the off-engine case both ‘if’ statements will never evaluate to true in the same execution cycle of the script.

In other words, when a script performs an attribute set (write) operation followed, at a later point in the script, by a read of the same attribute, the value written will not be read back if the attribute is off-engine, rather the attribute value existing when the script commenced execution is returned instead. In this case, the value written to the attribute will not be returned by a get (read) operation until succeeding execution scans of the script.

Notes:As described above a script performing read / write operations on the same attribute will behave differently depending on whether the attribute is on-engine or off-engine. If necessary, the script developer can avoid this situation by using a local script variable to manage the attribute’s value in the course of the script’s execution. At the end of the script, the value of the local variable is then written to the attribute.Scripts attached to an ApplicationObject are part of the supervisory control logic. I.e., read and write operations performed by the script are treated as SupervisoryGets / Sets.

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

Off-Engine Attribute Access When a script accesses an off-engine AutomationObject attribute, the Local Message Exchange/Network Message Exchange (LMX/NMX) sub-system is the provider of the attribute data. In this case, LMX/NMX establishes a subscription for the attribute’s value and maintains the most recently published value in an on-engine read-only cache. When a script reads an off-engine



AutomationObject attribute, the LMX cache’s most recently published value is provided to the script. This value will not change during the execution scan of the script.

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

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

Accessing Regular Attributes (non-UDAs)In order to maintain the integrity of an object, access to regular attributes from within a script is limited to whatever access other AutomationObjects have. This constitutes what the object has been designed for and it must be absolutely avoided that a script could interfere and potentially break the object’s logic.

I.e., access to regular attributes is treated in the same way as access to attributes of other objects from within the script.

Accessing UDAs The precautions taken for regular attributes do not apply for UDAs. UDAs are added to an object for the main purpose of having one or more scripts on this object drive them.

As a result script access to UDAs is treated exactly like the internal runtime access of a primitive to its attributes. In particular, a script can set the quality property of a UDA on the hosting object. However, the quality of a UDA is defaulted to GOOD.

On the other hand propagation of quality in calculations is handled in the following manner: In the expression a = b + c, if b is bad (or initializing), the value of a is not updated and its quality is set to BAD or (initializing). If the quality of b is uncertain then the calculation is performed, the value of a is updated and a’s quality is set to uncertain.

Prevent Accessing Attributes during OnStartup(), OnShutdown()

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

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

Wonderware Training


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

Quality Handling in Script Expressions Script expressions are ‘one liners’ and as such it does not make sense to only execute the part of an expression that deals with attributes of acceptable quality. I.e., the expression is either evaluated as a whole or not at all.

If any of the input variables to the expression change to an initializing or bad quality state, the result value reported will have a quality of initializing or bad (if there exists at least one input with initializing and another input with bad quality, bad will have precedence over initializing quality and be reported as the expression result’s quality). The result value itself is set to the default value for the given data type (e.g., a result value of type float is set to NaN – not a number) when the quality turns unacceptable.

If the script expression is used as the trigger for the execution of a script and the quality of at least one referenced attribute is unacceptable (i.e., initializing or bad), then the script is not triggered at all.

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

When using the Application Server scripting language, the script developer should understand the following rules and behavior:

Only Referenced Attributes Expose Quality Only referenced attributes expose quality. Local variables do not have a quality assigned. I.e., when assigning the value of an attribute to a local variable the quality information is lost.

Example: The following code snippet assumes that A and B are local variables of appropriate data type.

A = 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.}



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

Script Functions do not Leverage Quality InformationFor Script Functions the in and out parameters as well as a potential return value have no associated quality information. E.g., a Script Function for calculating the square root of a float value might have a signature like this:

float Sqrt(float InValue)

If an attribute reference is 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 on 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.

Wonderware Training


Adhering to this standard allows script writers to take quality into account without ever explicitly evaluating the quality of referenced attributes.

Condition statements are the only instance where a DQP enabled script language takes quality implicitly into account. In all other cases the script execution system ignores the quality if the script developer does not choose to test the quality explicitly. This also means that the assignment

PID1.SP = PID2.SP

is executed independent on 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 is it easier if all the listed cases are treated equally; i.e., the quality is ignored in all cases.

Numerical Comparisons and NaNs (>, <=, >, >=)If either double or float operand is IEEE representation of not-a-number NaN in a numerical comparison, then the result is false. This follows the IEEE 754 standard. Also, positive zero and negative zero are considered equal.

Script Execution Error 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 (e.g., by running in an infinite loop), a script is aborted after the timeout period for the script has elapsed. The script execution infrastructure will clean up after the aborted script as best as possible. E.g., the script infrastructure must attempt to release external objects or data base



connections that were created by the script. However, it can never be guaranteed that an aborted script has no negative side effects. E.g., the script could have started to manipulate data base entries and could leave some table entries in an inconsistent state.

All synchronous mode scripts will be subject to the same timeout period, which is exposed as an attribute on the AppEngine.

The script developer will be required to configure the timeout period for each Asynchronous mode script in order to provide flexibility in accommodating the potentially time consuming operations that these scripts are intended for.

Overflow Error A script experiences an overflow condition. Overflow conditions not only apply to analog data types (integer float) but also other data types (e.g., string length overflow).

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.

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.

Wonderware Training


Script Locking

Locking Scripts in Templates From an implementation point of view it is much easier to lock both the expression controlling the execution of an ApplicationObject script and the actual script at the same time; i.e., treat both as one entity. This allows the system to compile both the expression and the script into only one dll which makes deployment easier and decreases the overhead carried in each dll.

Typically an expression uses attribute references. If the user wants to lock the expression and the associated script expression in a template then it is crucial that aliases are used in both the expression and the script. This allows the user to specify the attributes that the aliases point to on a per instance basis while the code is locked.

Rules on Locking of Scripts:Script text can be locked/unlocked in a Template.When a Script is locked in a Template, the Alias names are automatically locked also. The Alias References are never locked. Locking of Aliases is not specified separately (it is only done when the script itself is locked/unlocked).The Script expression, trigger type and trigger period are group locked and can be locked separately from the script text.When a Script is added to a Template, all properties of the Script are editable.When a Script is added to an Instance, all properties of the Script are editable except for the Lock property (since lock is never editable in an Instance).For a Script added in an Instance, all properties of the Aliases can be edited except the Lock (since locks are never editable for Instances).

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.

Language Definition

QSII Case SensitivityAll QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the case is preserved throughout editor sessions.

QSII CommentsBoth 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}

QSII White SpaceSpaces 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.

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

QSII Operations that Require 1 OperandOperation Description~ Complement- NegationNOT Logical NOT

QSII 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) (, )

Wonderware Training


QSII VariablesVariables must be declared before any other code. Local variables or attributes can be used interchangeably within the same script. However, local variables go out of scope at the end of the script function they are used in. However, variables declared in the general section of the script exist and keep their value throughout the lifetime of the object that the script is associated with. Thus this kind of variable turns into a ‘member variable’ of the script class. Other scripts attached to the same object cannot access this variable.

Variables can be used on both the left and right hand side of statements and expressions.

QSII Syntax for Variable DeclarationEach 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

2 - (negation), NOT, ~3 **4 * , /, MOD5 +, -6 SHL, SHR7 <, >, <=, > =8 ==, <>9 &10 ^11 |12 =13 AND14 (lowest) OR

Precedence Operator



statement will refer to the value associated with the local variable ‘PV’ rather than the attribute ‘PV’.

Note: The naming convention for QuickScript.NET variables is more restrictive than in QuickScript. In QuickScript additional special characters are allowed:Quickscript_special_character :- _!@-?#$%\&

In contrast to QuickScript arrays with up to three dimensions are supported. Only the upper bound of each dimension can be specified and is fixed after the declaration; i.e., a statement analogous to VB’s ReDim statement is not supported. The lower index of each array dimension is always 1.

The data type declaration (AS <data_type>) is optional. If omitted, the data type of the variable is Integer (as in QuickScript).

The following table shows how the QuickScript .NET data types map to C++ data types. The default value column defines which value the variable takes on when it is defined (before another value is assigned).

Mapping of Application Server Attribute Data Types to QuickScript .NET Data TypesApplication Server data types are mapped to QuickScript .NET variable data types according to the following table.

Data Type (as specified inAS <data_type>)

Default Value

Corresponding C++ data type Comment

Boolean, Discrete False VARIANT_BOOL Discrete and Boolean are synonymous. Discrete is still supported for migration from InTouch.True=1, False=0

Integer 0 long (4 bytes) Signed–2147483648 to 2147483647

Float, Real NaN float (4 bytes) Float and Real are synonymous. Real is still supported for migration from InTouch.For range information please refer to Appendix

Double NaN Double (8 bytes) For range information please refer to Appendix

String, Message “”(empty string)

BSTR Maximum length defined by BSTR (2147483647)

Time 0 Based on .NET’s System.DateTime (8 bytes)

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 Based on .NET’s System.TimeSpan structure (8 bytes)

100 nanosecond ticks represents a time span.

Object Nothing IDispatch pointer Leveraged for accessing OLE Automation servers.

Wonderware Training


Application Server Data TypeQuickScript .NET Data Type

Comments

MxBoolean Boolean or Discrete

True=1, False=0

MxInteger IntegerMxFloat Float or RealMxDouble DoubleMxString String or

MessageIn Application Server, there is no fixed upper limit on string length.

MxInternationalizedString String or Message

These strings are read-only at runtime. If script tries to write at runtime the write will fail at runtime with appropriate status.

MxTime Time The filetime content of MxTime is mapped to Time.DateTime of the QuickScript .NET data type. The Application Server internal representation is based on 1601, whereas the Script internal representation is based on 0001 (consistent with .Net system).The time zone offset of MxTime is mapped to Time.TimeZoneOffset.Time.DateTime is a .Net DateTime. Time.TimeZoneOffset is an integer.

MxElapsedTime ElapsedTime Same definitionMxReferenceType String Only the string content of the attribute is used.

The potentially pre-bound IDs are thrown away. MxStatusType Integer One of the integer values listed in section. Note,

that only the status category is exposed. The status detail is not accessible form within a script.

MxDataTypeEnum Integer One of the integer values listed in section.MxSecurityClassificationEnum Integer One of the integer values listed in section.MxDataQualityType Integer One of the integer values listed in the OPC Spec.

‘Data Access Custom Interface Standard’. The user can also write this (but only my attributes, not external attributes). For example, to set the quality of MyAttr to GoodObject.MyAttr.Quality=192. Note that access to Quality is purely an OPC quality operation.To access Application Server’s 4 basic quality states (Good, Bad, Uncertain, Initializing), the user can use functions IsGood(), IsBad(), IsUncertain(), IsInitializing(). This will allow tests likeif (IsGood(Obj.Attr.Qstring) Additionally, the user can set the quality using functions SetGood(), SetBad(), SetUncertain(), SetInitializing(); for example:SetBad(TIC101.PV).



QSII Numbers and StringThis section describes the allowed format for specifying integer and float numbers as well as strings in the script text.

Integers in decimal formatIntegers constants in decimal defined as

IntegerConst ::=

[sign] <non-zero_digit> <digit>*

| 0

sign ::= + | -

non-zero_digit ::= 1-9

digit ::= 0-9

I.e., an integer constant is a zero or consists of an optional sign followed by one or more digits. Leading zeros are not allowed.

Integer constants outside the range –2147483648 to 2147483647 cause an overflow error.

Integers in hexadecimal formatPrepending either 0x or 0X causes a literal integer constant to be interpreted as being in hexadecimal notation. In this case the sign is not supported.

MxQualifiedEnum Integer or String

Attributes of type mxQualifiedEnum can be read / set as an integer or a string.Example:Dim intV1_PV as Integer;Dim strV1_PV as String;intV1_PV = Valve101.PV;{ Now intV1_PV holds the ordinal value of the qualified enumeration }strV1_PV = Valve101.PV;{ Now strV1_PV holds the string value of the qualified enumeration }

MxQualifiedStruct N/A The data type MxQualifiedStruct is not directly mapped to a QuickScript .NET variable data type. Instead, functions are provided that allow the script developer to map parts of the qualified struct to native script data types.Example (the actual name and signature might change): ToInteger(<QualifiedStruct>, StartByte) which expects an attribute of data type mxQualifiedStruct and a number of the first byte that makes up a 4 byte integer. It returns a regular integer.

Application Server Data TypeQuickScript .NET Data Type

Comments

Wonderware Training


IntegerHexConst ::=

<0><x | X> <hexdigit>*

hexdigit ::= 0-9, A-F, a-f

When entering a hexadecimal number, only 8 hexdigits (32-bits) are allowed.

FloatsFloat constants are applicable as values for variables of type float / real or double. I.e., float constants do not take the number of bytes into account. It is up the validation step of the script (lexer / parser) to detect an overflow when too big a float constant is assigned to either a variable of type float / real or double.

FloatConst ::=

[<sign>] <digit>* .<digit>+ [<exponent>]

| [<sign>] <digit>+ [.<digit>* [<exponent>]]

sign ::= + | -

digit ::= 0 - 9

exponent ::= exponent_character [sign] <digits>+

exponent_character ::= e | E

Sign is either plus (+) or minus (–); and digits are one or more decimal digits. If no digits appear before the radix character (.), at least one must appear after the radix character. The decimal digits can be followed by an exponent, which consists of an introductory letter (e or E) and an optionally signed integer. If neither an exponent part nor a radix character appears, a radix character is assumed to follow the last digit in the string.

Please note that the allowed range depends on the data type (4 byte float / real versus 8 byte double) of the variable that the value is assigned to.

String LiteralsString literals need to be surrounded by double quotes. They are referred to as quoted strings. Within the quoted string the character ‘\’ can be used as an escape character. The following escape characters are supported:

Escape Sequence Description\n New line\r Carriage return\t Horizontal tab\' Single quotation mark. Single quotes can

also directly be used in a string without using the escape sequence.

\" Double quotation mark\\ Backslash\uxxxx Represents single Unicode character

formed by the hexadecimal number xxxx. E.g. ‘\u0066’ is the letter ‘f’. 4 digits are required.



QSII Control Structures

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

\Uxxxxxxxx Represents single Unicode character formed by the hexadecimal number xxxxxxxx. E.g. ‘\u00000066’ is the letter ‘f’. 8 digits are required.

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.

Escape Sequence Description

Wonderware Training


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 thenMessage = ”Value is negative”;

Else{Default. Should never occur in this example}

EndIf

For consistency with InTouch Scripting, the following syntax is also supported:

IF <boolean_expression> THEN

[statements]

[ { ELSE IF

[statements] } ]

[ ELSE

[statements] ]

ENDIF;

ENDIF;

This approach basically nests a brand new IF compound statement within a previous one and requires an additional ENDIF.

FOR … TO … STEP … NEXT Loop A FOR-NEXT loop is used to perform a function (or set of functions) within a script several times during a single execution of a script. The general format of the FOR-NEXT loop is as follows:

FOR <analog_var> = <start_expression> TO <end_expression> [STEP<change_expression>]

[statements]

[EXIT FOR;]

[statements]

NEXT;

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 exists. (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 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: Collection 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;

Wonderware Training


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. (Omitted for this slice)

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.

Support for Script FunctionsIn order to follow the naming syntax of InTouch QuickScript, binary shared functions are referred to as script functions. Functions written in QuickScript are named QuickFunctions.

Accessing Script FunctionsScript functions can be directly accessed from within the script code. The syntax is exactly like in QuickScript.

Example:PumpState = StringRight("The Pump is On", 2);

Where StringRight is a binary script function as described in the Scripting DFS. After the executing the script snippet PumpState holds the value “On”.



Any of the script functions provided by The Application Server can be invoked this way.

Syntax:

ScriptFunction ::= <FunctionName> ( {<Paramater>} { “,” <Paramater>} );

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:

ActiveX® Server:Other names for ActiveX Server are COM Server, ActiveX component, ActiveX EXE, ActiveX DLL.

Support for OLE Automation Compatible ActiveX ServersSupport 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;

Wonderware Training


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");



Wonderware Training


Lab 10 – Object Reuse

IntroductionIn a previous lab we created a $TankSystem template that contained other templates. It was useful as a cookie cutter for the many TankSystems we have in our facility, but every time we want to model another tanksystem we must fill in the IO reference information for the valves, pump and level transmitter instances. As it turns out, our facility has a well-defined naming convention that identifies how to access our device IO. We can use this convention along with some scripting in our templates in such a way that our devices will address themselves when they are deployed. All we need to do is name the TankSystem instance appropriately.

In order to accomplish this task, we will need some relative keywords in our scripting language that refer to contained and container objects. These words include Me, MyContainer, MyEngine, and MyPlatform. These keywords allow you to work your way up the container hierarchy. To move down to the contained objects you can use the contained name.


Add scripts to existing templates and note changes that are propagated to existing instances of the template.Create a new instance of a template and note the differences between that instance and the previously generated instance.




Tasks

Modifying Tank Template Objects1. Double click $XYTankSystem to open the editor and select the UDAs tab.

2. Click on the plus icon to add a UDA named IOSet with a Data type of Boolean and a Category of User Writeable.

Wonderware Training


3. Select the Scripts tab.

4. Click on the plus icon to add a Script named AssignIO.



5. Add the following:

Select an Execution Type of Execute

For the Expression enter Me.IOSet == 0

For the Trigger Type select WhileTrue

Add the following script to the Script area.

IF Me.AssignIO.ExecutionCNT >= 2 THEN

Dim Datasource as string;datasource = "InControl.Tagname.T" + StringRight(me.tagname,3);

me.DLInletValve.CLS.Inputsource = datasource + "_IV_CLS";me.DLInletValve.OLS.Inputsource = datasource + "_IV_OLS";me.DLInletValve.CMDOpen.OutputDest = datasource + "_IV_CMDOpen";

me.DLOutletValve.CLS.Inputsource = datasource + "_OV_CLS";me.DLOutletValve.OLS.Inputsource = datasource + "_OV_OLS";me.DLOutletValve.CMDOpen.OutputDest = datasource + "_OV_CMDOpen";

me.DLTransferPump.AuxContact.Inputsource = datasource + "_TP_AuxContact";me.DLTransferPump.CMDStart.OutputDest = datasource + "_TP_CMDStart";

me.DLLIT.PV.Input.InputSource = datasource + "_LT_PV";

Me.IOSET = true;ENDIF;

Wonderware Training


6. Lock the following attributesAliasesDeclarationsScriptsBasics


The Check In dialog box will appear. Enter Added AssignIO script for automatic configuration in the Comment field. Then click OK.

8. In the Deployment View, create an instance of the $XYTankSystem object and name the instance XYTankSystem_xxy where xx is your student number and y is the Tank System number (0 or 1 only).

Note: When the TankSystem instance is renamed, a dialog box with a warning is displayed.

Click OK.

Note: When creating an instance of this template, the instance will display a warning icon

on the new instance. This is OK. This can be cleared by adjusting the IO references from ---.--- to --- as a place holder for the actual reference to be applied later. If you have a warning icon with this template object, please notify your instructor.

Wonderware Training


9. Assign XYTankSystem_xxy to the XYLine1 Area.



10. Notice that XYTankSystem_001 needs to be re-deployed because it now includes the new script. Doing so will override (on runtime) the reference configuration hardcoded into the contained objects.

Deploy (cascade) the new Tank System instance and re-deploy (cascade) the XYTankSystem_001 and verify this with Object Viewer.

11. View the object in Object Viewer and verify that the configuration attributes for the new objects have the right reference.

Wonderware Training


Lab 11 – Averager

IntroductionThe QuickScript.Net scripting environment supported in Industrial Application Server is an extremely powerful extensibility tool.

One of the features of IAS is the ability to extend an object’s set of attributes (Namespace) by adding custom User Defined Attributes (UDAs). The scripting engine allows the customization of any object by internally calculating the data that a UDA is going to handle. Using this technique and internal reserved keywords of the scripting engine, it is possible to create objects that add new information to existing objects by just creating a containment relationship.

We will create an Averager object based on a new derived template that will calculate the Average of the PV attribute of any analog object in the Galaxy. The average will be calculated on a set of no more than 100 samples. These sample sizes can be configured by the application developer when the instance is created.


Create an instance of a UserDefined object.Configure UDAs and scripts.Monitor the new values using the Object Viewer.




Tasks

Create the Averager Template1. Right-click the $UserDefined object in the Template Toolbox and select New/Derived

Template.

Name your new template XYAverager.

2. Assign $XYAverager to your Template Toolset.

3. Double-click on the $XYAverager template object to open its editor and select the UDA tab.

Click on the Plus icon and add a UDA called Avg. Configure it as follows:

Data Type: Double

Category: Calculated

This is an array: Unchecked

Wonderware Training


4. Create another UDA and name the UDA QueueSize. Configure it as follows:

Data Type: Integer

Category: User writable

This is an array: Unchecked

Value: 50



5. Click the Scripts tab. Click on the Plus icon and add the following script:

Name: Calculate

Execution Type: Execute

Trigger Type: Periodic

Trigger Period: 00:00:00.0000000

6. Click the Plus to expand the Declarations section.

Wonderware Training


7. Add the following code in the Declarations section of the editor:

Dim valueQueue[100] As Double; 'Circular queue to hold the values for the average.Dim queueLength As Integer; 'Holds the current length of the queue.Dim nextElement As Integer; 'Holds the next element for the circular queue.

In the body of the script, type the following script:

'NOTE: The queueLength variable allows the object to know how' many values are stored in the queue.' This allows an accurate average when the object has not' stored all the values in the queue.

'Get next element for the queue and add the next value to the queue.nextElement = (nextElement Mod Me.QueueSize) + 1;valueQueue(nextElement) = MyContainer.PV;

'Verifies the queue is not filled up.If queueLength < Me.QueueSize Then

queueLength = queueLength + 1;Else

queueLength = Me.QueueSize;EndIf;

'Calulates the average with the values stored in the queue.Dim queueSum As Double;Dim i As Integer;

queueSum = 0.0;

For i = 1 To queueLengthqueueSum = queueSum + valueQueue[i];

Next;

Me.Avg = queueSum / queueLength;



Wonderware Training


8. Lock the following sectionsAliasesDeclarationsScriptsBasics



9. Create another script and name the script CheckQueueSize. Configure it as follows.

Execution Type: Execute

Expression: Me.QueueSize

Trigger Type: DataChange

In the body of the script, type the following script.

'Validate QueueSize everytime it changes'so it's always within the valid range.If Me.QueueSize < 1 Then

Me.QueueSize = 1;ElseIf Me.QueueSize > 100 Then

Me.QueueSize = 100;EndIf;

Wonderware Training


10. Lock the following sectionsAliasesDeclarationsScriptsBasics


The Check In dialog box will appear. Enter Added scripts for Average calculation and data validation in the Comment field. Then click OK.



Create and Test an Averager Instance12. In the Deployment View, create an instance of the $XYAverager object and rename it

XYAverager1.

Note: When the Averager instance is renamed, a dialog box with a warning is displayed.

Click Yes.

13. Assign XYAverager1 to the XYLIT object.

Wonderware Training


14. Right-click the XYAverager1 object and select Deploy the object On Scan.

15. Right-click the XYAverager1 object and select View in Object Viewer.


17. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab dialog box enter Averager and click OK.

18. Add the attributes Avg and QueueSize to the Watch Window to monitor the value.

19. Change the value of QueueSize to see how it reacts.




Wonderware Training


Section 4 – Extensions and Output Functionality

ExtensionsThe Extensions page is comprised of five main functional areas. These are described below.

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

Section ObjectiveThis section will familiarize you with an understanding of the Extensions environment and the OUtput Functionality for ApplicationObjects.



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.

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

Wonderware Training


9. Set the security classification for the attribute if available. See "Security Icons" in "Working with Object Editors" for more information.

10. Save and close the object editor to include the new attribute extensions in the configured object.

Output Functionality The following information applies to the functionality of InputOutput and Output extensions as well as the output function of the Field Reference, Switch and Analog Device objects.

If a single set request is made to a destination attribute during a single scan cycle, that value is sent to the destination. During a single scan cycle, though, more than one set request to the same destination is possible. In that case, folding occurs and the last value is sent to the destination.

The following occurs during a single scan cycle: Only the last value requested during a scan cycle will be sent to its destination when the object executes. Its status is marked as Pending as it waits for write confirmation from the destination object. All other set requests during that scan cycle are marked as successfully completed.

If one or more new sets are requested during the next scan cycle, then the second scan cycle's value is determined in the same way as described above. It is then sent to the destination when the object executes again and the value sent to the destination during the previous scan cycle is marked with successful completion status even if write confirmation had not been received.

In other words, within a single scan cycle, data is folded and only the last set requested is sent to the destination. For instance, an {11,24,35,35,22,36,40} sequence of set requests will result in a value of 40 being sent to the destination object. All other values result in successful completion status.

The exception to the above-described functionality is for Boolean data types used in User sets (sets from InTouch or FactorySuite Gateway). This functionality accounts for an unknown user input rate (for instance, repeated button pushes) with a consistent object scan rate for outputs, and therefore creates reproducible results. In this case, a combination of folding as described above plus maintenance of a queue of one element deep in order to better meet the expectation of users. To begin with, the first value set after the object is deployed (the default True or False) is always written to its destination.

Subsequently, the following occurs during a single scan cycle: A two-tiered caching scheme of a Value to be Sent and a Next Value to be Sent is implemented. The Value to be Sent is based on data change as compared to the last value sent to the destination object. The Next Value to be Sent is based on data change as compared to the Value to be Sent value. When the first data change occurs, the new value is cached in the Value to be Sent queue. Folding occurs if the same value is requested again. If another value change occurs, this second value is cached in the Next Value to be Sent queue. Again, folding occurs if the same value is requested again.

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

IntroductionExtensions allow you to add historization and alarming to certain parameters on your objects and UDAs. They also enable you to place input and output references on these extendable types. By extending a UDA in this manner, it can be used in scripting to promote the name of an object to a reference to the object. The difference is when you have the name of an object all you have is a string, however a reference to the object can be used to get properties and control the state of the object. The power of IO references combined with UDAs is explored in this lab.


Configure an object’s extensions to allow communication to other objects about certain parameters.View those changes in the Object Viewer and change their state.




Tasks

Extensions Configuration1. Double click on your XYTankSystem_001 instance to open its editor.

Select the UDAs tab.

Create a UDA named TankAlarm and configure it as:

Data type Boolean

Category Object writeable

Wonderware Training


2. Select the Extensions tab.



3. Select TankAlarm and configure it as follows:

Input extension checked

Source InControl.Tagname.TXXY_ALARM01

Alarm extension checked and locked

Category Process

Priority 500

Alarm message attribute me.Tagname

4. Save and close the editor and check in the object.

5. Right click on the TankSystem_001 object and select View in Object Viewer.

Optional: Modify the auto-config script to include Tank Alarm.


7. Right-click in the Attribute Monitoring section and select Rename Tab. In the Rename Tab dialog box enter Extensions and click OK.

Wonderware Training


8. Add the following attributes to the Watch Window:TankAlarmTankAlarm.InAlarmTankAlarm.AckedTankAlarm.TimeAlarmOnTankAlarm.TimeAlarmOffDLPlant.InAlarm (Note that this attribute is from the Plant area, not the XYTankSystem object.)




Wonderware Training

Section 5 – Additional Application Objects 5-109

Section 5 – Additional Application Objects

Introduction

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

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

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

Switch ObjectThis 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 ObjectThe 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 Integrated Development Environment (IDE) documentation.

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

Note: A UserDefined object can only contain ApplicationObjects.

Section ObjectivesBe familiar with Additional Automation Objects that represent some element of your application.Understand their hosting and containment relationships.



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.

Wonderware Training

Module 6

Alarming and HistorySection 1 – Alarming 6-3

Lab 13 – Alarming 6-9

Section 2 – Network Account Utility 6-23

Section 3 – Historization 6-33

Lab 14 – Historization 6-37

6-2 Module 6 – Alarming and History

Module ObjectiveObtain an overview and understanding of how the Industrial Application Server integrates with InTouch and InSQL.

Wonderware Training

Section 1 – Alarming 6-3

Section 1 – Alarming

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 App 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 (e.g. “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



Displaying alarms/events in InTouchThe Current Alarm Display is an ActiveX Control delivered with InTouch. The primary purpose of the control is to allow an InTouch Operator to view and acknowledge active alarms at runtime that are generated by alarm providers. Alarm providers can include local providers and providers on the network. Application Server (ArchestrA) is a key alarm provider. Key functions include:

Configuration at design time for subscription to specific alarm providers on the network for alarm reports. One or more Application Server platforms can be an alarm providers (and can be local or remote).Configuration at design time for subscription to specific alarm groups (or areas) in a provider. Groups (or areas) can be hierarchical, meaning sub-groups are automatically subscribed to.Display of key alarm information.Acknowledgment of selected alarms with a comment.Suppression of alarms (local filter only).

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


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



Wonderware Training


Lab 13 – Alarming

IntroductionA platform object can be configured to be an alarm provider to the InTouch Distributed Alarming infrastructure. The Alarm Logger database will log these alarms, and InTouch 9.0 supports two new alarm ActiveX controls to display them. These controls can be used to view streaming alarms as they occur or historical alarms and events recorded in the distributed alarm database.

In this lab we will configure your Platform to be an Alarm Provider to InTouch’s Alarm Logger database. We will configure the Platform and our Sinewave object in the IDE. Then we will configure the Alarm DB Logger Manager and start the logger. Finally, we will configure the Alarm Summary (AlarmViewCtrl) and the Alarm/Event History (AlmDbViewCtrl) controls to accept alarms from your Platform.


Configure Platforms to be Alarm ProvidersConfigure and start the Alarm Logger databaseConfigure the Summary and History controls to accept alarms.




Tasks

Configure the Platform1. Double-click on your Platform to open the Platform editor.

2. Check the InTouch alarm provider box and verify the Alarm areas list box is blank.

3. Close and Save the editor.

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 provide for the whole Galaxy.

Wonderware Training


Configure the AnalogDevice Object4. Double-click on the XYLIT object.

5. Select the Alarm tab.



6. Configure the Alarms tab as follows:

Check the box for Detect PV level(limit) alarmsCheck the box for Level alarms – HiSet the Limit to 80.0


8. Redeploy the Platform.

Wonderware Training


9. Right click on XYLIT and select View in Object Viewer.

10. Add the following XYLIT attributes to the Watch Window.PVHi.LimitHi.InAlarmHi.TimeAlarmOffHi.TimeAlarmOn



Configure the Logger Database11. Select Start/Programs/Wonderware/InTouch/Alarm DB Logger Manager to launch the

Logger Database

12. Click the Settings button to configure the database.

Wonderware Training


13. Configure as follows then click the Create button:

Server Name localUser Name sa Logging Mode ConsolidatedPassword [Check with your instructor for the correct password.]

The Success dialog box will display indicating the tables were created.

Click OK to continue.



14. Back at the Alarm DB Logger Manager – Configuration dialog box click Test Connection to test the database connection.

15. Click OK if connection succeeded, then click Next to continue.

Wonderware Training


16. At the Query Selection dialog box configure the Alarm Query as follows then click Next to continue.

Alarm Query \\<Provider Node>\Galaxy!<Area>

Where <Provider Node> is the platform’s node name, Galaxy is a fixed keyword and <Area> is the area of interest.



17. At the Advanced Setting dialog box, accept the default settings and click Finish.

18. Click Start to start the database logger then minimize it, but DO NOT close it.

Wonderware Training


View Alarm History and Event History19. Select Start/Programs/Microsoft SQL Server/Enterprise Manager to launch the SQL

Server Enterprise Manager.

20. In the left pane under Console Root expand Microsoft SQL Servers.



21. In the left pane, highlight Microsoft SQL Servers/(local)/Databases/WWALMDB/Views.

In the right pane, right click on v_AlarmEventHistory and select Open View/Return all rows.

Wonderware Training


Here you can investigate the details of the alarming history with time and date stamp, values, etc.



Wonderware Training


Section 2 – Network Account Utility

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 FactorySuite™ 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 IDE will stop functioning properly. If you delete the ArchestrA user account on an 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.

To recreate an ArchestrA user account 1. Start the Change Network Account utility by selecting Start/Programs/Wonderware/

Common/Change Network Account.

Section ObjectivesThis section will discuss the role of changing the network account and how to use the Change Network Account Utility to accomplish that task. After discussing this section the student will be able to:

Understand the role of the Change Network Account Utility, and;Have an understanding of how it can be configured.



The Change Network Account dialog box appears.

The data shown in this dialog box are those settings entered during the initial installation of an ArchestrA component on the computer. The password options are shown blank for security reasons.

Wonderware Training


The Change Network Account utility allows you to change the current data shown in the dialog box, including:

Changing the password of the current account.Creating a new local user account.Using an existing local machine or network domain account.

2. In a single-node ArchestrA system, create any account.

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

4. 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 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! We 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.

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. Open the Network and Dial-up Connections dialog box (see image below) and rename each card with a clearly identifiable function (for instance, "Supervisory Net" and "PLC net"). Different operating systems provide unique access to the Network and Dial-up Connections dialog box (in Windows 2000 Professional, click Start; point to Programs, Accessories and Communications; and then click Network and Dial-up Connections).

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.

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



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

Several other parameters must be configured to ensure successful node-to-node communications in the ArchestrA environment. You must configure the IP address and DNS settings as follows for each network card to function properly.

Do the following for each network connection

1. In the Network and Dial-up Connections dialog box, right-click the network connection and click Properties in the shortcut menu. The connection's Properties dialog box (see image below) is displayed.

Wonderware Training


2. Select Internet Protocol (TCP/IP) in the list of components used by this connection, and click Properties. The Internet Protocol (TCP/IP) Properties dialog box (see image below) is displayed.



3. For the supervisory network, select Obtain an IP address automatically. For the other network connections, select Use the following IP address. Consult your network administrator for the proper settings for the remainder of the parameters in this group.

4. Click Advanced. The Advanced TCP/IP Settings dialog box (see image below) is displayed. Click the DNS tab.

Wonderware Training


5. For the supervisory network, select Register this connection's addresses in DNS. For the other network connections, clear this check box.

6. Click OK.



Wonderware Training


Section 3 – Historization

Historization BackgroundThe history system supports historization of process data in distributed history architecture.

One or more InSQL products can be installed on the same network as the App Server Galaxy. The Galaxy can be configured to store history data into one or more of those InSQLs. Since the Engines use push technology to historize, the InSQL box does not have any ArchestrA software requirements.

Each Engine in the Galaxy is configured with the location of the InSQL storage node to which its history data is to be sent. This configuration is stored in an attribute within the Engine.

InSQL requires an InSQL 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 InSQL.

When an AutomationObject starts up it registers its configuration data with InSQL using an InSQL supplied interface. If the InSQL tag already exists, it means this object has been previously registered. If the InSQL 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 InSQL. The user does not need to run InSQL configure and import tags from App Server (as done with InTouch today).

For storage, the story is similar. When an object decides to store a new VTQ to InSQL, it pushes that storage update message, with the new VTQ, to InSQL using an InSQL supplied interface. InSQL must exist on a different node from the AutomationObject. The history primitive uses the previously-returned unique identifier for the InSQL tag that corresponds to the historized property to identify the tag being stored.

Note: Alarms are stored at the Platform, history is stored at the Engine.

History Configuration

Historizable Data Types for Attributes Attributes of the following data types support historization:

Float (numerical)

Double (numerical)

Integer (numerical)

Boolean (non-numerical)

String – Unicode (non-numerical)

CustomEnum (non-numerical)

Section ObjectivesFamiliarize you with the background concept of historization, and Enable you to understand details of historizable configuration.



maps to InSQL Integer

ElapsedTime (numerical)

Maps to InSQL Float, converted to seconds.

Entire arrays or portions of arrays are not supported.

All numerical attributes are sent to InSQL in the engineering units form exposed by the attribute, and InSQL does not scale the value. Additionally, the historized object does all change detection and value deadbanding. All update packets sent to InSQL are stored to disk.

Configuration of a non-numerical Attribute for Historization For an object that has non-numerical historizable attributes, the 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 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 InSQL at Object Deploy TimeWhen an AutomationObject is deployed that has been historized, the object causes a dynamic reconfiguration of the InSQL product. Each historized property causes a new tag to be created and configured automatically in InSQL at deployment time. The InSQL storage system to be configured is configured in the engine object itself.

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

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

Wonderware Training


Reconfiguration of InSQL at Object Undeploy TimeWhen an AutomationObject is undeployed that has been historized, object does not cause any dynamic reconfiguration of the InSQL product. In other words, the InSQL tag and all its history is left in the InSQL historian. This means the history data can still be examined in the future even if the AutomationObject is no longer deployed.

InSQL Installation and DeploymentInSQL is installed and deployed using its standard mechanism. InSQL can be deployed on any PC in the Galaxy, or on a PC outside the Galaxy but on the local network. InSQL 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 InSQL can be utilized by a single Galaxy. However, a single engine sends its history to only one InSQL.

A single InSQL can receive historical data from a single Galaxy only.

InSQL Value MappingThe update packet to be sent to InSQL 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 InSQL datatypes as specified below:

Enum – historize as Integer ordinal value

Strings – InSQL 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, InSQL clients do not handle NaN properly. Therefore, ArchestrA will convert the NaN value to a Null value representation just prior to sending to InSQL.

InSQL Quality Mapping The Industrial Application Server Data Quality is somewhat different than the InSQL data quality. The plan is for InSQL to support the OPC Quality definition. Thus, the 16-bit value for the OPC Data quality is sent to InSQL. 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 InSQL. This means that a point that has an identical value over some period of time with varying qualities will have multiple records stored to InSQL. The quality stored in InSQL is to be the actual quality of the attribute in App Server with no modification. However, InSQL may insert “artificial” quality (e.g. 24) and null value in the database when certain situations such as disconnects occur. It does this in cooperation with the ActiveFactory clients to project the right information on the client.

InSQL Timestamp mappingThe timestamp to be sent to InSQL for each attribute value/quality update is sent by the object in the VTQ packet. Both App Server and InSQL use UTC time.



Application Server History Storage PerformanceThe link from the Application Server to InSQL may fail or be down for any of a number of reasons:

The network connection to InSQL goes down unexpectedly.The InSQL storage node goes down or fails unexpectedly.The Galaxy Platform and its Engines which are generating history startup prior to InSQL node startup in a recovery situation.History data must be preserved in these cases by having it stored locally until the link to InSQL has recovered or InSQL 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.

Wonderware Training


Lab 14 – Historization

IntroductionAn Industrial Application Server engine object can be configured to historize properties of the objects it hosts by specifying the location of the InSQL node. When an object with a historized property is deployed on an engine that has been configured to historize, a tag is built in the InSQL MDAS group and the engine pushes the data to InSQL at the specified cycle (this cycle can not be faster than the engine scans). If a connection to the InSQL machine can not be made at deploy time, the engine will store the history to a path specified. In this lab, we will configure an object’s attributes to be historized by IndustrialSQL Server (InSQL). We will use the ActiveFactory Trend object in InTouch to trend these attributes.


Configure the object’s instances to be historized.Configure the App Engine and Platform to push data to InSQL.Check Industrial Application Server connection to InSQL Server.View data trend with the ActiveFactory Trend object in InTouch.




Tasks

Configure the LIT Template Object1. Double-click on your XYLIT Template object to open its editor.

Select the History tab.

Wonderware Training


2. Check the box for PV. Leave the Value deadband at 0.0. Set the Trend high to the maximum value of your object and the Trend low at the minimum value.

Then Lock all attributes.


Configure the TankSystem Template4. Double-click on your XYTankSystem Template object to open its editor.



5. Select the UDAs tab and create a UDA called InletValve with a Data Type of String and Category of User Writeable.

6. Create three (3) more UDAs as follows:

Name Data Type Category

LIT Float User Writeable

OutletValve Integer User Writeable

TransferPump Integer User Writeable

Wonderware Training


7. Select the Extensions tab.



8. For InletValve check Input extension and configure the Source as me.XYInletValve.PV. Also, check History extension and lock it.

Note: If you configure the Input Extension as me.XYInletValve it will default to me.XYInletValve.PV.

Wonderware Training


9. Configure the remaining UDA extensions as follows:

Name Input Extension Source History extension

LIT checked me.XYLIT.PV checked and locked

OutletValve checked me.XYOutletValve.PV checked and locked

TransferPump checked me.XYTransferPump.PV checked and locked


11. Redeploy the Tank System instance.



Configure the Engine12. Double-click on the Engine object.

Wonderware Training


13. On the General tab, check the History box for Enable storage to historian. Verify that 100MB is selected for the Store forward deletion threshold.



14. Configure the Historian by typing in APU00 as the selected node

or

click on the ellipses box to activate the Browse Node dialog box and highlight the

APU00 node.

15. Click OK.


Wonderware Training


Configure the Platform17. Double-click the Platform object. At the General tab configure the History store forward

directory as follows:

Enter C:\S&F for the History store forward directory


19. Redeploy the Platform.

20. Configure the Deploy dialog box as follows and click OK.

Check the box for Cascade DeployCheck the box for Force Off ScanCheck the box for OnScan



21. Click Close.

Wonderware Training


Configure ActiveFactory Trend22. Select Start/Programs/Wonderware/ActiveFactory/Trend to launch the ActiveFactory

Trend.

23. Right-click on the Server icon and select Connect.



24. Configure the Connect to IndustrialSQL Server dialog box as follows:

InSQL Server APU00

Select Use SQL Server authentication

Login Name wwUser

Password wwUser

Click OK.

25. Expand the Public Groups/Analog Tags and locate your object name in the TagName area below.

26. Double-click the tag to add it to the Trend.

27. Click on the Live Mode icon to configure the Trend to update dynamically.

28. In the Auto refresh mode dialog box select 1 second from the drop down box and click OK.

Wonderware Training


Your trend will appear similar to the following example:



Wonderware Training

Module 7

Securing the GalaxySection 1 – Security Overview 7-3

Lab 15 – Application Server Security Settings 7-13

7-2 Module 7 – Securing the Galaxy

Module ObjectiveConfigure, deploy, and test security with InTouch and Application Server.

Wonderware Training

Section 1 – Security Overview 7-3

Section 1 – Security Overview

ArchestrA™ security is designed to prevent users from performing unauthorized activities. This includes users of:

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

Section ObjectiveIntroduce Security with Application Server and InTouch.



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

For example, a certain attribute of the DiscreteDevice may be set by the operator to change its status while a different attribute may be set by a technician. These attributes are meant for different people, Operator (operate) and Technician (tuning). Configuring access to all users for all AutomationObjects on individual bases would be a time-consuming and repetitive effort. Thus, configured Roles and Security Groups can be applied to Users to enable easier configuration of the Security Model.

Security Groups are simply the grouping of objects that you want to behave in the same way with respect to security. Every AutomationObject belongs to exactly one Security Group. By default all new objects belong to the Default Security Group, which cannot be removed. Roles generalize Users function, such as Intake Operator or Dispatcher. Roles are granted permissions onto a number of Security Groups. If, for instance, a Role is granted Tuning access to a Security Group, then that role has write permissions to all object attributes with a security classification of Tuning (but none other). Roles are also granted utility functions-based permissions, such as Deploy or Can Edit.

For example, a Role of Software Engineer is created. This Role has full permissions to modify the objects in the 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.

Wonderware Training


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

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 Industrial 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 IDE closes.When you switch to None from another Authentication Mode and click OK, the 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 IDE and anywhere in the ArchestrA environment are granted based on the logged in user's associated roles and permissions. The 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 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 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 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

Wonderware Training


the new login data. If that fails, the trusts are being reestablished by the controller, and you should retry at a later time.If you attempt to log in to ArchestrA on a workstation running Windows 2000, login will fail until you properly set the TCB privilege in Local Security Policies. Do this as follows: On a Windows 2000 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 IDE, SMC, and View require their users to be authenticated so that the appropriate permissions can be confirmed. An authenticated user is granted the sum of all Permissions within their assumed Roles.

Supported Operating System User 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 Launching 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 will appear:The user explicitly chooses a Log On option from within the UI. It is not necessary to explicitly Log Off before logging on using a different User Profile. The previous user will be implicitly logged off.

Username and Password are entered onto this dialog.

If OS Authorization is being used then the user will also be required to select from a list of accessible domain name for the user being logged in.

Logon ObjectA Logon COM object is provided for use by any OS client utilities that need to log on to Application Server. This COM object either provides a Log-on Dialog or is driven silently by an automation interface. OS authentication and log on dialogs may be leveraged.

Wonderware Training


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

Attribute Security ClassificationsOperators interact with AutomationObjects by accessing their Attributes. For example, a Valve is opened by setting its object’s Command Attribute to OPEN.

Attribute SecurityClassifications classify Attributes of AutomationObjects (like the above Command attribute) from a security perspective. They are:

FreeAccess – Any User can write to these attributes to perform safety or time critical tasks that could be hampered by an untimely logon request (e.g. halting a failing process). This does not require the user to have any privileges.Operate – Operators write to these attributes during normal day-to-day operations. These include Attributes such as Setpoint, Output and Control Mode for a PID Object, Command for a Discrete Device Object, etc. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write.Secured Write – Operators write to these attributes for normal interaction with a highly secured object forces re-authentication. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write. The AutomationObject will reject the write requested via the return status and the user must re-enter the login details.Verified Write – Operators write to these attributes for normal interaction with a very highly secured object. This is similar to Secured Write, however it also requires a second user authentication. The second user must also be assigned to the Security Group of this AutomationObject, to allow the write.Tune – Writing to these attributes is considered a tuning activity. Examples are attributes that adjust alarm setpoints, PID sensitivity, etc. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write.Configure – Writing to these attributes is considered a significant configuration change. For example, a PLC register that defines a Discrete Device input. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write. It also requires that the Object is currently OffScan.View-Only – The attributes are never written to at runtime, regardless of the user's permissions.

There are two other situations where an Attribute's Security Classifications are specified:When a User-Defined Attribute is configured.When an Engineer overrides the Attribute Security Classification within a Template editor.

Note: Overriding Security Classifications is not permitted within Instances.

Security Across Multiple GalaxiesThe ability for user profiles to span multiple galaxies will be supported in future versions.



Wonderware Training


Lab 15 – Application Server Security Settings

IntroductionAs we work with the security settings within the IDE we will set up various Roles and Users and configure them with different sets of permissions. We will then observe the differences in the Object Viewer as we logon as various users.

In this lab, we will create an instance of the SecurityTest Template, configure it, create an Instance, and deploy it. Objectives

Create, configure and deploy an Instance SecurityTest Template called “XXSecurityTest_001”.Configure the Security settings for AppServer.




Tasks

Create and Configure a Derived Template Called $XYSecurityTest 1. Expand Template Toolbox.

Right-Click $UserDefined Object. Create a New/Derived Template and rename it XYSecurityTest.

2. Assign $XYSecurityTest to your Toolset.

Wonderware Training


3. Double-Click $XYSecurityTest to open this object and select the UDA tab.

Click the + symbol to add a UDA.

4. Name the attribute Att1_FreeAccess.

Press Enter.

Click the Shield symbol to select the security level.

Select Free Access.

5. Repeat steps 6 and 7 for the following attributes:

UDA Name Datatype SecurityAtt1_FreeAccess Boolean Free AccessAtt2_Operate Boolean OperateAtt3_SecuredWrite Boolean Secured WriteAtt4_VerifiedWrite Boolean Verified WriteAtt5_Tune Boolean TuneAtt6_Configure Boolean ConfigureAtt7_ReadOnly Boolean Read Only



6. Save and Close the editor and Check In the object.

Create an Instance Called $XYSecurityTest 7. In the Model View, create an instance of XYSecurityTest (it will be XYSecurityTest_001) and

assign it to your Line1.

Wonderware Training


Configure Galaxy Security8. From the Galaxy menu, select Configure/Security.



9. Select Galaxy for the Authentication Mode.

Wonderware Training


10. Click the Security Groups tab.

11. Click the Add button to add a new group.

Name the new object TestGroup.



12. Select the Default Security Group.

13. Select the XYSecurityTest_001 instance object from the list in the right pane.

Wonderware Training


14. Drag XYSecurityTest_001 onto TestGroup in the left pane.

Select TestGroup again.

Note that XYSecurityTest_001 is now associated with TestGroup in the right pane.

15. Click the Roles tab.



16. Click the Add button.

Name the new Role TankOperator.

Press Enter.

Double-Click in the Access level field and assign TankOperator an access number of 500.

17. Click the Users tab.

Wonderware Training


18. Click the Add button to add a new user.

Name the new user Operator.

Press Enter and keep Operator selected.

Check TankOperator in the bottom pane. This will include Operator in the TankOperator role.

19. Click the Change Password button to change the password.



20. Enter a new password and click OK. Here we are using the word password as the password but your instructor may have you select a different password.

21. Click the Roles tab.

Select TankOperator.

Expand TestGroup in the Operational permissions pane in the lower right corner.

For the TankOperator TestGroup check the box for

Can acknowledge Alarms

Can modify “Operate” attributes

TestGroup will be checked automatically.

Wonderware Training


22. Select Administrator.

Expand TestGroup in the Operational permissions pane in the lower right corner.

For the Administrator TestGroup check the box for

Can modify “Configure” attributes

Can modify “Operate” attributes



23. Click OK.

You’ll notice now that we have set the Galaxy to something other than Security of None, we now have to identify who it is that is accessing the Galaxy.

In the future you can always change users by selecting from the Galaxy/Change User from the menu bar.

24. Enter Operator and the password and click OK.

Wonderware Training


Deploy the SecurityTest Instance 25. In the Deployment View, right-click on the XYSecurityTest_001 instance object and deploy it.

26. Open the Object Viewer, add a watch window and rename the Tab to Security.

27. Add the following attributes to the Watch Window:Att1_FreeAccessAtt2_OperateAtt3_SecuredWriteAtt4_VerifiedWriteAtt5_TuneAtt6_ConfigureAtt7_ReadOnlyScanStateScanStateCmd

Compare the attributes that are available while being logged on as the Operator vs. the Administrator vs.the Developer.

28. In the Object Viewer, from the menu bar select Options/Change User.

29. Change to Administrator and click OK.

Notice the task bar at the bottom of the Object Viewer now indicates the Administrator is logged in.



30. in the Object Viewer test the functionality that is available to the Administrator. Modify the values of the Att* attributes to verify the security setting configured in the previous steps.

Note: Your instructor will demonstrate the Configure User Information dialog box where you can change the default settings for various functions such as Prompts, Initial Scan state for deployed objects, Scan state defaults and other User defaults

31. Right click on your XYSecurityTest_001 object and select Properties.

Select the Change Log tab.

Here you see the log of the changes made that affect the object.

Wonderware Training


32. Click Close.

33. Verify that the Alarm DB Logger Manager is still running.



View Alarm History and Event History34. Select Start/Programs/Microsoft SQL Server/Enterprise Manager to launch the SQL

Server Enterprise Manager.

35. In the left pane under Console Root expand Microsoft SQL Servers.

Wonderware Training


36. In the left pane, verify that Microsoft SQL Servers/(local)/Databases/WWALMDB/Views is still highlighted.

In the right pane, right click on v_EventHistory and select Open View/Return all rows.

Here you can investigate the details of the event history and the details associated with each event.



IDE Security37. In the IDE, select Galaxy/Configure/Security.

Wonderware Training


38. Select the Roles tab and select Default role.

Under IDE Permissions/Framework configuration uncheck can modify the security model.



39. Select the Administrator role.

Verify under IDE Permissions/Framework configuration that can modify the security model IS checked.

Note: Actually, the can modify the security model cannot be set to unchecked for the Administrator.

Click OK to close the Configure Security dialog box.

Wonderware Training


40. In the IDE, select Galaxy/Configure/Security.

You will be reminded that the Operator has not been configured to change security.

41. Click No.

42. Logon as Administrator.

In the IDE, select Galaxy/Config Security. You should see no error and be able to config security.



Wonderware Training

Module 8

Galaxy MaintenanceSection 1 – Exporting and Importing a Galaxy 8-3

Lab 16 – Exporting/Importing CSV Files 8-13

Section 2 – System Management Console (SMC) 8-29

8-2 Module 8 – Galaxy Maintenance

Module ObjectivesObtain an overview and understanding of:

How to Export and Import Galaxies;How to use the System Management Console to manage platforms.

Wonderware Training

Section 1 – Exporting and Importing a Galaxy 8-3

Section 1 – Exporting and Importing a Galaxy

Exporting Galaxy ObjectsWhen exporting Galaxy objects there are three options available. These are:

Exporting Automation ObjectsExporting All Automation ObjectsGalaxy Dump

Each of these has unique features and characteristics which are discussed in this section.

Exporting Automation ObjectsUse the 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 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.

To export an object

1. Select an object in the Template Toolbox or Application Views pane.

2. From the Galaxy menu, select Export/AutomationObject(s).

Section ObjectiveThis section will discuss some fundamental functions dealing with Galaxy Maintenance. Specifically, we will illustrate how to Export for future use and how to Import a galaxy created previously.



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.

3. The Export AutomationObject(s) dialog box is displayed. In the export 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


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

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

To export all automation objects

1. From the Galaxy menu, select Export/All AutomationObject(s).

Wonderware Training


2. The Export AutomationObject(s) dialog box is displayed. In the export 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.

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

Exporting a Galaxy Dump File Object instances and their configuration data can be exported to a comma-delimited format Galaxy dump file (.csv extension).



Note: This function only dumps instances. Templates cannot be dumped. The .csv file contains the configuration for the checked in versions of the selected objects as well as the checked-out objects of the user who initiates the Galaxy dump. The file contains only those attributes that are unlocked and configuration time-writeable, one column per attribute. Attributes that are locked, calculated or runtime writeable only are not saved to the file. Attributes that are not text based (for example, type QualifiedStruct) are not dumped. Object Help files are not dumped.

To export objects to a Galaxy dump file

1. Select an object in the Application Views pane. You can export more than one instance with this function by first multi-selecting objects (Shift+Click). Also, you can dump all instances derived from a template by selecting just the template.

2. Select Export on the Galaxy menu and then click Galaxy Dump. The Galaxy Dump save dialog box is displayed.

3. Browse to the name and location of the .csv file to which you want to dump the selected instances. Click Save to continue or Cancel to end the export function. The Galaxy Dump progress box is displayed.

Wonderware Training


4. 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 that has been created.

Galaxy Dump File (.csv) Structure Dumped objects are organized in the resulting .csv file based on the template each is derived from. 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.

Importing a Galaxy Load File Object instances and their configuration data in an existing Galaxy can be exported to a comma-delimited format Galaxy dump file (.csv extension). A .csv file can be edited in most text editors and spreadsheet programs. Using editing functions like copy and paste, you can create quantities of already-configured objects ready to be imported into your Galaxy.

Note: The contents of the .csv file is determined by the original Galaxy dump. A load file contains only instances. Templates cannot be dumped and loaded.

Important: The Dump contains only Object Instances. For the Load to succeed, the templates from which those objects were derived must already exist in the Galaxy.

To import a .csv file

1. Select Import on the Galaxy menu and then click Galaxy Load. The Galaxy Load dialog box is displayed.

Wonderware Training


2. In the Galaxy Load dialog box, browse to locate the .csv file that contains the objects and configuration data you want to import. Select the file and click Open to continue or Cancel to end the import function. 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.

3. Choose the preferred conflict resolution and click OK. A progress box is displayed during the Galaxy load process. Click Cancel to terminate the Galaxy load process.

A Galaxy Load dialog box appears indicating that the Load was successful.



All objects that were changed or created during the Galaxy Load process are checked out to the logged in user.

Note: A comment line in a .csv file created in Microsoft® Excel may create an unintended default-value object. To avoid this scenario, open the .csv file in Notepad to ensure the comment line does not contain quote marks.

Wonderware Training


Lab 16 – Exporting/Importing CSV Files

IntroductionThere are times when it may be desired to modify certain parameters of objects outside the IDE environment and then load those changes back into the IDE. This lab will illustrate how objects can be exported and modified externally. Subsequently they can be imported so as to create additional instances of the objects.

We will create an instance of your Tank template and export it to a CSV file. There we will modify it slightly and import it back into the IDE creating a new instance of that Tank with the changes. A Flow Indicator Transmitter (FIT) object will then be created and another instance of the Tank with the FIT will be created. Again, we will export those objects, modify them externally and import them back into the IDE creating a new instance of Tank with the changes.


Use the Galaxy Dump utility to export object instances.Modify the file externally.Use the Galaxy Import utility to import the modified file.




Tasks

Galaxy Dump and Load 1. Select the TankSystem_001 instance and its children. Then Export to a Galaxy Dump by

either right-clicking on the Tank, and selecting Export/Galaxy Dump.

Or,

From the File menu select Galaxy/Export/Galaxy Dump.

2. Save the file as TankTest1.csv.

Wonderware Training


You will see the Galaxy Dump dialog box indicating the dump as complete when it finishes.



3. Open TankTest1.csv in Notepad.

Note: We are using Notepad instead of Excel to open the file because CSV files built in Unicode currently do not translate correctly in Excel.

Wonderware Training


4. For Tank and its children (Inlet Valve, Outlet Valve, Transfer Pump and LIT) change the references to a different suffix (e.g., 001 to 301). Remember, the last digit represents a tank number so it must be 0 or 1.

Note: It is recommended that you turn off WordWrap for ease of viewing.



5. Select File/Save As and save the file as TankTest2.csv. Be sure that it is a csv file.

Wonderware Training


6. In the IDE, select File/Import/Galaxy Load and select TankTest2.csv.



7. At the Galaxy Load Conflict Resolution dialog box select Skip and click OK.

Wonderware Training


You will notice the Tank has been imported essentially du;licating our original XYTankSystem_001.



Galaxy Dump and Load – PH Object8. In the Template Toolbox, derive a template called XYPH from an Analog Device.

Wonderware Training


9. Assign the XYPH object to your Tank System TemplateToolset.

10. Create an instance of the XYPH template and assign it to your TankSystem_001.



11. Right click on your XYPH object and select Export/Galaxy Dump.

12. Save it as XYPH.csv.

Wonderware Training


13. Open XYPH.csv in Notepad.

14. Copy the last line and change the reference in the last line to XYPH_002.

15. Copy the last line again two more times and change the references to XYPH_003 and XYPH_004.

16. Select File/Save As and save the file. Be sure that it is a csv file.



17. In the IDE, select File/Import/Galaxy Load and select your XYPH.csv file.

18. At the Galaxy Load Conflict Resolution dialog box select Skip and click OK.

Wonderware Training


You will see your original XYPH object and the additional three that you created directly in the csv file. Since we did not change the TankSystem instance association we see they are assigned to our XYTankSystem_001.



Wonderware Training


Section 2 – System Management Console (SMC)

About System Management ConsoleThe System Management Console (SMC) provides ArchestrA AppServer 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 Platform Manager Some of the key features of the Platform Manager are that it:

Runs with minimal ArchestrA and operating system requirements, equivalent to "Safe mode" Uses the local platform as the gateway to the ArchestrA application Does not rely on the Galaxy Repository to exist Allows viewing of the layout of the Galaxy Repository, Platforms, and Engines Provides the ability to set Platforms and Engines OnScan or OffScan Provides the ability to start and stop Platforms and Engines

Starting Platform Manager Platform Manager is a common component of an Application Server application and it is available from any PC node in the application that has a deployed platform; therefore, you do not need to install it onto each node. This ensures that all nodes used within a galaxy have access to Platform Manager.

When you use Platform Manager, you can access the platforms and engines deployed to the local PC node and to any other PC node in the Galaxy. Platform Manager does not require the GalaxyRepository to be installed on the PC node.

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

Section ObjectivesUnderstand the role of the System Management Console, and;Have an understanding of how it can be configured.



To Start Platform Manager Ensure your AppServer application is running. Start Windows and click Start to start your programs. Select Programs/Wonderware/System Management Console.

If Platform Manager has security enabled, the Platform Manager Login dialog box appears.

From the Platform Manager Login dialog box, enter your User Name and Password. If the configured security is OS User Based, then select the domain from the Domain list box. Click OK.

Wonderware Training


After successfully logging in, or if no security is enabled for Platform Manager, the Platform Manager appears under the ArchestrA System Management Console (SMC) root node.

Console 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 include the Platform Manager, the Log Viewer, the DAServer Manager, and the Galaxy Database Manager.

The contents of the details pane changes as you select items in the console tree.

Details PaneThe details pane is comprised of two main elements:

Column headings: when Galaxy Database Manager is selected in the console tree, two columns are displayed, Node and Galaxy. The Node column identifies which node a galaxy resides on. The Galaxy column displays the galaxy’s name. Use this information when backing up and restoring galaxies.Data window: displays galaxy data.

The contents of the details pane changes as you select items in the console tree.



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

There are four authentication modes for security that can be enabled for Platform Manager: No authenticationGalaxy authentication modeOS User Based authentication modeOS Group authentication mode

When no security is enabled from the IDE, the user is automatically logged into Platform Manager as "DefaultUser." Without security, the logon dialog box does not display when Platform Manager is launched and the user is granted all permissions.

If the security configured from the IDE requires Galaxy authentication, OS User Based authentication, or OS Group authentication, then some of the existing users and roles are not valid and the user may not be able to perform some operations.

Galaxy Authentication Galaxy authentication requires the user to log into Platform Manager every time the utility is started.

OS User Based Authentication OS User Based authentication allows users who have matching OS accounts to log in, while all others are rejected.

OS Group Authentication In OS Group authentication, the user defines roles that match OS Groups and at log in, the OS Groups are matched with the roles.

Console Menu Commands Upon opening the System Management Console there are a wide selection of options available from the menu and icon bar:

The following commands are available from the Platform Manager Action menu when you select a platform or engine in either the console tree or the details pane.

Wonderware Training


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.

The following commands are available from the Platform Manager View menu when you select a platform or engine in either the console tree or the details pane.

Command 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

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 location



Platform Manager Toolbar Buttons The following toolbar buttons may appear on the console toolbar, but will vary depending on the object that you select in the console tree and its current state.

Log ViewerThe Logger is an ArchestrA utility that records information regarding the activity occurring on the computer. For example, it records start-up data, error conditions, and DAServer information.

Bookmarks 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

Command Description

Button Description Back

Forward

Up one level

Show/Hide Console Tree/Favorites

Refresh

Help

Filter

Enable/Disable Message Filter

Find

Fast Mark

Export

Print

Print Preview

Wonderware Training


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

Security for the log viewer is set at the galaxy level.

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.

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.

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 IDE or other ArchestrA component.

Note: The Log Viewer displays error messages in red-highlighted stripes. These indicate malfunctioning processes and should be resolved quickly. Warning messages are displayed in yellow stripes. These indicate major events in the system.

A good strategy for troubleshooting problems

1. Gather as much information first about the process that is malfunctioning. For instance, you attempted to deploy an object in the IDE and a message was displayed stating the deployment was not completed. Note the function you attempted and the message you received.

2. Open the Log Viewer by clicking Start, pointing to Programs and then to Wonderware, and then clicking System Management Console. In the SMC, select Log Viewer and then the node the IDE is located on. Look for red and yellow messages. Also, use the information you collected about the failed process to search for clues in the logged messages.

3. Use the Find command on the View menu to single out messages by message text or other category of data, or use the Filter command on the View menu to reduce the number of displayed messages based on message, time range or terminal session criteria.



The following chart indicates the key differences in Log Viewer and WWLogger.

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 message1. Right-click the message and click Add Bookmark on the Bookmark submenu.

2. In the Add Bookmark dialog box, either accept the default name (Bookmarkx where x is a number in an ascending sequence) or overwrite it with something more descriptive. You can change the bookmark name in the Bookmarks dialog box at a later time. See "To manage bookmarks" below.

3. Click OK to set the bookmark or Cancel to terminate the process.

To set a fast bookmark on a message1. Right-click the message and click Fast Bookmark on the Bookmark submenu. A default

naming sequence is applied to the message (Bookmarkx where x is a number in an ascending sequence). Alternatively, you can set a fast bookmark by selecting the message and clicking the Fast Bookmark icon on the toolbar.

2. Change the bookmark name to something more descriptive, if necessary, in the Bookmarks dialog box at a later time. See "To manage bookmarks" below.

To go to a bookmarked message1. On the View menu, click Go To.

2. In the Go To dialog box, enter the name of the message’s bookmark by typing it in the box or selecting from the list.

3. Click Go To. The Go To dialog box remains open.

4. Use the Previous and Next buttons to go to the nearest bookmarked message above and below, respectively.

5. When you are done searching, click Close.

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



To manage bookmarks1. On the View menu, click Bookmarks.

2. In the Bookmarks dialog box, you can manage current bookmarks and create new ones. The bookmark list shows the current set of bookmark names and associated Message No. (the same number as the No. column in the message window). The bookmark list provides several functions.

3. For instance, to rename a bookmark, select it, press F2 and type the new name. Note that each bookmark must have a unique name; so you cannot bookmark two messages with the same name.

4. To go to a bookmarked message, double-click on it in the list or select it and click Go To.

5. To remove one or all bookmarks from your logged messages, select a message and click Remove, or click Remove All.

6. To add a new bookmark, select the message you want to bookmark in the message window and click Add. This function is comparable to a fast bookmark. Rename it by pressing F2.

7. When you are done, click Close.

Note: Bookmarks are not saved when you quit the Log Viewer application. To mark your message log more permanently, use the Mark command on the View menu.

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

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.

Wonderware Training

Module 9

DAServers and DI ObjectsSection 1 – DAServers 9-3

Section 2 – DI Objects 9-7

Section 3 – FactorySuite Gateway 9-9

Lab 17 – FactorySuite Gateway 9-15

Section 4 – Intermittent Network Configuration 9-25

9-2 Module 9 – DAServers and DI Objects


DAServers and DI Objects and how they relate to the connectivity of our application to external data.FactorySuite Gateway and how it can enhance the connectivity of your application.

Wonderware Training

Section 1 – DAServers 9-3

Section 1 – DAServers

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

Wonderware's DAServers also come with an exclusive new user interface called the DAServer Manager, which is installed as a Microsoft® Management Console snap-in. Its end-user benefits include simple remote server activation, configuration and operation, and extensive protocol diagnostic troubleshooting.

Several standard features are available with each DAServer, including: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 DAServers support connectivity to numerous protocols and products. Wonderware's current DAServers 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 Modbus® Serial protocol

Configuration DAServers can be configured using the DAServer Manager utility. The DAServer Manager is an MMC shell capable of displaying specific configuration pages for each configuration node. This utility allows browsing and editing of servers on different nodes.

DAServers are hot configurable. In other words, they are configurable while the server is running or even acquiring data. Certain restrictions imposed by the underlying 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.

Section ObjectiveBecome familiar with DAServer and its use with the Industrial Application Server.



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

Wonderware Training

Section 1 – DAServers 9-5

You must create the Device Protocol Layer (server specific) modules with the DAServer, and all three sets of modules are required for a fully functioning DAServer.

Plug-insPlug-ins provide protocol translation functionality for device integration clients. Typical Plug-ins communicate in DDE, SuiteLink or OPC protocol, and serve as interfaces between their clients and the DAS Engine. You can disable a protocol when customizing the installation for your DAServer.

DAS EngineThe DAS Engine is a middleware component that exposes two sets of unique interfaces, one for communicating with Plug-ins and one for communicating with Device Protocol Layer components. It encapsulates common tasks for the DAServer, like handling the item database, distributing data to clients, propagating clients' requests to the protocol, and providing diagnostics.

Device Protocol LayerThe Device Protocol Layer provides translation between the hardware specific protocol such as Modbus and CIP and the DAS Engine interface.

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.

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.

Wonderware Training

Section 2 – DI Objects 9-7

Section 2 – DI Objects

IntroductionDevice Integration (DI) Objects are designed for applications that connect to the Industrial Application Server. They represent the application's network and devices, and mirror the actual device hierarchy. In the Industrial Application Server, Device Integration (DI) Objects are a subset of Automation Objects available in the Template Toolset of the Integrated Development Environment (IDE). As a subset of these Automation Objects, Device 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 IDE/Galaxy. This facilitates the DAServer installation process for end-users.

DI Objects in the 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:

Section ObjectiveBecome more familiar with DI Objects and their use with the Industrial Application Server.



The differences between the Application and DI Objects are listed below: DI Objects are associated with a DAServer.DI Objects include some extra primitives in addition to the common Primitive (also hidden by default. A special dialog provides access to the attributes developers might need to override.).DI Objects include extra dependency files.DI Network Objects are hosted by an AppEngine, not an Area.

This impacts the Deployment view within the IDE. The Host must be deployed before the object can be deployed.

DI Objects can be hosted by each other or by DI Networks.GUIDs tie the host and the hosted object together.

DI Devices and DI Network objects have extra tabs within their editors to configure ScanGroups, BlockReads, and BlockWrites.

Wonderware Training


Section 3 – FactorySuite Gateway

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.

A primary purpose of FS Gateway is to translate between ArchestrA MX protocol and other protocols. For instance, an Industrial 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 FactorySuite products without using InTouch tags. Using FS Gateway as a protocol translator allows direct connection to an Industrial Application Server. FS Gateway can replace OPCLink, which translates OPC to DDE or SuiteLink.

FS Gateway is also useful for legacy servers, controllers, and operating systems. Gateway can translate older DDE to the newer SuiteLink protocol, enabling legacy products to connect to newer systems.

Other Connectivity ToolsIndustrial Application Server can access device data by using client application objects. These DI Objects ($DDESuiteLinkClient, $InTouch proxy, $OPCClient) enable the server to interface with I/O devices that use DDE, SuiteLink, InTouch tags, or OPC protocol.

Other protocol connectivity tools include third-party OPC servers, the Archestra DAS Toolkit, the Rapid Protocol Modeler Kit, the ActiveX SECS-II/GEM kits, and the InTouch Tag Creator.

I/O servers provide connectivity for devices using DDE, FastDDE, and SuiteLink protocols. I/O servers can connect every FactorySuite 2000 and FactorySuite A2 component, as well as PLC, RTU, DCS, and ESD systems.

Section ObjectiveThis section discusses integration to third party applications, specifically through the FactorySuite Gateway



You can build I/O servers using Wonderware's Rapid Protocol Modeler (RPM) Kit. The RPM Kit can handle both serial and TCP/IP communications with either ASCII or binary protocols to connect FactorySuite client applications to devices with non-standard protocols.

DAServers (Data Access Servers), provide simultaneous connectivity between plant floor devices and DDE, SuiteLink and/or OPC-based client applications running under Microsoft Windows. The DAS Toolkit allows you to create a DAServer specific to your needs. DAServer architecture is modular, allowing for plug-ins for DDE/SL, OPC, and other protocols.

Wonderware’s InControl software offers connectivity to third-party OPC servers and clients by allowing you to create an OPC Server and/or OPC client. You can use the OPC set of interfaces to collect and transfer data between software packages from any vendor. OPC uses the client-server model and the Microsoft COM/DCOM® protocols for vendor-independent data transfer. The InControl OPC Server consists of these three primary types of objects: server, group(s), and item(s). Each OPC item object represents a single data element in the data source and has a name, value, time stamp, and quality. Items also have attributes and properties. OPC groups manage the attributes of each item contained in them. The OPC server maintains the properties of all OPC items. The InControl OPC server uses SuiteLink for communications.

In addition to its own database, SQL Server can act as a gateway to systems based on Oracle, Sybase, Ingres and other databases. Once connected to SQL Server, external databases operate as if they were part of the native SQL Server database. Data from multiple databases can be combined in reports and queries.

Refer to the FactorySuite support website, especially the Compatibility Matrix, for more information on specific connectivity tools.

FactorySuite Gateway FAQs1) What is FactorySuite Gateway?

FactorySuite (FS) Gateway is an integration server and protocol translator that can be used to integrate classic FactorySuite products with newer ArchestrA based products, as well as exposing FactorySuite data sources as OPC Servers to third party applications and external systems. FS Gateway therefore provides:

A Universal Protocol Converter for Wonderware ProductsExposes FactorySuite A2 as an OPC ServerIntegration for classic servers

2) How is FS Gateway Delivered?

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

3) How is FS Gateway Licensed?

FS Gateway is available for use with any Wonderware Product, at no additional charge. The only stipulation is that it must be always used in conjunction with a Wonderware product, either in a server or client connection capacity.

Wonderware Training


Release 1.0 of FS Gateway will not have license enforcement as part of the Wonderware License Management Utility but will be restricted for use with a Wonderware product via a paper license. A future version may contain license enforcement.

4) What product client protocols are supported?

DDE, FastDDE, Suitelink and OPC

5) What is the value provided by FS Gateway?

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

6) Why is FS Gateway needed?To remove NetDDE dependencyTo provide connectivity to earlier versions of InTouchTo provide NT support which will allow connections to classic products that have not been migrated to later Operating Systems.To provide OPC connectivity to FS products (e.g. InTouch and Industrial Application Server)To replace the OPCLink product used when connecting InTouch to OPC Servers.To provide Industrial Application Server data for 3rd party clientsTo provide a mechanism for the transport of IAS data between two different Galaxies.

7) Does FS Gateway provide Galaxy to Galaxy communications with ArchestrA and the Industrial Application Server?

FS Gateway does provide the means for data access from an ArchestrA Object Attribute in Galaxy A to an ArchestrA Object Attribute in Galaxy B, in the same fashion that an Object Attribute in Galaxy A could receive data from any OPC Server. The plan is that a future release of the Industrial Application Server will have built-in "Intergalactic Communications". FS Gateway can still be used for this in the interim, but an even better solution is forth coming.

8) How is security controlled with FS Gateway?

When used with the Industrial Application Server, Role-based security is employed. That means that a User is defined on the node where the FS Gateway is installed. That User account is linked to an ArchestrA Role, which is linked to a Security Group, which is linked to individual Object Attributes. Therefore, the defined user can only access those attributes which it is assigned within the Galaxy. This needs to be managed carefully as any program that utilizes that user account on the FS Gateway node, either locally or remotely can access the associated attributes, with no specific knowledge of which external application is accessing the Galaxy.



9) What are the common uses for FS Gateway?Exposes InTouch as an OPC Server Exposes InSQL as an OPC Server (live data only) Exposes IAS as an OPC ServerBasic Galaxy to Galaxy Data Access Exposes classic IO Servers (DDE) as a OPC DA or SuiteLink ServersBasic Read/Write Data Access from Classic InTouch (pre-7.11) to a Galaxy Factory Suite Integration (DT analyst, SCADAlarm, InBatch) to a Galaxy Replaces InTouch OPCLinkActs as a Data Concentrator for a client wanting access to many different sources.

10) What capability is there to browse tag and attribute values for products using the FS Gateway?

FS Gateway can "browse" InTouch and OPC DA Servers Data Connections. This is accomplished inside the SMC which is the centralized place for configuration and diagnostics. All other data connection items are manually entered (or alternatively can be imported from a CSV file) before the data can be browsed. This "browse" is the ability to navigate the actual native information (either on InTouch or OPCServer). Once a group is created and the items created inside the group then a client can browse this "configured" data.

For the Industrial Application Server, it is necessary to manually enter the item names. This can be done on the IAS platform first and then exported into a .csv file and then imported into the FS Gateway. Once these items have been manually entered the OPC Client will be able to browse the data. The user can still access data that has not been configured for browsing but the item name must be known. SuiteLink inherently does not allow for browse capabilities.

11) How is the FS gateway configured and managed?

The FS gateway is configured like any other DAServer, by using the ArchestrA System Management Console or SMC.

12) What data is accessible in the Industrial Application Server Galaxy via the FS Gateway?

The FS Gateway exposes 4 basic data types in a Galaxy. They are Boolean, String, Float and Integer.

13) What is FS Gateway compatible with?

Client ProductsDDE Clients [including FASTDDE V2 (pre-FactorySuite2000) and FASTDDE V3 (FactorySuite2000 Plus)]SuiteLink ClientsOPC Clients (DA v2.05)

Server ProductsDDE Servers

Wonderware Training


InTouch Data SourceArchestrA Galaxy Data source from Industrial Application 2.0 SuiteLink Data SourceOPC DA Servers (v2.05)

14) Can I run more then one instance of FS Gateway on a single computer?

No, only a single instance of the FS Gateway can be run on a single computer at the same time. This is similar to our DAServers.

15) Can I have multiple galaxies as data sources connected to an instance of FS Gateway?

No, the FS Gateway must be on the same platform as the Application Server and only one instance of Application Server can reside on a particular platform.

16) How many clients can I have connected to an instance of FS Gateway?

As many as you like!

17) How many Data Sources can I have connected to an instance of FS Gateway?

The FS Gateway can act as a data concentrator and can access as many sources as you would like to connect to (with the limitation of only one can be an Application Server).

18) What OS Versions is FactorySuite Gateway 1.0 Compatible with?Windows XPWindows NT 4.0Windows 2000Windows 2003

For additional information or details on how to access and configure Factory Suite Gateway please refer to the Wonderware FactorySuite Gateway User’s Guide.



Wonderware Training


Lab 17 – FactorySuite Gateway

IntroductionThis lab will identify the steps needed to configure both the Instructor machine and the Student machine for FactorySuite Gateway.


Use the DAServer Manager to create and ArchestrA Object on the Instructor machine.Configure the ArchestrA Object.Understand how to activate the server in the SMC.In the Student machine, create and configure a DDESuiteLinkClient object in the IDE to connect to the Instructor machine.




Tasks

Instructor Configuration

Note: FactorySuite Gateway 1.0 must be previously installed on the Instructor's computer.

1. From the Start menu, select Programs/Wonderware/System Management Console to open the SMC.

Wonderware Training


The System Management Console opens as shown below.

2. Expand DAServer Manager/Default Group/Local/ArchestrA.FSGateway.1 and select Configuration.



3. Right-click Configuration and select Add ArchestrA Object.

4. Name the added object MyGalaxy.

Wonderware Training


5. Configure MyGalaxy as follows:

Reconnect Attempts: 3

Reconnect Period: 30000 MSec

Read Only: Checked

6. Save the configuration.

7. Select ArchestrA.FSGateway.1.



8. Right-click ArchestrA.FSGateway.1 and select Activate Server.

Or,

Click the Activate Server icon on the icon bar.

Wonderware Training


Student Configuration9. In the Deployment View, create an instance of the $DDESuiteLinkClient object by dragging

it from the Template Toolbox to the Application Views pane.

10. Name the instance XYInstructor.

11. Double-click XYInstructor to open the DDESuiteLinkClient editor.



12. Configure the General tab as follows:

Server node: <instructor's node name>

Server name: FSGateway

Communication protocol: SuiteLink

13. Select the Topic tab.

Wonderware Training


14. Add a new Topic by clicking in the Add Topic button [+] in the Available topics section, name the topic ArchestrA.


At the Check In dialog box, enter"Initial configuration and setup." in the Comment field and click OK.

16. Assign XYInstructor to XYAppEngine.

17. Deploy XYInstructor. Verify that Initial Scan state is set to On Scan.

18. View the object in Object Viewer.



19. Type XYInstructor.ArchestrA.ABLIT in the Attribute Reference textbox (where ABLIT is the Instructor’s LIT object) and press the Go button to add the reference to the Watch Window.

20. Press OK in the dialog box that pop-ups.

21. Verify that you're reading data from the instructor's galaxy.

Wonderware Training


Section 4 – Intermittent Network Configuration

IntroductionIntermittent networks are physically distributed networks that, because of low bandwidth and/or high traffic, tend to have delays or breaks in communication.

Any distributed network that is routed (uses modems or radio transmitters) is considered intermittent. A wide area network is also considered intermittent because of the time lag in transmitting data. Industries such as water and waste control, telecommunications, natural gas and oil distribution, in which fast response is not critical, can often use intermittent networks.

Intermittent networks are usually controlled by SCADA (supervisory control and data acquisition) systems in which a central computer is used to communicate to remote PLCs or RTUs. A SCADA system gathers real-time data, transfers the data to a central site, performs the necessary analysis and control, and displays the information visually in an appropriately organized fashion. SCADA architecture can easily be expanded to handle additional remote sites and I/O points.

A SCADA host performs centralized alarm management, data trending, and operator display and control. The priority of SCADA is collecting and recording data events and alarms.

In a SCADA system, current status and commands are handled by local controllers (RTUs and PLCs). SCADA systems employ RTU or PLC protocols including Modbus, AB-DF1, and DNP3.0. SCADA communications can use a range of wired (lease line, dialup line, fiber, ADSL, cable) and wireless media (licensed radio, spread spectrum, cellular, CDPD, satellite). IO servers and DA servers collect data from remote units, then send this data to the Industrial Application Server using OPC, or SuiteLink protocols.

Critical needs for the SCADA industry are timestamping, disaster recovery, security, and dealing with bandwidth limitations.

Timestamping: For RTU protocols where data timestamps may be retrieved from the remote site, it is necessary that a DA Server or I/O Server acquire this timestamp and make it available as a parameter of the data. Given the data's value and its timestamp, it is possible to transfer the data's value and timestamp into the historical database or process the data with event analysis algorithms. Such data transfer and processing require the development of specific Application Server objects designed for this task. RTU event information: For RTU protocols where event information may be retrieved, particularly as structured blocks with point ID, value, timestamp, and description, a DA Server or I/O Server must acquire the structured information and make it available for processing. Typically this requires special programming to transfer the data to a database. In particular the data may be transferred directly into the Industrial SQL Server historian.

Disaster Recovery: For insuring the integrity of an operational system where the central site is "at risk" from fire, tornado, hurricane or other catastrophe, it is important to establish a site, physically separated from the central one, that has replication capability. The replication capability includes having duplicated hardware, and requires that software configuration and key 'state' information is periodically propagated from the central site to the recovery site. Each disaster recovery scenario will be unique, thus it is important to consult with system integration experts regarding the design of communications equipment, hardware and the configuration of the software.

Section ObjectivesUnderstand the concept on Intermittent Networks and how to configure for them



Security: Galaxy security is configured via the Security dialogue of the IDE. Users/Groups are assigned, roles are created and mapped to Galaxy privileges, and individual Application Objects are allocated to Security Groups. For geographically distributed systems it is likely that the topology will involve the use of more than one Domain Controller. Such a distributed topology allows that computer nodes at different sites are joined to different Domain Controllers; the operators, engineers and technicians log into those Domains. As long as their membership is then authenticated against Galaxy authorized groups, they will have access to the capabilities of the system. There is one specific requirement for the account used when installing the Industrial Application Server bootstrap at each computer node. For a contiguous Galaxy, that account must be identical on all computers in the system, i.e. it must be one Domain, one user name and its associated password. The configuration of Microsoft Security with Active Directory and DNS supports invoking such 'cross-domain' accounts when configuring the bootstrap service at installation time. It is important to properly configure the DNS settings for the NIC adapter to insure that multiple Domains are visible to the computer.Bandwidth limitations: Bandwidths of 56K or slower are dealt with using RTU technology through a DAServer or I/O server.

Configuration and Deployment

Distributed InTouch HMIsInTouch NAD (Network Application Development) can be used to design and configure systems, and to maintain graphical interfaces in a physically distributed system. The server maintains a master copy and clients maintain a copy of the master, so that if the master is unavailable, the client keeps working. Note that remotely notifying client applications of InTouch over a slow network is limited by the number and size of changes that may be effectively transmitted within a reasonable amount of time.

Note: When NAD is used in a Terminal Services environment on a Win2003 machine, a share must be created to the Master application even if the Master is on the Terminal Server Node.

When Not to Use Cascade DeploymentFor large numbers of Platforms and Engines residing on computers that are situated over slow network connections, it is not recommended that a Cascade Deployment of the entire Galaxy be initiated. For such networks it is important to deploy the Platforms separately. Also, Platforms that have complex combinations of Areas and Objects or large numbers of Objects should be selected in smaller groups and deployed as groups.

Note: DCOM: In setting up the network, be careful in setting blocked ports. Some DCOM ports need to be open to communicate with OPC. Leave open the ports that interact between FactorySuite components.

Wonderware Training


#

��

��

�� !"� �!�#

$�%�&�� '�#"��( �) �

*+�

��*�

$*��

+)�+(( ,)

-. +( �

�/ 01 ��

2& 3) 4�

-. -. -.

-. � �,

� '5� � 6

��0

7�,��6��)

*,08&�, )��

�0)��&�8�

�

(�) �

*+�

��*�

$*��

+)�+(( ,)

-. +( �

�/ 01 ��

2& 3) 4�

-. -. -.

-. � �,

� '5� � 6

��0

7�,��6��)

*,08&�, )��

�0)��&�8�

$�%�&�� '�#"��

�

(��)

�� !"� �!�

��#"' &

��%��" &�*+

�,�-�.+�

&"'�

+�9��

��/&"�'��

�"��" '�(� �

'!��& �#�)0�.��%��'1"'��"'1�� "�'

/�'2"1*� �"�'�� . ��

�*+��%"��3��

��%��

�'!*��" &��++&"� �"�'��%��

*+5�+��

��1�(-

��*��

�� !"� �!�#

/�'��&��



Reducing data traffic is especially important in intermittent networks. This can be accomplished in many ways. Please refer to the Deployment Guide for detailed recommendations for reducing data traffic.

Wonderware Training

Module 10

VisualizationSection 1 – Visualization 10-3

Lab 18 – Properties Visualization 10-13

Lab 19 – Alarm Connectivity in InTouch 10-33

Lab 20 – Tank System Visualization 10-39

Lab 21 – InTouch Tag Connectivity 10-67

10-2 Module 10 – Visualization

Module ObjectiveObtain an overview and understanding of how the Industrial Application Server integrates with InTouch and InSQL

Wonderware Training

Section 1 – Visualization 10-3

Section 1 – Visualization

Integration with Other FactorySuite® ProductsIn a few short years, the AppServer has emerged as the engine for e-business, acting as the development platform for server-based applications, a key connector for integrating Web and legacy systems and the launching pad for the next generation of IT infrastructure such as enterprise portals and Web services. The AppServer is becoming the central piece of a larger, more complex middle-tier computing infrastructure.

Because the fundamental ArchestrA™ architecture of AppServer comes bundled with an array of products, such as databases, server operating systems, and Integrated Development Environments (IDEs) it naturally follows that it act as the centerpiece of a much larger platform, one that also includes integration, portal and edge servers—not to mention related technologies such as identity management systems.

This trend has been long in coming. The recent Gartner report looked to label this evolution, calling this extended AppServer platform the "application server platform suite."

The following diagram illustrates the concept of integration with existing systems, or, in our case, other FactorySuite systems.

In this more detailed example it is clear that with the ArchestrA™ architecture of AppServer, integration with FactorySuite is clearly the fundamental solution to plant floor management and coordination.

Section ObjectiveThis section will familiarize you with an understanding of how Industrial Application Server integrates with InTouch and InSQL from a visualization perspective



In the following lab we will use the AppServer to interface with InTouch to see how the integration with InTouch leverages the visualization of both InTouch and AppServer.

InTouch IntegrationInTouch’s communications protocol support has been expanded beyond SuiteLink and DDE capabilities to include Message Exchange. WindowViewer acts as an anonymous Engine when accessing Message Exchange. This means it has no attributes that can be accessed by Message Exchange clients, and that it is not configured, managed or viewed as an AutomationObject within the AppServer Galaxy. InTouch advises (subscribes to) only those items that are active. This would be the currently displayed Window items and items needed for script execution. This minimizes the Message Exchange subscription activity to those elements that are currently active.

Tag Browser

The browser enables InTouch WindowMaker environment to select an App Server database source as a Tag Source for remote tags and browse through the namespace of the Galaxy. An object attribute or property of an attribute is to be mapped to an InTouch remote tag.

Access NameA pre configured Access Name called “Galaxy” is available in WindowMaker for Message Exchange access. This Access Name will only be relevant for InTouch in the ArchestrA environment. There will be no user configurable settings for this access name.

Wonderware Training


Tag SourceTo create a Tag Source within InTouch the user will be required to give the tag dictionary a name. Select the predefined Access name “Galaxy” and this will preset the Tag Source Type with a value of “Galaxy”. The user then enters the connection information for the dictionary:

Username

Password

Name of Galaxy

Galaxy Location (This is the node where the Galaxy Repository is located.)

Tag BrowserWith the new Tag Source, the user is presented with a list of all the objects within the target galaxy. He can expand objects to see either the contained objects or the runtime accessible attributes. The browser does not expose those attributes that start with an “_” (i.e. marked as hidden) or any attribute of type QualifiedStruct. The Column mappings are as follows:

Tagname = ObjectTagname.Attributename

Datatype = See list in next section for the datatype mappings.

Access Name = “”

AlarmGroup = Objects Area

Comment = Name of the Template that the instance was derived from

If the user has selected a tag from the App Server Browser then the next time a Browser is launched from InTouch the App Server Browser will be automatically launched.

The following restrictions apply when the App Server browser is launched:Only runtime visible attributes in a single Galaxy’s namespace are viewable, this will include the capability to switch between an Objects TagName and its HierarchicalName . The selection will be based on:

Runtime visible attributesFrom a Currently Checked in AutomationObjectWhere the attribute name does not have an “_” following a “.”

The browser does not allow browsing of attribute datatypes that are not supported. See the datatype mapping table in a next section for the list of attribute datatypes and their mapping to InTouch.The browser disallows selecting attributes that would result in an InTouch item name length greater than the maximum allowed by InTouch, which is currently defined as 95 characters. Those attributes are not viewable in the browser The burden falls on the App Server developer to use concise enough names to fit within the limitation of InTouch’s item name string length. The name displayed from the Galaxy is the Object “TagName”.”AttributeName” plus “[1]” for each array dimension. The name length must include all of these and the maximum length of a DotField name. So this allowable length for a displayed attribute name as 80 characters.The browser allows selection of a property of an attribute as detailed below. By default, the Value property is selected when the attribute is selected.

Attribute Data TypesThe following list is the Tag Source data types that will be displayed within the Tag Browser.



BooleanIntegerFloatDouble (Cast to InTouch Float)String Time (Cast to InTouch String)ElapsedTime (This will be cast to InTouch float convert to seconds)Reference (Cast to InTouch String)Enumeration (Cast to InTouch String)

Attribute PropertiesThe WindowMaker Tag Browser and the Message Exchange client in WindowViewer add and recognize special extensions to each Attribute in order to provide access to information that otherwise would not be available to InTouch. These extensions are optional and do not need to be used by the InTouch application. However, applications that are concerned with status and quality information will likely use these extensions heavily. These items extend the name space of attributes to include additional “properties” that WindowViewer can expose to application scripts and Windows®. For example, the reference to “TIC101.PV.#ReadSts” provides access to the MxStatus information for the subscription to “TIC101.PV”. This information is very useful for displaying extended information that is exposed by Message Exchange.

These items do not exist as object attributes in App Server (nor in Message Exchange as attributes) as named elements. This is purely a client-side extension (supplied in the client abstraction layer) that makes them appear to exist to the client. The Client Abstraction Layer obtains the information that is provided by these elements from Message Exchange API calls (e.g. UserGetStatusDescription(), UserGetQualityDescription()).

Attribute Extension DataType PurposeNone Coerced This is the default case. Means no extension was supplied.

The item should be read/written as normal, with the value datatype coerced as appropriate to InTouch native type. Failed read or write status information can be obtained if the client subscribes in addition to the #ReadSts or #WriteSts items described below. Example: “Pump1.PV”.

Wonderware Training


.#VStringfor floats/doubles attributes only:.#VString1.#VString2.#VString3.#VString4

String(read-write)

Sets up a subscription to the reference that is prefixed by “.#VString”. This is the underlying reference. Returns the current value of the underlying reference as a string (via coercion) when both reads and writes are working correctly. However, if the UserGetAttribute returns bad status, this item returns an abbreviated Status description string (based on MxStatus) instead of the value. The abbreviated status description strings are:“?Pending” – for pending“?Warning” – for warning“?Comms” – for communications error“?Config” – for configuration error“?Oper” – for operational error“?Security” – for security error“?Software” – for software error“?Other” – for other error

If the status is good but the quality is bad, this item returns the Quality description string (available from Message Exchange) instead of the value. Only when quality and status are both good, or when quality is uncertain and status is good, for UserGetAttribute does it return the value as a string (this may require coercion if the type returned by Message Exchange is not a string). When uncertain, the value is always suffixed with a “?” to indicate the uncertainty of the value. For example, “3.14 ?” or “True ?”.

When a write is performed to this item, the client abstraction layer does the UserSetAttribute to the underlying reference. The return status from the UserSetAttribute call is used to generate a status string, which is placed in the return value for this item. This status will always be “?Pending” initially. Later, when the write completes, the returned string is updated as follows. If the write does complete successfully, the returned value for this item reverts back to the current value for the underlying subscribed reference as a string as described above. If the write returns an error or pending, the \Status item continues to show the last write status even if subscription updates continue to come in on reads. Error in write status is therefore given priority over any read status. This applies for only 20 seconds, at which time the value reverts back to the read value. When the window is deleted, then the logic resets for future subscriptions to this item.For example, “Pump1.PV.#VString” actually registers the reference “Pump1.PV” with Message Exchange. The Client Abstraction Layer strips off the .#VString string and applies the special logic described here.For formatting of Floats/Doubles to a string format, the “.#VStringN” options (where N=1-4) are provided. The N indicates the number of decimal places to return in the formatted string. For example, “3.1234” would be a valid returned string for “.#VString4”. The “.#VString” acts as if N=0 for float and double.

Attribute Extension DataType Purpose



.#EnumOrdinal Integer(read-write)

Contains the currently read ordinal value for attributes of Qualified Enum type. This is a way of returning an integer for enumerations rather than a string. Since qualified enum attributes return a string to InTouch by default, and InTouch may need an integer for some animation links, this extension allows the integer value to be accessed by applications. Only exposed for attributes of type Qualified Enum. This causes a subscription to the underlying item and does not require that the item is already previously subscribed to. Example, appears in InTouch as “Pump1.PV.#EnumOrdinal”. When this item is registered with the client abstraction layer, it strips off the .#EnumOrdinal part of the string and registers “Pump1.PV” with Message Exchange. When the value updates, the client abstraction layer returns the ordinal integer value for the enumeration rather than the string.

.#ReadSts String(read-only)

Contains the current read-status of the subscribed to item that this string is concatenated to (e.g. appears to InTouch as “TIC101.PV.#ReadSts”). Provided by the MxStatus structure and translating it to a string. Blank (empty string) if status is OK. Otherwise, contains the abbreviated translated MxStatus string. The abbreviated status description strings are:“?Config” – for configuration error“?Comms” – for communications error“?Oper” – for operational error“?Pending” – for pending“?Warning” – for warning“?Security” – for security error“?Software” – for software error“?Other” – for other error(These strings are localizable within InTouch).

NOTE: This item cannot be written to since it is status of read only.

NOTE: If the associated item (for example TIC101.PV) is not currently subscribed, then this returned string is blank “”.


Wonderware Training


Data Type Support

ArchestrA Attributes/Properties can be of several datatypes that do not directly map to InTouch’s four primary datatypes. The following table defines how the client abstraction layer maps datatypes for read and write operations. It also describes the datatypes that the Galaxy Dictionary exposes within InTouch’s Tag Browser.

.#WriteSts String(read-only)

Contains the last write-status of the item that this string is concatenated to (e.g. appears to InTouch as “Pump1.Cmd.#WriteStatus”). Provided by the MxStatus structure and translating it to a string. Blank (empty string) if status is OK. Otherwise, contains the full translated MxStatus string. Otherwise, contains the abbreviated translated MxStatus string. The abbreviated status description strings are:“?Config” – for configuration error“?Comms” – for communications error“?Oper” – for operational error“?Pending” – for pending“?Warning” – for warning“?Security” – for security error“?Software” – for software error“?Other” – for other error

(These strings are localizable within InTouch).

NOTE: This item cannot be written to since it is status of write only.

NOTE: If the associated item (for example TIC101.PV) has not yet been written to, then this returned string is blank “”.


Attribute/property datatype

InTouch datatype Notes

Float Float – 32 bit Pass thru.Double Float – 32 bit If double is IEEE NAN, then convert to float IEEE NAN. If

overflows, set .quality to bad and pass float IEEE NAN. If double fractional value is a smaller fraction than the smallest float fraction of 1.17549E-38, treat as 0.0 float and set .quality to Good. (This is consistent with the double-to-float coercion in MxValue).

Boolean Discrete False = 0, True = 1Integer Integer – 32 bit Pass thru.String (always Unicode) String – MBCS

( multi-byte character set encoded )

Truncate string if is too long for InTouch. Set quality uncertain if it does so. Retain both bytes of each Unicode character.

Time String – Unicode (MBCS)

Format as appropriate string for locale. Use MxValue conversion to string.

ElapsedTime Supported. Pass as float seconds. MxValue supports coercion to this type.

MxDataType String – MBCS Pass the string.MxSecurityClassification String - MBCS Pass the string.



The table on the following page indicates a very detailed description of how the value/quality mapping to various InTouch animations is to be implemented.

Sample Detailed Mapping Table:

MxQuality String - MBCS Pass the string.MxReference String – MBCS Pass the reference string portion only as Unicode.MxCategorizedStatus String - MBCS Pass the string.MxQualifiedStruct Not supported Not supported. Return bad data quality and empty string.MxQualifiedEnum String – MBCS Pass the enum string. The integer ordinal value can be

accessed by applications by referencing .#EnumOrdinal. For example, “Pump1.PV.#EnumOrdinal”.

Array of Strings String – MBCS(read-only)

Put each element of the array into a comma separated string, such as: “String1,String2,String3”Up to the maximum string limit of InTouch string value. If truncate, then associated quality sent to InTouch will be set uncertain. Cannot write to an entire array of Strings.

All arrays Integer, Float, String, or Discrete.

Only support the subscription to a single element of an array. In that case the conversions above apply. Otherwise, return empty string with quality Bad. An array shows up once and only once within the browser. For example, Object.AttributeArray[1]. The browser returns 1 as the index into the array and the user can change it to the required value such as [3]. Single elements of arrays are writable (attribute-category permitting).

MxInternationalizedText String This at runtime is accessed as a String type.

App Server Data Type

App Server Value

App Server Quality

InTouch Analog Animation

InTouch Discrete Animation

InTouch String Animation

InTouch String (#VString)

float/ double 3.14 Good 3.14 On Msg 3.14 3.14float/ double 3.14 Uncertain 3.14 On Msg 3.14 3.14 ?float/ double 3.14 Initializing 3.14 On Msg 3.14 Initializingfloat/ double 3.14 Bad 3.14 On Msg 3.14 Badfloat/ double NaN Good 0.00 Off Msg 0 NaNfloat/ double NaN Uncertain 0.00 Off Msg 0 NaN ?float/ double NaN Initializing 0.00 Off Msg 0 NaNfloat/ double NaN Bad 0.00 Off Msg 0 NaNfloat/ double 1.7E308 Good 0.00 Off Msg 0 1.7E308float/ double 1.7E308 Uncertain 0.00 Off Msg 0 1.7E308 ?float/ double 1.7E308 Initializing 0.00 Off Msg 0 Initializingfloat/ double 1.7E308 Bad 0.00 Off Msg 0 BadCust Enum Open Good 0.00 Off Msg Open OpenCust Enum Open Uncertain 0.00 Off Msg Open Open ?Cust Enum Open Initializing 0.00 Off Msg Open InitializingCust Enum Open Bad 0.00 Off Msg Open BadBoolean True Good 1.00 On Msg 1 TrueBoolean True Uncertain 1.00 On Msg 1 True ?Boolean True Initializing 1.00 On Msg 1 Initializing

Attribute/property datatype

InTouch datatype Notes

Wonderware Training


Note: This table applies to good MxStatus. If MxStatus is bad, then the #VString string will indicate the abbreviated status category such as “?Comms”. For other animations such as Analog, when MxStatus is bad, no operation is performed (no value is sent to InTouch and the previous value is left as is).

LMX, NMX Client Abstraction LayerThe client abstraction layer has been modified to allow for Message Exchange communications. When using Message Exchange, the client abstraction layer (and WindowViewer) can communicate to a single AppServer Galaxy at a time. In addition, the client abstraction layer may be using SuiteLink or DDE at the same time. To use Message Exchange, WindowViewer requires that a single AppServer Platform object, and its prerequisites, be previously configured and deployed to the PC upon which WindowViewer is to run. A Platform can be shutdown when WindowViewer is running (for example by using the SMC). This situation is handled gracefully, meaning WindowViewer continues to run and communicate with other applications using SuiteLink or DDE. However, all subscribed remote tag references to MessageExchange must receive bad data quality. When the Platform starts back up, WindowViewer resumes its communications to MessageExchange.

IO StatusWindowViewer provides the status of each communications channel via the special (internal) “IOStatus” access name. Within WindowMaker, the user can create a discrete tag that monitors this special access name for the communications status to Message Exchange. The name of the item on the “IOStatus” access name is the name of the topic. Since the topic name does not apply

Boolean True Bad 1.00 On Msg 1 BadString In the bank Good 0.00 Off Msg In the bank In the bankString In the bank Uncertain 0.00 Off Msg In the bank In the bank ?String In the bank Initializing 0.00 Off Msg In the bank InitializingString In the bank Bad 0.00 Off Msg In the bank BadInteger 45 Good 45.00 On Msg 45 45Integer 45 Uncertain 45.00 On Msg 45 45 ?Integer 45 Initializing 45.00 On Msg 45 InitializingInteger 45 Bad 45.00 On Msg 45 BadTime 5/10/2002

11:06:44 AMGood 0.00 Off Msg 5/10/2002

11:06:44 AM5/10/2002 11:06:44 AM

Time 5/10/2002 11:06:44 AM

Uncertain 0.00 Off Msg 5/10/2002 11:06:44 AM

5/10/2002 11:06:44 AM ?

Time 5/10/2002 11:06:44 AM

Initializing 0.00 Off Msg 5/10/2002 11:06:44 AM

Initializing

Time 5/10/2002 11:06:44 AM

Bad 0.00 Off Msg 5/10/2002 11:06:44 AM

Bad

ElapsedTime 5 03:42:22.22 Good 445342.22 On Msg 445342.22 445342.22ElapsedTime 5 03:42:22.22 Uncertain 445342.22 On Msg 445342.22 445342.22 ?ElapsedTime 5 03:42:22.22 Initializing 445342.22 On Msg 445342.22 InitializingElapsedTime 5 03:42:22.22 Bad 445342.22 On Msg 445342.22 Bad

App Server Data Type

App Server Value

App Server Quality

InTouch Analog Animation

InTouch Discrete Animation

InTouch String Animation

InTouch String (#VString)



for Galaxy communications, the topic name is assumed to be “Galaxy” for this case. So if the user creates a Discrete Tag that monitors “IOStatus:Galaxy”, this tag provides the communications status to message exchange. In all normal situations (even if the network is down), this status returns 1 (or good) status. This is because the Galaxy communications is established locally via LMX. Only when an unusual situation develops, such as the local Bootstrap or local Platform being shutdown locally, will the communications status ever go to 0 (or bad).

Similar to the previous item, WindowViewer also provides the status of a communications channel via a special item called “Status” that exists on every topic. Therefore, the Galaxy Access Name also supports a special item called “Status” that indicates the status of the communications channel. This status behaves the same as the one that exists on the IOStatus access name for the Galaxy item.

Note that this basically makes “Status” a reserved word by InTouch, such that there should be no object name in the Galaxy called Status. This is not enforced anywhere (other than by the user). If there is an actual Galaxy object called Status, InTouch cannot see it.

Quality DataThe AppServer data quality on read operations (subscriptions) includes two major parts, the first the AppServer enumeration and the second the OPC quality. InTouch uses only the OPC quality part, placing it in the .Quality field for the remote tag. The client abstraction layer pulls out the OPC quality part and returns it to InTouch. InTouch places this part in the .Quality field of the remote tag.

Read and Write StatusMessage Exchange read and write operations return an MxStatus structure which defines detailed error information when an operation fails. This structure can then be translated into a human-readable string by Message Exchange. InTouch makes this string information available to the user for both read and write operations. This is accomplished though remote tag references that end in the strings “#VString”, “#ReadSts” and “#WriteSts”.

Galaxy SecurityMessage Exchange operations are all processed as UserGet and UserSet requests and security checking is performed by the receiving AutomationObject. Within InTouch both user sets and script sets are treated the same.

The Galaxy can be configured to use either AppServer or InTouch security for user authentication and authorization.

When Galaxy Security is in use no users will need to be created in the InTouch environment. AppServer users will be authenticated against the AppServer security system. Domain users would be authenticated through the OS. The AppServer Security Model contains the AccessLevel used within Traditional InTouch Applications so that they can maintain the mechanisms for controlling screen display. InTouch will then return the log in information to the same “$Operator” Tags as is defined within the InTouch 9.0.

An additional script function has been added to InTouch that enables the user to write a script that can determine if the currently logged in user has a defined “Role”. This enables the InTouch developer to integrate their screen display scripts with the AppServer security model (enables AccessLevel to be ignored).

If an InTouch Application is using InTouch mode then there is no “Trust” relationship between InTouch and the ApplicationServer. If InTouch Security is being used then the user will always be defined as the “Default” user.

Wonderware Training


Lab 18 – Properties Visualization

IntroductionWhen using InTouch as the view component for Industrial AppServer the InTouch application must reside on a node with a Bootstrap and Platform object deployed. In this configuration InTouch will use the message exchange functionality of the Platform, enabling Galaxy namespace browsing and increased data communication functionality. In this lab you will configure a remote tag source to point to the galaxy, and map the ApplicationObject properties to InTouch Animation Links for viewing.


Set up properties in InTouch and configure tag sources to link them to our ArchestrA application.

Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.(e.g., if the user is John Burns, Valve would be JBValve) This will eliminate problems when we deploy our objects in a common galaxy later in the course



Tasks

Configure InTouch Properties1. Copy the appropriate application to your Drive C:

Note: Your instructor will provide you with the correct application.

2. Open InTouch.

3. In the InTouch Application Manager dialog box, select Tools/Find Applications to locate the Application provided by your instructor.

Wonderware Training


4. Click on the WindowMaker icon to open InTouch WindowMaker.

5. Select the Properties window of the Application and click OK.



6. Double click on the text object (#) following the Attribute.PV.#String.

Wonderware Training


7. Select the Value Display, String.

8. Delete any existing expression and double-click in the white space area of Expression:

9. Click on the ellipse to create a new tag source definition.



10. Select New to create a new Tag Source.

Wonderware Training


11. Configure the Tag Source as follows then click OK:

Tag Source Name: Your Galaxy Name

Access Name: Galaxy

Tag Source Type: Galaxy

GR node name: Your Node Name

Galaxy name: Galaxy currently running on your node

Generic Configuration



An Actual Configuration

12. Click Close to close the Define Tag Sources dialog box.

Wonderware Training


13. Select your tag source from the Tag Source drop down box.

The Attribute Browser dialog box opens.

14. Select XYLIT and PV from the attribute list. Make sure the Property is <none>.

Note: The Show all attributes box must be checked.

Click OK.

15. Confirm the String Expression is correct and click OK.



16. Click OK on the Properties configuration dialog box.

17. Click on Runtime to verify the value.

18. Repeat these steps for the remaining links assigning the Attribute Property to the respective link.

Or

Click on the background of the Properties window to activate the window.

Press F2 to select all items on the window.

Wonderware Training


Configure the remaining attributes as follows:

obj1.PV.#QString as XYLIT.PV.#QString

obj1.PV.#ReadSts as XYLIT.PV.#ReadSts

obj1.PV.#VString as XYLIT.PV.#VString

obj1.PV.#VString1 as XYLIT.PV.#VString1




obj1.PV.#WriteSts as XYLIT.PV.#WriteSts

obj1.PV.#Locked as XYLIT.PV.#Locked

Select Special / Substitute Tags from the menu bar.



Click the Replace button and replace obj1 with XYLIT.

Click OK.

Wonderware Training


Click OK.

19. Click on Runtime to verify the values.



Wonderware Training


Configure Data Connection between the InTouch Application and Industrial Application Server20. Go to Development.

Open the Security Window within the Application.

Note: If you see ?Config for any of the “live” data connections in WindowViewer, you will need to perform all the tasks in this section of this lab. This indicates that your InTouch Application is not yet configured to communicate with your Galaxy in Application Server.



21. Click on the background of the Security window to activate the window.

Press F2 to select all items on the window.

22. Select Special / Substitute Tags from the menu bar.

23. Click Replace.

You want to replace it with references to your galaxy.

Wonderware Training


24. Enter the Old Text for SecurityTest.

Enter the New Text for the SecurityTest. Remember that XY stands for your initials.

Click OK in the Replace Text dialog.

Click OK in the Substitute Tagnames dialog.

25. Verify that ArchestrA security is selected from the main menu.Special / Security / Select Security Type / ArchestrA.



26. Click Runtime to test your configuration.

You should see the correct Object Name and Security Group.

Test Security in InTouch27. Do not log on with any user name at this point.

Attempt to change Att1_FreeAccess and Att2_Operate from 0 to 1 (or vice versa).

You should be able to change Att1_FreeAccess, but not Att2_Operate based on the security you configured.

Wonderware Training


28. Click Log On.

Logon as operator.

Click OK.

29. Attempt to change all the Attribute values.

Note the behavior of each Attribute and whether or not it will change or require a password.

30. Click Logon.

Logon as Administrator.

31. Attempt to change all the Attribute values.

Note the behavior of each Attribute and whether or not it will change or require a password.

Note: You will receive challenge boxes identical to those you saw earlier. You will not be able to change Configure while the object is OnScan.You will not be able to change the Read Only attribute.



Note the outcome of your testing.

Wonderware Training


Lab 19 – Alarm Connectivity in InTouch

IntroductionThis lab will illustrate how to connect InTouch‘s Alarm ActiveX controls to the Galaxy.


Set up Galaxy connectivity in InTouch for viewing and acknowledging Alarms and Events.



Tasks

Configure the Alarm ActiveX Controls in InTouch1. In InTouch WindowMaker, open the Alarm Test window of the Instructor provided

application.

2. Double-click the Alarm Summary (AlarmViewCtrl) control to open the Properties dialog box for this object.

Wonderware Training


3. Click the Query tab.

4. Enter \Galaxy!<Area> in the Alarm Query field where Galaxy is a fixed key word and Area is the area from which you wish to view alarms.

Click OK to continue.



5. Double-click the Alarm History (AlmDbViewCtrl) control to open the Properties dialog box for this object.

6. Click the Database tab and configure the Server Name as local.

Check the Auto Connect box.

Depending on your configuration, your instructor may need to provide you with a password.

Wonderware Training


7. Click the Test Connection button to verify connectivity to the database.

8. Click the General tab and for the Display Mode select Alarm History.

9. Click OK to close the AlmDbViewCtrl3 Properties dialog box.

10. Go into Runtime and monitor the alarms. Right-click in the upper control and acknowledge alarms.



Wonderware Training


Lab 20 – Tank System Visualization

IntroductionThe client abstraction layer used by InTouch to communicate with the Galaxy exposes several object property dot fields that can be used to build animation links. The Object.Property.Value will map to a data type in InTouch as described in the mapping table in this section (e.g. an object Boolean will map to an InTouch discrete). The Object.Property.#VString will map to a message that represents not only the object value but diagnostic information also. The Object.Property.#EnumOrdinal will map to an InTouch Integer that represents one of many states the property can assume. In this lab you will use some of the property dot fields to build animation links against the App Server objects.

In this lab, we will build a visualization of our Tank System in InTouch and configure it to link to our Tank System in ArchestrA.


Set up properties in InTouch and configure them to link to our ArchestrA application.Create a SmartSymbol from the Tank System created in InTouch.




Tasks

Configure InletValve Properties1. In WindowMaker, create a new window.

2. Name the new window Tank.

3. Draw a Valve

Wonderware Training


4. Double-click on the Valve and select a Fill Color Analog link.



5. For the Expression, enter Galaxy:XYTankSystem_001.XYInletValve.PV.#EnumOrdinal where InletValve is the name of your InletValve object in TankSystem_001 and click OK.

Or

Double click in the Expression area and select XYTankSystem_001.XYInletValve.PV.#EnumOrdinal.

Note: You want to use the Hierarchical name instead of the Tagname so make sure you have clicked on the Hierarchical filter button before you select.

6. Test the Valve in Runtime.

Traveling color(yellow)

Closed color(red)

Open color(green)

Wonderware Training


7. Insert a button on the application window and substitute the string to label it as OPEN.

8. Configure the OPEN button for the InletValve with a Touch Pushbutton action script as follows:

Action Script:

Galaxy:XYTankSystem_001.XYInletValve.Cmd.#EnumOrdinal = 2;



Wonderware Training


9. Configure the OPEN button for the InletValve with a Visibility link as follows:

Visibility Link:

Galaxy:XYTankSystem_001.XYInletValve.PV.#EnumOrdinal == 1

Visible State : On



10. Insert another button on the application window and substitute the string to label it as CLOSE.

11. Configure the CLOSE button for the InletValve with a Touch Pushbutton action script as follows:

Action Script:

Galaxy:XYTankSystem_001.XYInletValve.Cmd.#EnumOrdinal = 1;

Wonderware Training


12. Configure the CLOSE button for the InletValve with a Visibility link as follows:

Visibility Link:

Galaxy:XYTankSystem_001.XYInletValve.PV.#EnumOrdinal == 2

Visible State : On



13. Insert another button on the application window and substitute the string to label it as TRAVELING. This button will not require any configuration.

14. Test the application in Runtime.

15. Place the buttons on top of one another so that the TRAVELING button is on the bottom.

16. Test the application again in Runtime verifying the proper buttons are displayed during the appropriate operation.

Wonderware Training


Create Outlet Valve17. Select all of the Valve and the Buttons, right-click and select Edit/Duplicate from the Menu

to duplicate the cell.

Or

Right-click and select Duplicate.



18. With the duplicate valve and buttons still selected, right-click and select Substitute Tags.

19. Substitute InletValve for OutletValve and click OK.

20. Click OK.

21. Test in Runtime.

Wonderware Training


Create the LevelMeter22. Draw a LevelMeter and configure it as follows:

Percent Fill/Vertical:

Galaxy:XYTankSystem_001.XYLIT.PV

23. Insert a text display and configure it as follows:

Text (“#”, Arial Regular 14):

String Value Display:

Galaxy:DLTankSystem_001.DLLIT.PV.#VString2




Create the Pump25. Draw a Pump and configure it as follows:

Fill Color/Analog Expression:

Galaxy:XYTankSystem_001.XYTransferPump.PV.#EnumOrdinal

Wonderware Training


26. Insert a button on the application window and substitute the string to label it as ON.

27. Configure the ON button for the TransferPump with a Touch Pushbutton action script as follows:

Action Script:

Galaxy:XYTankSystem_001.XYTransferPump.Cmd.#EnumOrdinal = 2;



28. Configure the ON button for the TransferPump with a Visibility link as follows:

Visibility Link:

Galaxy:XYTankSystem_001.XYTransferPump.PV.#EnumOrdinal == 1

Visible State : On

Wonderware Training


29. Insert another button on the application window and substitute the string to label it as OFF.

30. Configure the OFF button for the TransferPump with a Touch Pushbutton action script as follows:

Action Script:

Galaxy:XYTankSystem_001.XYTransferPump.Cmd.#EnumOrdinal = 1;



31. Configure the OFF button for the TransferPump with a Visibility link as follows:

Visibility Link:

Galaxy:XYTankSystem_001.XYTransferPump.PV.#EnumOrdinal == 2

Visible State : On

Wonderware Training


32. Identify the Tank System as follows:

Text (“#”, Arial Bold 14):

String Value Display:

Galaxy:DLTankSystem_001.DLLIT.PV.#VString




Generate Smart Symbol34. Select the entire Tank System, right-click and select CellSymbol/Make Cell.

35. Before we generate a SmartSymbol, we want to replace the Instance references with the Template references.

Right-click on the Tank System cell and select Substitute/Substitute Tags.

Wonderware Training


36. Click Replace.

37. Replace XYTankSystem_001 with $XYTankSystem.

38. Click OK.



39. Right-click on the cell and select SmartSymbol/Generate SmartSymbol.

40. At the InTouch SmartSymbol - Management Mode dialog box highlight the NewSymbol and clock Close.

You will be prompted to convert the current object to the new SmartSymbol.

Wonderware Training


41. Click OK.

42. Double-click on the SmartSymbol to open the SmartSymbols Properties dialog box where you can view the properties associated with your New Symbol. Notice in particular the Template References on the lower right portion of the dialog box.

Click on the ellipses for ArchestrA Instance to activate the Object Browser dialog box and link it to an instance from your Galaxy.

You will get a prompt to configure a Galaxy for browsing.

Click OK.



43. Enter the name of your GR Node Name and the Galaxy Name and click OK.

44. Select XYTankSystem_001 and click OK.

Wonderware Training


Notice the references in the Instance References column have changed.

45. Click OK.




Add and Configure an Additional Smart Symbol47. Click on the SmartSymbol Wizard to add another SmartSymbol.

48. Click on your application window.

The InTouch SmartSymbol - Select Mode dialog box opens.

Highlight your SmartSymbol and click OK.

Wonderware Training


49. Click on the ellipses for ArchestrA Instance to activate the Object Browser dialog box and link it to an instance from your Galaxy.

50. Select XYTankSystem_000 or any other tank system that you might have in your Galaxy and click OK.



Notice the references in the Instance References column have changed.

51. Click OK.


Wonderware Training


Lab 21 – InTouch Tag Connectivity

IntroductionIn AppServer, we can use a Device Integration Object to connect to InTouch, browse the Tagname Dictionary and import those tags into our object in the IDE. This can provide faster connectivity. In this lab we will configure an InTouchProxy Device Integration object to connect to InTouch, browse the Tagname Dictionary and select a certain one to connect to through the IDE. We will then use the Object Viewer to verify connectivity.


Configure the InTouchProxy object to select tagnames from the InTouch Tagname Dictionary.Configure the AnalogDevice to connect to the InTouchProxy object.




Tasks

Configure the IT1 Object1. Check with your instructor as to the location of the application.

Note: It is recommended that there be ONE computer running the Reactor Demo (either on the Instructor computer or one of the Student’s computers) and share the app folder as ReactorDemo.

2. In the IDE, create an instance of the InTouchProxy Device Integration object.

3. Rename the object IT1.

Wonderware Training


4. In the Model View, assign it to your System area.

5. In the Deployment View, assign it to your AppEngine.

6. Double-click on the IT1 object to open its editor.



7. On the General tab, for InTouch runtime node enter the node name where the InTouch Application resides.

8. Click on the ellipses to activate the Browse For Folder dialog box to browse to the correct application.

Wonderware Training


9. Now you can locate the application and click OK.

The application is now inserted into the Item browse path field.

10. Select the Items Configuration tab.



11. Click on the to add an attribute.

12. While being prompted to enter the attribute name in the left most portion of the form, click on

the ellipses in the right most portion of the form.

This will open the Tag Browser dialog box to allow selecting the tag(s) you desire to include as attributes to the IT1 object.

Wonderware Training


13. We now want to select the following tags.$SecondReactLevelReactTempProdLevel

With the first tag highlighted, scroll to the other tags and select them while holding down the Control key. Then click OK.

The tags are now listed as available attributes in the Items Configuration tab of your IT1 object.



14. Save and Close the editor and Check In the object.

15. Right-click on the IT1 object and deploy it.

16. Create a new instance of an AnalogDevice object, rename it XYReactLevel and assign it to Line1.

Double click on the object to open its editor.

17. Select the I/O tab and click on the ellipses for the PV input source.

Wonderware Training


18. Select IT1 as the Tagname. Then select ReactLevel as the Attribute and click OK.

The I/O tab now has IT1.ReactLevel configured as the PV input source.



19. Save and Close the editor. Check in the object. Then Deploy it.

20. Right-click on your XYReactLevel object and select View in Object Viewer.

21. Right-click on PV and add it to the Watch List window. Verify the correct value.

Note: If the value displays as ‘Bad’, verify the connection status of the IT1 device object and reconnect if necessary.

Wonderware Training

Module 11

Multi-Node GalaxiesSection 1 – Redundancy and Redundant DI Objects 11-3

Lab 22 – Redundancy 11-19

Section 2 – Converting to a Multi User Galaxy 11-33

Lab 23 – Convert to Network Environment 11-37

11-2 Module 11 – Multi-Node Galaxies


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 – Redundancy and Redundant DI Objects 11-3

Section 1 – Redundancy and Redundant DI Objects

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

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.

Section ObjectiveThis section will 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



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.

b. In the Application Views panes of the 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.

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

Wonderware Training


their current roles until a failure occurs. If either engine is deployed by itself, it assumes the Active Engine role.

If a failure occurs (computer hardware lost or failed, or a network card failure), the engine with the Standby role assumes the Active role and the engine that was in the Active role is given the role of Standby - Not Ready. When the cause of the failure has been remedied, this engine assumes the Standby - Ready role.

If you edit an engine with redundancy enabled while it is deployed, when it is redeployed the engine which has the Active role will perform this function. It will then update the engine that is in the Standby role.

Dedicated and Shared 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


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.

Control Network

Visualization Nodes

Platform 2

Redundancy Message Channel

Supervisory Network

Platform 1

AE1AE1Bck AE2

AE2 BckPrimary Backup Backup Primary

AutomationObject Server AutomationObject Server



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

Wonderware Training


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.

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.

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


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.

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.

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

Wonderware Training


Errors and Warnings Certain requirements (for instance, the order you configure an object pair for redundancy) are validated by the system infrastructure. If a requirement is not met, you may see error messages that describe the following:

You can configure an AppEngine for redundancy before its associated WinPlatform, but if you do, you will get an error message that the Platform (specifically, the RMC) is not configured yet.If the RMC IP Address parameter is not configured in both hosting WinPlatforms, then the configuration state of both Primary and Backup AppEngines changes to Error, with a message indicating that the host WinPlatform is not configured with the network adapter required for redundant communications. When the RMC IP Address is configured and the WinPlatforms are checked in, the hosted AppEngines are automatically revalidated and the Error state is resolved. If hosted AppEngines are checked out, they are not revalidated.If both Primary and Backup AppEngines are assigned to the same WinPlatform and an attempt is made to deploy both engines, both the Primary and Backup will fail to deploy with a message noting that the Primary and Backup objects must be hosted by different WinPlatforms. Reassign the Backup object to another WinPlatform and deploy it separately.If both the Network Address and RMC IP Address parameters in the WinPlatform's editor address the same network card, you will get a warning message when you save the configuration. These two parameters must address different network cards.

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.



Configuration RedundantDIObjectsConfigure redundancy in data acquisition objects in the 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 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.

0�� "�'�

�*+��%"��3��

4$/

4& �2��#�

��

/�'��&��++&"� �"�'��%��

��!*'! '�

��5.6��

��7� ��7

��%��7��%��7�

-*:�0��

Wonderware Training


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.

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 22 – Redundancy

IntroductionThis lab will describe the steps necessary to configure redundancy between two nodes. It explains the necessary hardware requirements and configuration as well as the required IDE configuration.

Note: Because of the additional hardware and network requirements necessary it is recommended that this lab be done as an Instructor Demonstration only.

ObjectivesConfigure the required hardware installationConfigure network connectionsConfigure the Galaxy for redundancyTest redundancy



Tasks

Dual NICs Configuration

Note: The steps are for Windows 2003 Server, similar configuration can be accomplish on other Windows OS.

Hardware installation1. Shutdown Windows and turn off both computers.

2. Install the second NIC cards on both computers.

3. Plug the network crossover cable on the second NIC on both computers.

4. Turn on both computers.

Configure the Network connectionsFollow these steps on both computers.

5. Open the Control Panel and then double-click Network Connections.

Wonderware Training


6. Right-click Local Area Connection 1 and select Rename from the context menu. Rename the connection ArchestrA. (For identification purposes)



7. Right-click Local Area Connection 2 and select Rename from the context menu. Rename the connection RMC. (For identification purposes)

8. Select the menu option Advanced/Advanced Settings. The Advanced Settings dialog box will pop-up.

9. At the Advanced Settings dialog box, on the Adapters and Bindings tab configure (or verify) the Connections section in the following order:

ArchestrA

RMC

(Remote Access connections)

Wonderware Training


10. Click the OK button to close the dialog box.

11. Right-click ArchestrA and select Properties. The ArchestrA Properties dialog box will pop-up.

12. In the This connection uses the following items section (or Components checked are used by this connection section - depending upon your operating system) select Internet Protocol (TCP/IP) and click the Properties button. The Internet Protocol (TCP/IP) Properties dialog box will pop-up.



13. On the General tab click the Advanced button. The Advanced TCP/IP Settings dialog box will pop-up.

Wonderware Training


14. Select the DNS tab. Verify that the Register this connection's addresses in DNS checkbox is checked.

15. Click OK to return to the Internet Protocol (TCP/IP) Properties dialog box.



16. Click the OK button twice to close all dialog boxes.

17. Right-click RMC and select Properties. The RMC Properties dialog box will pop-up.

18. In the This connection uses the following items section select Internet Protocol (TCP/IP) and click the Properties button. The Internet Protocol (TCP/IP) Properties dialog box will pop-up.

Wonderware Training


19. Select the Use the following IP address option and configure the IP with a mask that is different that the ArchestrA network connection. For example:

20. Click the OK button to close all dialog boxes.



Configure the Galaxy for Redundancy21. If it is not already open, open the ArchestrA IDE, connect to the galaxy and Undeploy the

Galaxy.

The following steps assume that the instance names are as follows. Adjust accordingly:

XYPlatform1: $WinPlatform instance configure for NODE 1.

XYPlatform2: $WinPlatform instance configure for NODE 2.

XYAppEngine: $AppEngine instance hosted by XYPlatform1 in the Deployment View.

Wonderware Training


22. Double-click XYPlatform1 to open the $WinPlatform editor.

On the General tab configure the Redundancy section with the IP address of the RMC network connection for NODE 1 as follows:

Redundancy message channel IP address: 192 . 168 . 0 . 1

Redundancy message channel port: <default_value>

Redundancy primary channel port: <default_value>

23. Save and close the editor. At the Check In dialog, enter RMC configuration in the Comment field. Click OK.

24. Double-click XYPlatform2 to open the $WinPlatform editor.

On the General tab configure the Redundancy section with the IP address of the RMC network connection for NODE 2 as follows:

Redundancy message channel IP address: 192.168.0.2

Redundancy message channel port: <default_value>

Redundancy primary channel port: <default_value>



25. Save and close the editor. At the Check In dialog, enter RMC configuration in the Comment field. Click OK.

26. Assign XYAppEngine to XYPlatform2.

Wonderware Training


27. Double-click XYAppEngine to open the $AppEngine editor.

Select the Redundancy tab and check the Enable redundancy checkbox.

28. Save and close the editor. At the Check In dialog, enter Redundancy configuration in the Comment field. Click OK.

29. Assign XYAppEngine (Backup) to XYPlatform1.



30. Deploy the Galaxy.

Test Redundancy31. View XYAppEngine in the Object Viewer and add the following attributes to the Watch

Window:XYAppEngine.HostXYAppEngine.Redundancy.FailoverOcurredXYAppEngine.Redundancy.ForceFailoverCmdXYAppEngine.Redundancy.IdentityXYAppEngine.Redundancy.PartnerPlatformXYAppEngine.Redundancy.PartnerStatusXYAppEngine.Redundancy.Status

32. Add "live" attributes for any of the Application Objects hosted by XYAppEngine to the Watch Window.

33. Force failure of NODE 2 by unplugging the power cable, shutting down Windows or disconnecting both network cables at the same time.

34. Check Object Viewer on NODE 1 to monitor the attributes and see the failover.

35. Restore NODE 2 and monitor the attributes on NODE 1 to see the behavior.

36. Use XYAppEngine.Redundancy.ForceFailoverCmd to force a failover.

37. Monitor the changes on the attributes in Object Viewer.

Wonderware Training


Section 2 – Converting to a Multi User Galaxy

Standalone to Network ConfigurationEarlier we discussed the standalone configuration we have been using up to this point. At this time we 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 IDE, and a Galaxy Repository. Once we have reconfigured the environment there will be one machine (Node1) that will contain the Bootstrap, the 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 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 will deal with migrating from a standalone configuration to a network configuration. At the conclusion of this section the student will have an understanding of the steps necessary to migrate to a network environment.



The networked environment that we will migrate to is illustrated as follows:

Hardware and Associated Software

Application Server

Galaxy Repository

InTouch Station

Standalone Configuration

Present on each machine

BootstrapIDE


Contains

Contains

Contains

PLCBootstrap

IDEInTouch 9.0

Galaxy Repository (GR)

BootstrapIDE


BootstrapIDE


BootstrapIDE


BootstrapGalaxy Repository (GR)

BootstrapInTouch 9.0

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 will be a need for only one PLC so the one residing on the resulting Galaxy Repository node will be the one that is most likely the one desired for the network. Therefore, that is the on and only one that will be exported in preparation for the network environment.

The node that will contain 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.

PLCBootstrap

IDEInTouch 9.0

BootstrapIDE

InTouch 9.0

BootstrapIDE

InTouch 9.0

BootstrapIDE


Application Object Server ,Galaxy Repository, and

InTouch

Industrial Application Server and InTouch

Galaxy 1 Node4G1N4

Galaxy 1 Node3G1N3

Galaxy 1 Node2G1N2

Galaxy 1 Node1G1N1



Wonderware Training


Lab 23 – Convert to Network Environment

IntroductionThis lab will describe the steps necessary to convert to a Networked Configuration. In the networked environment a common Galaxy Repository will be shared between a set of PCs allowing multiple users to simultaneously work on the same application.

ObjectivesMigrate to a network environmentUse exporting and importing to take objects that were created on one node and migrate them to a single nodeUnderstand how to deploy and undeploy objects on a galaxy located on a different node

RequirementsGalaxy with access to IDE and I/O Servers.

Note: Remember to ALWAYS preface the object name with your FIRST and LAST initial.(e.g., if the user is John Burns, Valve would be JBValve) This will eliminate problems when we deploy our objects in a common galaxy.



Tasks

Preparing to Convert to Networked EnvironmentBefore we can convert to the networked configuration there are certain steps that must be initially undertaken.

1. Your Instructor will assign a specific grouping of multi-user galaxies (Members) and assign one student to host their galaxy (Galaxy Master).

2. On each node, export your TankSystem Template AND its children.

Wonderware Training


3. On the node that will contain the Galaxy Repository, THE GALAXY MASTER ONLY is to export the InControl instance.

4. All nodes are then to Undeploy their respective Galaxies.

Wonderware Training


Converting to the Networked Environment

Note: The Node that will contain the Galaxy Repository (the Galaxy Master) is to do these initial steps alone.

All other nodes are NOT to create any Galaxies at this time. It is imperative that the node that will contain the Galaxy Repository be the FIRST node to create a Galaxy, create a Platform and deploy that Platform.

STEPS 5 THROUGH 11 ARE FOR THE GALAXY MASTERS ONLY!5. On the node that will contain the Galaxy Repository (the Galaxy Master), select File/Change

Galaxy to create and change to a new Galaxy.



6. Create a Galaxy called Galaxy1. This will ensure that for each network, Galaxy1 will be the Galaxy that resides on the same node as the Galaxy Repository.

Wonderware Training


7. On the Galaxy1 node that will contain the Galaxy Repository create a Platform.

8. Deploy the Platform.

9. On the Galaxy1 node that will contain the Galaxy Repository, import the Tank Template and the InControl object.



10. The Galaxy Master is to configure Security with Galaxy Authentication and user accounts for each member of the team. Each user will belong to the Administrator role.

Wonderware Training


11. On the Galaxy1 node that will contain the Galaxy Repository, the Galaxy Master is to deploy the Engine, Area and the InControl object.



AFTER THE GALAXY MASTER HAS COMPLETED STEPS 5 THROUGH 11, ALL NON GALAXY MASTERS CONTINUE AT THIS POINT!12. All the Non Galaxy Master nodes are now to login and connect to the Galaxy1 node

containing the Galaxy Repository using the Security login created by the Galaxy Master.

13. All the Non Galaxy Master nodes are to create a Platform. Node 2 creates Platform2, Node 3 creates Platform3, Node 4 creates Platform4

14. All the Non Galaxy Master nodes are to create an Engine and an Area.

15. All the Galaxy nodes are to import their Tank.

16. All the Non Galaxy Master nodes are to do a Cascade Deploy to the Tank to their Platform.

17. Use the Object Viewer to verify that communication is occurring with the InControl object on the Galaxy Repository.

Wonderware Training

Appendix A

ArchestrA Licensing

A-2 Appendix A – ArchestrA Licensing

LicensingThe Industrial Application Server utilizes the FactorySuite A2 licensing. This appendix is designed to provide information about where the detailed license requirements for a FactorySuite A2 system reside.

Note: For additional deployment and pricing information, please see the Wonderware FactorySuite A2 Deployment Guide and the Wonderware Global Price List which are available from Wonderware Sales.

In addition to the Application Server, the following Wonderware products may also be present:FactorySuite Development 8.0 or higherInTouch View 9.0 SP2 or higherInTouch 9.0 SP 2 or higherInSQL Server 8.0 SP1 or higherInTouch for Terminal Services 8.0 or higherSuiteVoyager 2.0 or higherActiveFactory 8.0 or higherand others.

Note that the use of the term “License” in this document refers to the legal rights a customer has to use Wonderware Software.

There is also a local License Manager and associated .LIC file which is loaded with specific Wonderware Software packages and monitors the use of that specific package. Please refer to the appropriate product documentation to learn more about the Wonderware License Management System.

The detailed licensing information is located on Team.Wonderware.com in the following location.

Wonderware Training

Appendix A – ArchestrA Licensing A-3

1. Open your browser and go to Team.Wonderware.com.

2. Select Product Info/Industrial Application Server.



3. Select Proposal Guides, Lockout Specs & Sales Tools.

4. Select Licensing Guide for the Industrial Application Server v2.0.

Wonderware Training

Appendix A – ArchestrA Licensing A-5

5. Select the Licensing Industrial Application Server file near the bottom of the screen.



6. At the File Download dialog box select either Open or Save depending upon your needs.

Wonderware Training

Appendix B

FactorySuite Support Tools

B-2 Appendix B – FactorySuite Support Tools

OverviewThis Appendix explains Wonderware® Support programs, as well as detailed information concerning registration, support, and the Expert Knowledge Base.

Note: The Web pages shown and described in the following materials are subject to change without prior notice.

Wonderware’s Website is located at: www.wonderware.com.

To access the Support page, click the Support link.

Wonderware Training

Appendix B – FactorySuite Support Tools B-3

Next, select FactorySuite eSupport.

You may now either Login or Register.

RegistrationTo access the different areas and services available, you must first register yourself by selecting the Register link on the main page. You must fill out all the requested items of information.

The new User will be prompted to enter basic registration information. Once the registration information has been completed, the Technical Support Administrator will issue you a Userid and Password. If you are already registered, click Login.



A Userid and Password are not required if you simply want to enter the Wonderware corporate web site.

Levels of AccessWhen the Technical Support Administrator processes your registration, your Userid and Password is based on one of the following levels of access: Basic Support, Comprehensive or Enterprise customers, Wonderware Distributor, or Certified Support Provider.

System Integrators and OEM sites will be granted access if they have a valid Comprehensive Support or Enterprise support contract.

The Password Verification dialog box appears:

Wonderware Training


Users, Providers, and SubscribersBasic Support Users: Basic Support users who register on the Technical Support web page will be able to access the following areas and services by selecting www.wonderware.com/support/mmi/esupport.

On the Support page, under the Self Support tab, you will find a variety of information including the Expert Knowledge Base, Documentation, FAQs, Tech Alerts, Tech Articles, Tech Notes, and Tech Support Forums.

More Support links are contained within the Support page. The links are available according to your access level status.



Comprehensive Support Subscribers and Enterprise Support CustomersComprehensive Support subscribers and Enterprise Customers who register on the Technical Support web page can access all of the Basic Support services and additional exclusive areas on the web site.

At www.wonderware.com/support/mmi click Contact Us for phone numbers and E-mail addresses for contacting Tech Support. For the latest contact information, please view the KBCD, issued quarterly.

Enterprise Support: Wonderware Technical Support offers Enterprise Support for those customers who have exhibited a high level of commitment to Wonderware products. It extends beyond the full service Comprehensive Support services that are available.

Some of the advantages are:A designated Enterprise Support Program account manager.Account Manager site visits.Bi-weekly status reports submitted to Enterprise customers.

Wonderware Distributor Support: Wonderware has over 150 distributors and sales offices located throughout the world. Each is available to assist you with your needs.

To locate the nearest Wonderware distributor, go to: www.wonderware.com/Aboutus/Sales.

Solution Providers: Select the Solution Providers link from the Support page.

Information on this page includes innovative enhancements for WW products. These include vertical market wizards, ActiveX objects, and I/O Servers.

Wonderware System Integrator: Select the Solution Providers/Wonderware SIs link from the Support page.

From this page you can also locate a Wonderware Registered or Certified SI. Qualified System Integrators and developers are accessed from this location. They have the technical ability to assist you with your needs.Certified Support Provider: Most of our worldwide Wonderware distributors are Wonderware Certified Support Providers (CSPs). Our distributors provide valuable application and technical support, as well as FactorySuite product training.

Wonderware CSPs undergo a rigorous certification process – including passing lengthy written examinations in each FactorySuite component. This ensures you receive a consistent, high-quality level of support no matter where in the world you are located.

If you contact Wonderware Technical Support in Lake Forest, CA either by telephone or by e-mail, the Technical Support Administrator will forward your call or e-mail to a Technical Support engineer at the nearest Certified Support Provider site. (Callers from outside the U.S. and Canada may be given the telephone number of the nearest Certified Support Provider).

Our Certified Support Providers are trained to answer even the most difficult questions that you may have about the FactorySuite. For issues that require further research, our Certified Support Providers may work with Wonderware Technical Support to ensure that you are given a complete solution to your issue.

For further questions on our Certified Support Provider program, contact either your local Wonderware distributor or Wonderware Technical Support in Lake Forest, CA.

At www.wonderware.com/support/mmi click Contact Us for all up-to-date phone numbers and E-mail addresses for contacting Tech Support.

Wonderware Training

http://www.wonderware.com/support/mmi

http://www.wonderware.com/support/mmi


Expert Knowledge BaseNavigate to this page by selecting the Expert Knowledge Base link on the Support page.

Information included on this page includes the 10 Most Frequently Asked Questions, expert search capabilities and troubleshooting information for all of our products:

Team WonderwareSupport information is also located on: team.wonderware.com.



– Intentionally left blank –– Intentionally left blank –

Wonderware Training

Appendix C

Industrial Application Server Glossary

C-2 Appendix C – Industrial Application Server Glossary

Application

A collection of objects within a Galaxy Repository that performs an automation task. Synonymous with Galaxy. There may be one or more applications within a Galaxy Repository.

Application Engine (AppEngine) A scan-based engine that hosts and executes the runtime logic contained within AutomationObjects.

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 ViewsThe Applications Views pane displays the object-related contents of the Galaxy in three different ways: Model, Deployment, and Derivation Views. The Model View is the default display when the 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.

Wonderware Training

Appendix C – Industrial Application Server Glossary C-3

Automation Object Server (AOS)A computer that hosts one or more application engines and associated automation objects. An Industrial 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 persisting 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.

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 The notion of 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. 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 ArchestrA runtime. This action involves installing all the necessary software and instantiating the object on the target platform with the objects default attribute data from Galaxy Repository.

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

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

Wonderware Training


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.

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

ImportThe act of reading a .aaPKG File and using it to create AutomationObject instances and Templates in the Galaxy Repository.

Industrial Application ServerRefers to the FactorySuite A2 Supervisory Control Platform, commonly known as the Application Server. The Industrial 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 Industrial 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 Industrial 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 (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 FactorySuite A2 Development License.

InTouch View InTouch View Clients are InTouch Runtime Version 8.0 clients that solely use of the Industrial Application Server for its data source. In addition, standard InTouch v8.0 runtimes can leverage the Industrial 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 Industrial 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 Industrial 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

Wonderware Training


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

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 Industrial Application Server or InTouch® HMI. For example, there is a Proxy Object that enables the Industrial Application Server to access an OPC server.

Redundancy

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

SecurityIndustrial Application Server security is applied to IDE, 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

Wonderware Training


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 systemwide message exchange component, a set of basic services, the operating system, and the physical hardware. This object hosts all AppEngines.



Wonderware Training

Instructor NotesRevision CJune 2005

Part Number 05-2056

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

Industrial Application Server

2.0 Course

2

Course Developer E-mail TelephoneDana Lundy [email protected] 949-639-8639

Wonderware Training

mailto:[email protected]

3

Note: Important! The only difference in Rev B and Rev C is Appendix A. The Licensing information was revised.

Instructor Preparation and Class Setup

System Requirements for Industrial Application Server/Galaxy RepositoryTo run the Application Server, the following hardware and software are recommended.

Software Requirements

FactorySuite A² Development seat – IDE with Galaxy Repository (Project Database)Microsoft® SQL Server 2000 Service Pack 3a andMicrosoft® .NET Framework 1.1 andMicrosoft® Internet Explorer 6.0 SP1 andMicrosoft® Windows® Server 2003 or Microsoft® Windows® 2000 Server with Service Pack 4 or Microsoft® Windows® 2000 Advanced Server with Service Pack 4

Important! The Microsoft SQL Server login for BUILTIN\Administrators group must be present and enabled.

FactorySuite A² Development seat – IDE with no Galaxy Repository (Project Database)Microsoft® .NET Framework 1.1 andMicrosoft® Internet Explorer 6.0 SP1 andMicrosoft® Windows® Server 2003 or Microsoft® Windows® 2000 Professional with Service Pack 4 or Microsoft® Windows® 2000 Server with Service Pack 4 or Microsoft® Windows® 2000 Advanced Server with Service Pack 4 or Microsoft® Windows® XP Professional with Service Pack 2

FactorySuite A² Application Server RuntimeMicrosoft® .NET Framework 1.1 andMicrosoft® Internet Explorer 6.0 SP1 andMicrosoft® Windows® Server 2003 orMicrosoft® Windows® 2000 Professional with Service Pack 4 orMicrosoft® Windows® 2000 Server with Service Pack 4 orMicrosoft® Windows® 2000 Advanced Server with Service Pack 4 orMicrosoft® Windows® XP Professional with Service Pack 2

Hardware RequirementsPC with 2 gigahertz (GHz) or higher processor clock speed1 gigabyte (GB) of RAM or higher (512 MB minimum supported; may limit performance and some features)8 gigabytes (GB) of available hard disk spaceSuper VGA (1024 × 768) or higher-resolution video adapter and monitor


4

CD-ROM or DVD driveKeyboard and Microsoft Mouse or compatible pointing device

Note:Support for Windows Server 2003Industrial Application Server 2.0 leverages the Microsoft operating system, Windows Server 2003. Version 2.0 of Industrial Application Server has been thoroughly tested on this new OS enabling the user to immediately take advantage of its functionality.

Additional Application Server Node Software RequirementsWinZipIndustrial Application Server 2.0InTouch 9.0SP 2 w/ IAS Training Application for InTouchActive Factory Various documents and objects included in the training package

Historian Node Software RequirementsWindows 2000 Server w/SP3MS SQL Server 2000 w/SP2InSQL 8.0 w/SP1

Control Simulation Node Software RequirementsWindows NT or 2000InControl 7.1 w/SP1IAS Training Application for InControl

Setup NotesThe software must be installed on networked machinesDHCP is recommendedEach student machine is a full App Server node (FactorySuite A² Development seat – IDE with Galaxy Repository )There is only one Historian Node required on the networkThe App Server node and the Historian node software must be installed with the same Admin accountIf the OPC proxy DI object is used, DCOMCNFG must be used to set up InControl's server and OPCEnum on both App Server node and Control Simulation node

New and Enhanced Features (see separate ‘New Features’ PowerPoint presentation)Multiple features and powerful functionality have been added to Industrial Application server 2.0.

The main items incorporated or enhanced include:

Wonderware Training

5

High AvailabilityPerformanceUsabilityConnectivityScalability

High AvailabilityMigration

The process to upgrade the software and migrate the configuration database is simple and transparent to the user. It provides minimal downtime when updating current systems to the new version as it basically consists of two steps:

1. A Software Upgrade From IAS 1.5 [+Patch01] to 2.0

2. A Seamless Galaxy Migration

"From .cab File (Galaxy Backup)

Note: Restore First, then Migrate

"From .aaPKG (Templates/Instances)

Note: Select "Migrate" when Importing

Redundancy

Two key features of the system provide built in Redundancy:Application Execution - Redundant AppEnginesIO Data source - Redundant DI Object

AppEngine Redundancy:

A pair of AppEngines can be configured to provide high availability to the system. The pair consists of an Active Engine which executes the application and a Standby Engine which takes control of the application when the Active one fails. Configuration requirements are minimal as the system automatically creates the redundant pair and in runtime it continually synchronizes data, alarms and history between the pair.

Redundant DI Objects:

At the IO data level, a Redundant DI object can be configured to have a pair of IO data sources where one is Active and the other one is in standby mode. If the Active data source fails the Redundant DI Objects uses the Standby data source to communicate with devices in the field.

Improved Store and Forward functionality

Both IndustrialSQL Server 8.0 SP3 and Industrial Application Server 2.0 incorporate major enhancements to the performance of the Store and forward capability. This improvement has important impact on SCADA systems with limited bandwidth and intermittent networks.


6

ConnectivityIndustrial Application Server as an OPC Server

The FactorySuite Gateway (FS Gateway) provides support for Industrial Application Server 2.0. Using FS Gateway a Galaxy becomes an OPC server for an OPC Client that requires access to Galaxy data.

Additionally FS Gateway allows legacy IO servers to provide data to the Galaxy.

OPC item browsing

A key feature of this release is the ability provided by the OPC Client Object to browse OPC Servers. The OPC Item Browser allows users to browse the namespace of an OPC Server and choose items to add to a scan group, block read group, or block write group as long as the OPC server supports browsing.

Also it is now possible to Import/Export the items list in the DDE\SuiteLink client as well as in the OPC Client object.

PerformanceSupport for slow and intermittent networks

Important enhancements have been incorporated in Industrial Application Server 2.0 to support networks with poor performance caused by low bandwidth and intermittent availability.

MX protocol

Microsoft Message Queue has been replaced by Sockets technology in the protocol to optimize the data transfer over the network.

User authentication

The mechanism used to authenticate users/groups in a Domain has been enhanced to allow for a more robust system performance.

Store and Forward capabilities

The Store and Forward functionality has been optimized to improve data storage to the historian.

CPU and Memory utilization

Improvements in the script evaluation mechanism has contributed to the optimization of CPU and Memory utilization.

UsabilityFull support for InTouch SmartSymbols

Industrial Application Server 2.0 seamlessly integrates to InTouch SmartSymbols. It allows browsing the Template toolbox to simplify linking attributes between both applications. New instances of an existing Template can be automatically created from the SmartSymbol making them ready for deployment in the IDE.

Wonderware Training

7

Improvements to Multi-user environment

Various enhancements have been incorporated into the Multi user capability to simplify concurrent configuration of a Galaxy.

Diagnostics and maintenance

Many new attributes associated with Redundant AppEngines and Redundant DI Objects are available to monitor the system status and diagnose problems.

Also, more comprehensive information for maintenance purposes is available in this release. The SMC provides detailed information on operations such as Database restore and Database Migration, including initializing and completion time.

Documentation

New documents and resources have been created and the existing ones have been updated and improved to assist users defining and configuring FactorySuite A2 systems.

Getting Started with Industrial Application Server

Presents an overview of Industrial Application Server that walks you through the steps needed to create a simple working application for a typical plant production facility. This is available as a web-based application at www.wonderware.com

IDE User guide:

On line help documentation is provided with updated information on new functionality, features and enhancements. This is available on the Wonderware Tech Support Web site and in the Industrial Application Server Product CD.

FactorySuite A2 Deployment Guide

New and updated best practices and recommendations on configuring and implementing a FactorySuite A2 system are documented in the latest version of the Deployment Guide.

This is a key resource on providing useful information to users that need to implement SCADA systems and redundant configurations. This is available on the Wonderware Technical Support Web Site, under Industrial Application Server Documentation.

LicensingGalaxy IO count license

New IO count license sizes are available to implement smaller and larger systems. The IO count scale is available in the following increments: 250, 2500, 4500, 25K, 50K, 100K, 200K, 500K and 1 Million IO. Contact your distributor for ordering information


8

FactorySuite Development license

The FS Development license has also been scaled down to support the implementation of smaller systems. For the different sizes, please consult your distributor.

Instructor Note References

Page 1-3Module 1 – IntroductionSection 1 – Course IntroductionCourse IntroductionIntroduce yourself.

Have students introduce themselves: CompanyCurrent PositionLevel of expertise with Wonderware productsExpectations of the course

Give course logistics:Class timesBreaks & lunchPhones & restroomsContacting Wonderware

Go through materials in Training Kits.

Instructor NoteThere are a couple of Script files provided with the Instructor Info for this course. After a discussion of scripting, you may want to provide these Script files to the students to allow them to enter them into their labs. These scripts are for Lab 10 - Object Reuse and for Lab 11 - Averager.

Module 2There are no labs in this Module, however, it is of key importance in that it stresses the need for the creation of the application to be driven by first modeling the Plant. This helps organize the Areas with the respective objects that represent the Plant components for the particular Areas of the factory floor. It also prepares the developer for establishing an effective naming convention which can be vital to future development.

Module 3Lab 1 - Creating a Galaxy - This lab walks the student through the actual steps of how to create a galaxy. Ensure they use the initials of their first and last name to preface the name of their galaxy.

Wonderware Training

9

Lab 2 - Facility Model - This lab is to reinforce the concept of the model view and the importance of approaching an integration job through the model building paradigm. We are using instances here because the template concepts have not been introduced yet. When templates have been covered, the instructor should revisit this lab to discuss the importance of deriving area instances from derived templates rather than base templates. Area containment is also introduced.

Lab 3 - Create and Deploy a Platform - This lab is to introduce some of the Platform's functionality as well as the functionality of the Object Viewer. Prior to the lab, the instructor should discuss message exchange and the platform's use of it.

Lab 4 - Create and Deploy and Engine - This lab is to introduce some of the Engine's functionality. Some important concepts to discuss before this lab include scan period, checkpointing and the scheduler. This is a good time to go back to the platform object and discuss the engine and scheduler tabs on the platform's editor. The difference between Model View and Deployment View can be explored here.

Module 4Lab 5 - Device Integration Object - This lab is to introduce some of the functionality of the DDESuiteLinkProxy object. The ConectionStatus and Reconnect properties should be discussed. This is a good time to further explore the Object Viewer by describing the Security and Category columns. A description of the control layer and InControl should precede the lab. The Object Viewer's Attribute Reference input box can be used to type in a reference to one of the simulated items in the InControl app (InControl.Tagname.XXX)

Note: There is a csv file provided for use with this lab.

Lab 6 - Analog Devices - This lab is to introduce the Analog device. The student will see for the first time Appserver's relationship to real IO. The PV.InputSource can not be browsed to at this point because we have not made any attribute references. It is best to introduce the attribute reference after the lab.

Lab 7 - DiscreteDevices - Valve Instance - In this lab, the Discrete Device is introduced. This is a complex device and should be discussed thoroughly. It is necessary to further explore the control logic and discuss the OLS, CLS and cmdOpen bits in the InControl app before the lab.

Module 5Lab 8 - Modeling Complex Objects - Templates are introduced in this lab. It's important that the student thoroughly understand the IO requirements and the tank structure. The student's initials must be must be placed on the $Valve template. When troubleshooting, the first place to look is the ReadStatus and WriteStatus properties in Object Viewer.


10

Lab 9 - Change Control and Propagation - The Locked In Parent functionality should be discussed here as a way to propagate changes to objects instantiated by templates. Explain unlocking through multiple levels of templates.

Lab 10 - Object Reuse - This lab is intended to show the power of templates. A discussion on how standards are imposed by good template development is needed. The use of the keywords Me, MyContainer, MyEngine … should precede the lab.

Lab 11 -Averager - This lab illustrates the ability to extend the object's attributes through scripting by creating an Averager object that calculates the PV average.

Lab 12 - Extensions - This lab uses an extension with an advanced technique. A discussion of the MXReference data type and reference binding is needed. It will be necessary to demonstrate a simpler use of extensions before the lab.

Module 6Lab 13 - Alarming - The importance of this lab is to show how alarming is the responsibility of the object which is in alarm and how areas are used to filter alarms. It should be stressed that the Platform is not raising the alarm; rather it is the conduit through which the object alarms are provided. A discussion of alarm providers and consumers should precede the lab. Explain how multiple Platforms and Areas affect the network traffic.

Lab 14 - Historization - It is important in this lab, as in the alarm lab, to stress that it is the object that decides when to historize. The engine is used to pass the value to the historian and to perform the store and forward functionality.

Note: The instructor will need a separate machine to install InSQL. This machine should be on a projector so the instructor can show changes made to InSQL as the historized object gets deployed (or use a remote InSQL Console). Note that the students will not see any data in their trend if their AppServer is not time-synchronized with the InSQL machine. A description of InSQL and MDAS should precede the lab.

Module 7Lab 15 - Application Server Security Settings - The importance of this lab is to show how the various User Groups and Roles can be used to configure a given application for specific security by User.

Lab 16 - Authentication - This lab extends the discussion of security to include OS Group based security.

Wonderware Training

11

Module 8Lab 17 - Exporting/Importing CSV Files - This lab will illustrate how objects can be exported and modified externally. Subsequently they can be imported so as to create additional instances of the objects.

Lab 18 - SMC Operation - This lab will illustrate the functions associated with the System Management Console. We will look at how to start and stop Platforms and Engines from the Platform Manager, how to work with the Log Viewer, the DAServer Manager and the Galaxy Database Manager.

Module 9Lab 19 - FactorySuite Gateway - This is a new lab to illustrate the new features associated with the FactorySuite Gateway product. This lab will identify the steps needed to configure two (2) machines - the Instructor machine and the Student machine for FactorySuite Gateway.

Note: FactorySuite Gateway 1.0 must be previously installed on the Instructor's computer.

Module 10Lab 20 - Properties Visualization - When using InTouch as the view component for Industrial AppServer the InTouch application must reside on a node with a Bootstrap and Platform object deployed. In this configuration InTouch will use the message exchange functionality of the Platform, enabling Galaxy namespace browsing and increased data communication functionality. In this lab the students will configure a remote tag source to point to the galaxy, and map the ApplicationObject properties to InTouch tags for viewing.

Lab 21 - Alarm Connectivity in InTouch - This lab will illustrate how to connect the Galaxy to Alarm Summary and Alarm Event/Summary in InTouch. Then how to acknowledge those alarms in Runtime.

Lab 22 - Tank System Visualization - The client abstraction layer used by InTouch to communicate with the Galaxy exposes several object property dot fields that can be used to build animation links. The Object.Property.Value will map to a data type in InTouch as described in the mapping table in this section (e.g. an object Boolean will map to an InTouch discrete). The Object.Property.#VString will map to a message that represents not only the object value but diagnostic information also. The Object.Property.#EnumOrdinal will map to an InTouch Integer that represents one of many states the property can assume. In this lab you will use some of the property dot fields to build animation links against the App Server objects.


12

This lab also introduces the students to how to create a SmartSymbol in InTouch and configure it to reference the objects in their Galaxy.

Lab 23 - InTouch Tag Connectivity - In AppServer, we can use a Device Integration Object to connect to InTouch, browse the Tagname Dictionary and import those tags into our object in the IDE. This can provide faster connectivity. In this lab we will configure an InTouchProxy Device Integration object to connect to InTouch, browse the Tagname Dictionary and select a certain one to connect to through the IDE. We will then use the Object Viewer to verify connectivity.

Module 11Lab 24 - Redundancy - This is a new lab which describes the steps necessary to configure redundancy between two nodes. It explains the necessary hardware requirements and configuration as well as the required IDE configuration.

Lab 25 - Convert to Network Environment - This lab will describe the steps necessary to convert to a Networked Configuration. In the networked environment a common Galaxy Repository will be shared between a set of PCs allowing multiple users to simultaneously work on the same application.

Wonderware Training

Ias 2 0 Revc Gold Manual

Documents

Transcript of Ias 2 0 Revc Gold Manual