Professional Documents
Culture Documents
Ias 2 0 Revc Gold Manual
Ias 2 0 Revc Gold Manual
T R A I N I N G
Training Manual
Revision C
June 2005
Part Number 05-2056
Industrial
Application Server
2.0 Course
Table of Contents
Table of Contents
Module 1
Introduction .................................................................................1-1
Section 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
Module 2
Module 3
Module 4
Modeling Equipment...................................................................4-1
Section 1 Application Objects ......................................................................... 4-3
Lab 5 DeviceIntegration Object ................................................................ 4-7
Lab 6 Analog Devices ............................................................................ 4-19
Lab 7 DiscreteDevices - Valve Instance................................................. 4-29
Module 5
Module 6
Module 7
Module 8
Galaxy Maintenance....................................................................8-1
iii
iv
Module 9
Module 10
Visualization.............................................................................. 10-1
Section 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
Module 11
Wonderware Training
Module 1
Introduction
Section 1 Course Introduction
1-3
Section 2 ArchestrA
1-13
1-21
1-23
1-35
1-2
Module 1 Introduction
Module Objective
z
Wonderware Training
Course Overview
FactorySuite 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 Introduction
Module 2 Application Planning and the Plant Model
Module 3 The Galaxy
Module 4 Modeling Equipment
Module 5 Complex Object Modeling Extending the Objects
Module 6 Alarming and History
Module 7 Securing the Galaxy
Module 8 Galaxy Maintenance
Module 9 DAServers and DI Objects
Module 10 Visualization
Module 11 Multi Node Galaxies
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.
Prerequisites
It is expected that prior to taking this course the student will have a basic knowledge of InTouch.
1-3
1-4
Module 1 Introduction
Agenda
Module 1 Introduction
Introduction
z
What is ArchestrA?
Bootstrap
Platform
LMX, NMX
Toolkits
Engine
Objects
DI
System(Area)
Application
Analog, Discrete
Change control/propagation
When to use?
Number of I/O
Architecture
Installation / Licensing
z
Hardware Recommendations
Software Recommendations
Licensing Scheme
FS Compatibility
naming conventions
Wonderware Training
The difference between Object Oriented development process and Tag Based
development process
Types of objects
Selecting a GR Node
What is a Galaxy?
Selecting a Galaxy
Deleting a Galaxy
Creating a Galaxy
Tool bars
Views
Import/Export
Configure Security
Change User
Change Galaxy
Attributes
Errors/Warnings
Cross Reference
Change Log
Facility Modeling
z
Alarms
Events
Devices as Instances
1-5
1-6
Module 1 Introduction
Objects and Object Instances
z
Platform Properties
Object Viewer
Engine Properties
Area Properties
Templates
Extensions
Input Reference
Output Reference
Alarm
Historize
Propagate on check in
Wonderware Training
Me
My Host
My Container
My Area
Contained Names
Script Types
Dim Types
Aliases
Property Browser
Function Browser
Type Browser
Import/Export
What is an Alarm/Event?
Lab 13 Alarming
Network Account Utility
Historization
z
Engines Historize
InSQL MDAS
1-7
1-8
Module 1 Introduction
Lab 14 Historization
None
Galaxy
OS User
OS Group
As an aaPackage (Object)
Configuration
Component Architecture
DAServer Characteristics
DI Objects
z
DI Network Objects
Wonderware Training
DI Device Objects
FactorySuite Gateway
z
Module 10 Visualization
Visualization
z
InTouch Integration
Tag Browser
1-9
1-10
Module 1 Introduction
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:
z
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 control
InTouch for Terminal Services software for remote hosting of InTouch applications
Data 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 consistency
ActiveFactory 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 Server
SCADAlarm 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.
Object Development Toolkit: allows 3rd parties to create new domain objects
customized for specific needs
The ArchestrA infrastructure, or Framework, supports core services that are required by most of
the different types of supervisory control and manufacturing information systems mentioned
above. These core services include the following:
z
Version management
Internationalization
1-11
1-12
Module 1 Introduction
z
Runtime Components: which include PCs with core infrastructure (called Platforms), key
software applications (Engines) and objects (Framework Objects) that expose framework
related functionality. These components are centrally deployed and administered.
Wonderware Training
Section 2 ArchestrA
Section 2 ArchestrA
Section Objectives
z
Introduction
ArchestrA is a comprehensive plant automation and information architecture designed from the
outset to extend the life of legacy systems by leveraging the latest software technologies.
Offerings built upon this architecture empower decision-makers to achieve their business goals,
without abandoning prior investments in automation systems, production processes or intellectual
property.
ArchestrA's complete approach to industrial architecture significantly reduces a plant's total cost of
ownership through easy installation, operation, modification, maintenance and replication of
automation applications.
In the ArchestrA environment, software applications can be rapidly assembled rather than
programmed. New applications also can be created simply through the reassembly of existing
applications.
The ArchestrA vision is to provide a unified and robust architecture that is the basis for
collaborative production systems in support of industrial enterprises. Its open-development
platform and tools uniquely enable Invensys and third parties such as OEMs, machine builders
and system integrators to build domain knowledge and add significant value to the solutions they
provide. End-users and suppliers will benefit from ArchestrA's unified platform, which enables the
instant integration of application information.
ArchestrA is the comprehensive industrial automation and information architecture that
orchestrates a new way to run or expand older plants more efficiently, and an optimal way to build
new plants.
1-13
1-14
Module 1 Introduction
Unfortunately, even today, in most plants these systems operate independently. This hinders a
plant managers ability to synchronize and control production and business processes in a realtime environment. In other words, the majority of manufacturers have not successfully integrated
the functionalities of 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 everincreasing 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 managers 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 plants 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
Section 2 ArchestrA
Manufacturing Goals
For approximately a decade, manufacturers have been revising business practices, organization
charts, and systems infrastructures to become more market-driven and customer-centric. Their
overall objectives have been straightforward and consistent:
z
Become more responsive to market shifts and the increased competition brought on by
globalization
Utilize existing assets more efficiently to increase production, without the need to expand
the plant or build new capacity
Ensure the greatest possible return on assets, and improve profitability, in the face of
continuing manpower reductions
To achieve these goals, managers know they can no longer simply "invest in technology" and
expect improvements to come about automatically. In fact, millions of dollars have already been
invested with only marginal returns. However, management cannot afford to stand still, because
there are significant rewards to be reaped by those who develop improved responsiveness,
greater agility, and a higher return on assets.
Compounding the problem, many of yesterdays automation and information systems are
beginning to show their age, failing to offer the agility or rapid response that todays producers
require. Acting as a massive anchor, they actually impede the organizations forward progress as
they increasingly require greater amounts of maintenance and the corresponding expansion of
infrastructure support. But the original investment in these systems was so extensive and so
visible to owners and investors that it is understandably difficult to broach the subject of
"bulldozing" and starting over with the latest generation of technology. Further, it means not only
eliminating extensive hardware infrastructure, but also destroying an asset that is even more
valuable the intellectual capital unique to the manufacturing mission.
Synchronization of Systems
Todays 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. Todays 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.
1-15
1-16
Module 1 Introduction
The challenge has been to develop an architectural infrastructure that optimizes quality, customer
satisfaction, and efficiency of operation, while facilitating quick response and easy reengineering.
And to identify and deploy a plant information superstructure that embraces existing systems while
providing expansion capabilities for the long term.
Such an architectural infrastructure is available through ArchestrA. This allows manufacturers to:
z
Move ahead into the future, confident of shorter project execution times, reduced total cost
of ownership, and a proven, long-term strategy that will remain in a leadership position for
the life of the plant.
ArchestrA Architecture
ArchestrA, developed by Invensys, is a software infrastructure designed to unify combinations of
Invensys, third-party, and customer internal applications, both current and emerging, into a
synchronized, plant-level application model, and to foster their ongoing adaptation and
improvement. It comprises a unique combination of new toolsets and new applications
infrastructure services, allowing the rapid generation of new applications, products, and services.
Because it enables easy upgrades via integration of existing systems with these new technologies,
it offers manufacturers the promise of extending the lifecycle of an entire plants 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 companys
process. Incorporating ArchestrA will considerably reduce the cost and time involved in executing
strategic change.
Wonderware Training
Section 2 ArchestrA
ArchestrA enables manufacturers to synchronize the various informational elements within the
manufacturing domain and supply the information required by business systems in real time.
ArchestrA provides a number of key functions designed to free users from the complexities of
dealing with current underlying technologies. So users require only assembly skills, not
sophisticated programming knowledge, and are able to apply their time to functions in which they
have more expertise. By embedding common application services directly into a common
infrastructure, application engineers can design and reuse solutions that are instantly integrated.
The key elements of the software infrastructure are the following:
z
1-17
1-18
Module 1 Introduction
Manufacturing
Collaboration
Plant
Intelligence
Production
Supervisory
Plant Floor
Connectivity
Wonderware Training
Section 2 ArchestrA
Scalability
The 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.
1-19
1-20
Module 1 Introduction
Wonderware Training
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)
z
Hardware Requirements
z
1 gigabyte (GB) of RAM or higher (512 MB minimum supported; may limit performance
and some features)
1-21
1-22
Module 1 Introduction
z
Note:
Support for Windows Server 2003
Industrial 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
Architectural Overview
Possible architecture configurations that you can create with FactorySuite A2 components include:
z
Peer-to-peer configuration
In 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 configuration
In 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.
Note: Industrial Application Server 2.0 has been thoroughly tested and is supported in Domains
implementing DHCP servers.
1-23
1-24
Module 1 Introduction
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:
z
Visualization Node
Historian 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.
Visualization Node
AppServer
AppServer
Visualization Node
Historian
Wonderware Training
Visualization Node
Engineering Station
Configuration Database
Web Server
Run-Time Components
z
z
1-25
1-26
Module 1 Introduction
Configuration and run-time components for an Application Object Server node are described in the
following table:
Configuration Components
z
Run-Time Components
z
z
z
z
z
z
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:
Run-Time Components
z
z
z
Run-Time Components
z
z
z
z
Wonderware Training
IDE
SMC
Bootstrap (Base installed)
Run-Time Components
z
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
z
Run-Time Components
z
Required component
1-27
1-28
Module 1 Introduction
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.
Run-Time Components
z
z
z
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.
Workstation
Workstation
Historian
Engineering Station
Configuration Database
Web Server
IO/DA/OPC Server
PLC Network
Workstation
In 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.
Wonderware Training
Workstation
I/O Server
Workstation
I/O Server
Historian
Engineering Station
Configuration Database
Web Server
PLC Network
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.
1-29
1-30
Module 1 Introduction
Historian
The IndustrialSQL Server must run on its own computer, collecting historical data from any
workstation in the Galaxy and providing it to client applications.
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
Visualization Node
AppServer
AppServer
Visualization Node
Historian
Visualization Node
Engineering Station
Configuration Database
Web Server
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.
Platform (Deployed)
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.
1-31
1-32
Module 1 Introduction
Training Architecture
For 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
Contains
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Contains
Bootstrap
Galaxy Repository (GR)
Contains
Bootstrap
InTouch 9.0
Present on
each machine
Standalone Configuration
PLC
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Wonderware Training
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
PLC
Galaxy 1 Node4
G1N4
Galaxy 1 Node3
G1N3
Galaxy 1 Node2
G1N2
Galaxy 1 Node1
G1N1
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Industrial Application
Server and InTouch
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)
1-33
1-34
Module 1 Introduction
Wonderware Training
Installation
Industrial 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:
z
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:
Once the Microsoft .NET Framework is installed, installation of Industrial Application Server can
continue.
1-35
1-36
Module 1 Introduction
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:
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
1-37
1-38
Module 1 Introduction
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.
1-39
1-40
Module 1 Introduction
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
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.
1-41
1-42
Module 1 Introduction
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:
z
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:
z
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 IDEs Main Window to open the License Information dialog box.
Wonderware Training
Platform group
Status: Relationship between the current and maximum WinPlatform count values.
IO Point group
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.
1-43
1-44
Module 1 Introduction
Wonderware Training
Module 2
2-3
2-9
2-2
Understand the concept and need of developing a Plant Model before configuring the
Industrial Application Server
Become familiar with key factors necessary for building successful applications.
Wonderware Training
Introduction
In 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.
Plan Templates
2-3
2-4
Wonderware Training
),&
)9
37
77
),&
)9
'5,9(
/,&
)7
&7
/7
37
)7
)9
)9
'5,9(
&7
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."
2-5
2-6
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.
ArchestrA IDE naming restrictions. For example, you might have an instance tagname of:
YY123XV456
with the following attributes:
OLS, CLS, Out, Auto, Man
The following illustration shows how the naming convention in a traditional Human-Machine
Interface (HMI) is different from the naming within ArchestrA IDE:
+0,V
$UFKHVWU$
<<;9?2/6
2/6
<<;9?&/6
&/6
<<;9?2XW
<<;9
2XW
<<;9?$XWR
$XWR
<<;9?0DQ
0DQ
,QGLYLGXDO7DJV
2EMHFW
2EMHFW
$WWULEXWHV
For ArchestrA IDE, references are created using this naming convention:
<objectname>.<attributename>
For example:
YY123XV456.OLS
Wonderware Training
For more
information refer
to the InTouch to
IAS Migration
document
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 plantrelated Area or any Area for that matter.
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 Templates
A template is an element that contains common configuration parameters for objects that are used
multiple times within a project. Templates are instantiated to represent specific objects within the
application.
For example, you might need multiple instances of a valve within your application, so you would
create a valve template that has all of the required properties. This allows you to define once, and
reuse multiple times. If you change the template, the changes can be propagated to the instances.
You can use simple drag-and-drop within the 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.
2-7
2-8
Wonderware Training
Understand the difference between Object Oriented development process and Tag
Based development process
Introduction
There are several fundamental differences between Object-oriented and traditional Tag based
HMI and SCADA products. The following table illustrates the differences in how various processes
are managed in Object Oriented vs. Tag Based systems.
Process
Object Oriented
Tag Based
Structure
Hierarchical
Flat
Graphics Development
Done Last
Done Early
Background Process
Developed in Objects
Developed in Tags
Promotion of Standards
Strictly Enforced
Data Represented By
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.
Alarm Monitoring
Animation Scripts
Security Scripts
Supervisory Scripts
2-9
2-10
Event Detection
Device integration
In order to fully realize the benefit of an Object-oriented architecture, a SCADA System today
needs to depict all of these things, along with the graphics as objects.
Types of objects
In object-oriented SCADA, objects contain the aspects or parameters associated with the device
they represent. For example, a valve object can contain all the events, alarms, security,
communications and scripting associated with a device. Objects don't just represent plant
equipment. They can also model common calculations, database access methods, Key
Performance Indicators (KPIs), condition monitoring events, ERP data transfer operations and
many more things that you want the plant information system to do. Because these operations are
modular, it is easy to add them to any and all parts of the application. For example, let's say that
there is a standard way your organization calculates and initiates a maintenance work order for a
pump. By encapsulating this function as an object, it is possible to use it with any pump in the
application.
Wonderware Training
Operating procedures
Process measurements
Calculations
Graphics displays
This leads to a cookie cutter approach, where typically small software programs are developed as
objects/code modules that can be stamped out and joined together to form an application. Almost
all of the automation vendors have this capability today with their software. Where an objectoriented SCADA System is different, is that after the cookies are stamped out, you can change the
stamp, and all of the cookies you already made are automatically changed.
This is possible because when a SCADA package is truly object-oriented, it has the notion of a
parent-child relationship, where parent templates are developed and then "Child Objects" are
replicated or instantiated from the parent templates. Now all of the children are tied back to the
parent, so a change in the parent can be replicated to all of the children. This is an extremely
powerful development capability in that:
z
Application creation is optimized by using parent Templates and automated child object
replication
Project change orders are easily accommodated by making changes in the parent
template and having the child objects inherit the changes via change propagation
Ongoing system changes and expansions are easier and more cost effective because of
automated object replication and change propagation
2-11
2-12
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
2-13
2-14
Transfer Pump
TANKXXY
Inlet Valve
XX = Student # {01,02,03}
Y = Tank # {0,1}
Valve01 _CLS
Valve01 _OLS
Valve01 _CmdOpen
TANK
Tank Level
LIT01 _PV
Outlet Valve
Valve02 _C LS
Valve02 _OLS
Valve02 _C mdOpen
Wonderware Training
Module 3
The Galaxy
Section 1 The Galaxy
Lab 1 Creating a Galaxy
3-3
3-5
3-11
3-31
3-33
3-37
3-43
3-55
3-2
Wonderware Training
Obtain an understanding of what a Galaxy is and how it relates to the Galaxy Database
and the Galaxy Repository
What is a Galaxy
Its 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 PCs that constitute
an automation system. It defines the name space that all components and objects live in and
defines the common set of system level policies that all components and objects comply with.
A Galaxy Database is the relational database containing all persistent configuration information for
all objects in a Galaxy.
And a Galaxy Repository is the software sub-system consisting of one or more Galaxy Databases.
Creating a Galaxy
Each 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.
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
3-3
3-4
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
Create a 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)
3-5
3-6
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:
Wonderware Training
As soon as this process completes, the Connect To Galaxy dialog box with the Galaxy Name
displays.
3-7
3-8
Re-entering a Galaxy
5. To re-enter the IDE after it has been configured, navigate to the IDE through the Start/
Programs/Wonderware/ArchestrA IDE
Wonderware Training
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.
3-9
3-10
Wonderware Training
Galaxy Configuration
Destroy a Galaxy
Security Configuration
Object Configuration
Edit objects
Deploy/undeploy objects
3-11
3-12
IDE Configuration
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
Title bar
Menu bar
Toolbar
Template Toolbox
Application Views
Status 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
Menu Bar
The 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:
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 objects
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.
3-13
3-14
Export For exporting Automation Objects, All Automation Objects, Script Function
Libraries, and a Galaxy Dump.
Save For saving the currently-opened objects 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 objects 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.
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.
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 Contained Name For renaming the contained name of 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.
Status Bar For toggling on/off the Status Bar of the Main Window.
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 objects 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.
z
View in Object Viewer For allowing the evaluation of attributes and conditions when the
objects are deployed. It provides a visual display of the actions being executed.
Deploy For deploying the object or objects currently in focus to the nodes their
configurations denote, this command opens the Deploy Object dialog box.
3-15
3-16
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.
Set As Default For setting a System Object, such as WinPlatform or AppEngine, as the
default for assigning appropriate objects.
Window menu For manipulating the Object Editor Client Area of the Main Window, this menu is
available if at least one objects 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 IDEs HTML Help
documentation system.
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
z
Right-click on an object (multi-select is allowed) and click Validate on the shortcut menu.
3-17
3-18
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 objects 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 objects 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 objects 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 objects 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
Toolbar
The 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 objects 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 objects 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 objects change log. Changes you made to the object when it was check out are
backed out. An error message is displayed when the objects configuration editor is open.
Properties For accessing the properties of the object in focus.
3-19
3-20
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.
User Information For configuring global user preferences for the IDE. Using this
command opens the Configure User Information dialog box.
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 IDEs HTML Help
documentation system.
The availability of the previously described icons is dynamic depending on which part of the IDEs
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 Toolbox
This part of the Main Window hosts object template toolsets, which contain object Templates, from
which instances are created or other object templates are derived. The Template Toolbox contains
separate toolset bars for each toolset in the Galaxy Repository. Click the toolset bar to open that
toolset and display the object templates contained in the chosen toolset.
When you first log in, the default toolset with default object templates is opened. Once a user has
logged in to the Galaxy Repository, the Template Toolbox is loaded with the toolset that was
displayed during the last login session.
An example of a Template Toolbox view is as follows:
The items with $ prefixes are templates or templates which were derived from other templates.
Application Views
The Application Views pane displays the galaxy configuration based on how an object is related to
other objects:
z
Model View - This defines the Object relationship to the automation scheme layout. The
Objects are organized into Areas to represent the physical plant layout.
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 users last setting.
3-21
3-22
Galaxy Name
This view is used to display the assignment of Object Instances to their area. All Object instances
belong to one and only one area.
Areas can be hierarchical. This means that an area can contain an area and the parent area
collects the statistics for all its Objects and its sub-areas.
The above diagram represents the tree view that is displayed within the model view. This
represents the area based relationships of each of the objects. The diagram is read left to right and
top to bottom, so an Area can host Application objects, DeviceIntegrationObjects,.and Objects that
contain Objects
If the instance does not have a defined host then the instance will be displayed under the
"Unassigned Area" root of the tree.
Wonderware Training
Deployment View
The deployment view is used to display the assignment of the automation scheme to physical
machines and process engines. This view describes where the objects are running. This view
does not represent your physical plant environment.
An example of a Deployment view is as follows:
This diagram represents the tree view that is displayed within the deployment view. This
represents the topology view based on which PC and Engines the objects run on. The diagram is
read left to right and top to bottom, so a Platform can host an 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.
3-23
3-24
Derivation View
The Derivation view presents objects and templates in terms of their genealogy relationships. The
derivation view is the only tree view that shows both templates and instances. The purpose of this
view is to display to the user from which templates and derived templates an instance inherits its
properties.
An example of a Derivation view is as follows:
This view 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
Object Icons
When viewing the objects, there are several states that are reflected in the way the icons for that
particular object are represented.
For instance, notice the different types of icons in the following example:
Description
Undeployed (see AnalogDevice_001 and
DDESuiteLinkClient_001 in example above)
(no indicator)
3-25
3-26
Description
Configuration warning
Configuration error
(no indicator)
Configuration good
Description
AppEngine 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 objects 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.
3-27
3-28
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 objects 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
Comment: Use this box to enter your comments about configuration changes made to the
object.
Dont 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 Check Out: Use this command to change an objects 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 objects 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
objects 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 objects editor is currently open, the
override function fails.
3-29
3-30
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 objects version number also has a new
version number, and that version number matches the version in the configuration database.
Object Viewer
The Object Viewer monitors the status of the objects and their attributes and can be used to
modify an attribute value for testing purposes.
To add an object to the Object Viewer Watch list, you can manually type the object and attribute
names into the Attribute Reference box in the menu bar and select Go. When prompted to enter
the Attribute Type, press the OK key.
You can save a list of items being monitored. Once you have a list of attributes in the Watch
Window, you can select all or some of them and save them to an XML file. 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
Understand the concept of how to utilize ArchestrA Industrial Application Server to model
a specific facility.
Section
Area
Production
Line
Manufacturing
Cell
Once a plant application model has been developed, applications can be easily extended or
replicated based on the structure you have provided. With this Facility Model you can:
z
This provides universal application development capabilities. Additionally, it provides the ability to
build industrial applications that ensure consistent engineering quality and operational best
practices.
3-31
3-32
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
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.
3-33
3-34
Wonderware Training
3. Create five (5) more instances of an Area so that there are a total of six (6) Areas.
3-35
3-36
Plant
Intake
Production
Discharge
Line1
Line2
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
Understand the terminology associated with the various objects in the IDE.
Terminology
This 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 Names
ArchestrAObject Toolkit (AppObject Toolkit) a programmers 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.
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.
3-37
3-38
DAS Diagnostic: This is part of the DAS Control Client MMC snap-in-that provides a
set of diagnostic information for DAServers within the system
DAS Configuration: This is part of the DAS Control Client MMC snap-in which
enables configuration of the DAServer either locally or remotely.
DAS Activation: This is part of the DAS Control Client MMC snap-in which enables
the user to start and stop the DAServer.
DAS AppWizard: This is the C++ Wizard that generates the framework of the DAServer
Generic State Engines: These are engines which enable the device protocol developer
to build the particular functions:
Device Engine
Serial Engine
TCP/IP Engine
Component Names
ArchestrA AutomationObject Toolkit This is the toolkit for developing core ApplicationObjects,
in a C++ environment, which will be imported into the Galaxy via the IDE.
Area AutomationObject the AutomationObject that represents an Area of a plant within an
Application Server Galaxy. The area object acts as an alarm concentrator and is used to put other
AutomationObjects into the context of the actual physical automation layout.
ApplicationEngine (AppEngine) a real-time Engine that hosts and executes
AutomationObjects.
ApplicationObject An AutomationObject that represents some element of a user application.
This may include things such as (but not limited to) an automation process component (e.g.
thermocouple, pump, motor, valve, reactor, tank, etc.) or associated application component (e.g.
function block, PID loop, Sequential Function Chart, Ladder Logic program, batch phase, SPC
data sheet, etc.).
AutomationObject A type of Object that represents permanent things 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:
z
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.
Wonderware Training
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.
Objects
Some of the primary objects that are integrally a part of the Integrated Development Environment
(IDE) in AppServer are the:
z
WinPlatform Object
AppEngine Object
Area Object
AnalogDevice Object
DiscreteDevice Object
FieldReference Object
Switch Object
UserDefined Object
3-39
3-40
Calculating various statistics related to the node its deployed to. These statistics are
published in attributes.
Monitoring various statistics related to the node its 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 engines restart attribute) restart the
engine.
There is a special instance of the platform object called the galaxy platform. This platform
instance:
z
AppEngine Object
The AppEngine Object must have a Platform on which to run. The key functionality of this object
includes:
z
containing the logic to setup and initialize objects, when theyre deployed.
containing the logic to remove objects from the engine, when theyre undeployed.
determines the scan time within which all objects within that particular engine will execute.
In general the AppEngine contains no added value other then to support the creation, deletion,
startup, and shutdown of objects.
Area Object
The Area Object plays a key role in alarm and event distribution. All AutomationObjects belong to
an Area. Areas can contain sub-Areas. Areas provide a key organizational role in grouping alarm
information and assigning it to those who use alarm/event clients to monitor their areas of
responsibility.
Wonderware Training
Creating an Instance - 1
Drag and drop the template object from the Template Toolbox to the Application View. To delete
an instance of the Platform object highlight it and click on the Delete icon in the menu icon bar
, or, right click on it and select Delete.
3-41
3-42
It can now be renamed using the naming convention as designated by your instructor.
Creating an Instance - 2
Highlight the object in the Template Toolbox for which you desire an instance. Then from the
Galaxy menu, select Galaxy/New/Instance or use the short cut which is Ctrl+N.
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
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.
3-43
3-44
Notice we are
looking at the
Model View
Wonderware Training
3. Rename the object as XYPlatform. Remember to use the naming convention discussed
earlier.
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.
3-45
3-46
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
3-47
3-48
The Application Views will now display the object in its deployed state.
Wonderware Training
Or
Select Object/View in Object Viewer from the Object menu.
3-49
3-50
Attributes section
Individual attributes of the object.
11. Right-click in the Attribute Monitoring section and select Rename Tab.
Wonderware Training
13. Right-click on the attribute Area in the Attribute section of the Object Viewer and select Add
to Watch.
3-51
3-52
CPULoad
RamAvailableAvg
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
3-53
3-54
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
Assign the instance of the Engine to the System area in Model View and to the Platform
in the Deployment View.
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.
3-55
3-56
Wonderware Training
5. In the Deployment View, reassign the Plant and all the areas to the Engine since all Areas
must run on an Engine.
3-57
3-58
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.
Wonderware Training
The Application Views will now display the objects in their deployed state.
3-59
3-60
Wonderware Training
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.
3-61
3-62
14. Right-click on the following attributes in the Attribute section and select Add to Watch.
z
Area
Host
ScanState
ScanStateCmd
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 Equipment
Section 1 Application Objects
Lab 5 DeviceIntegration Object
4-3
4-7
4-19
4-29
4-2
Wonderware Training
Be familiar with Automation Objects that represent some element of your application.
Introduction
AnalogDevice Object
This object can act as either an Analog Input (with optional Output) or as an AnalogRegulator that
provides an external representation of a PID controller that exists elsewhere (typically a PLC or
DCS).
The AnalogDevice can be configured to have a personality of one of the two basic types:
z
When configured as Analog, this Template is very similar in functionality to the Analog Tag within
InTouch today. Just as the InTouch Analog can be configured for Read or ReadWrite, the
Archestra AnalogDevice configured as type Analog can be configured as an analog input (with no
output capability) or as an analog output (with output capability). The Analog supports the basic
alarming capabilities of level alarms, ROC alarms and deviation alarms from a SP target value. In
addition, the Analog in ArchestrA provides additional functionality such as PV override enable, PV
mode (auto, manual), bad PV alarming, and separate output reference capability.
When configured as an AnalogRegulator, this Template provides both PV and SP monitoring of an
external PID controller. It provides SP output capability with an optional separate feedback
address for the SP. Other controller-oriented features include controller mode (manual vs
cascade). All the alarm capabilities of the more basic AnalogDevice object are included, with the
difference that the SP value for deviation alarms is based on the SP value read from the controller.
Some of the common features of the AnalogDevice regardless of type (Analog or
AnalogRegulator) are:
z
Supports optional scaling of input and output, both linear and square root conversions.
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 negativeslope ROC.
PV Override when true, allows the PV to be written by a user if the PV mode is set to
Manual.
Adds SP read and write capability with optional separate read-back address. For data
integrity, the value of SP always represents the value read from the external controller, not
the requested SP that is output to the external controller.
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.
4-3
4-4
Input and Output states of the DiscreteDevice object are totally independent of each other
and can be configured as required by the users 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.
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).
Wonderware Training
4-5
4-6
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
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!
4-7
4-8
Wonderware Training
Server Name:
RTEngine
Communication Protocol:
SuiteLink
4-9
4-10
Wonderware Training
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.
4-11
4-12
Wonderware Training
10. Enter Initial configuration and setup in the Comment field and click OK.
4-13
4-14
Wonderware Training
14. Verify the Initial Scan State is set to OnScan and click OK.
4-15
4-16
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:
z
ServerNode
ServerName
CommunicationProtocol
ConnectionStatus
19. Select File/Save Watch List from the File menu and click Save.
4-17
4-18
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
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.
4-19
4-20
3. In the Deployment View, verify the AnalogDevice object will deploy on the Engine as
assigned to Line1.
Wonderware Training
4-21
4-22
Wonderware Training
9. The Check In dialog box will appear. Enter Initial configuration and setup in the Comment
field. Then click OK.
4-23
4-24
Wonderware Training
12. Click Close to close the dialog box once deployment is complete.
The Application Views will now display the objects in their deployed state.
4-25
4-26
Or
Select Object/View in Object Viewer from the Object menu.
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:
z
PV
17. Select File/Save Watch List from the File menu and click Save.
4-27
4-28
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
Create a new instance of the Application objects from the Template Toolbox.
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.
4-29
4-30
Wonderware Training
5. On the General tab, enable XYInletValve for Inputs and Outputs. Check the box for Enable
inputs and Enable outputs.
4-31
4-32
Wonderware Training
Closed
Opened
Transition state:
Traveling
Fault state:
Fault
4-33
4-34
Input 1
Input Name: OLS
Input Source Reference: InControl.Tagname.Txxy_IV_OLS
Where XX = student # {01, 02, 03}
Y = Tank # {0, 1}
Input to PV Map
0 0
Traveling
0 1
Opened
1 0
Closed
1 1
Fault
Wonderware Training
4-35
4-36
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
Wonderware Training
checked
12. The Check In dialog box will appear. Enter Initial configuration and setup in the Comment
field. Then click OK.
4-37
4-38
Wonderware Training
4-39
4-40
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.
15. Click Close to close the dialog box once deployment is complete.
Wonderware Training
16. Open the Object Viewer by right-clicking on the Valve and selecting View in Object Viewer.
4-41
4-42
17. Right-click in the Attribute Monitoring section and select Add Watch Window.
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:
z
CLS.Value
OLS.Value
PV
Cmd
Wonderware Training
21. Change the state of the Valve and click Apply, then OK.
4-43
4-44
Wonderware Training
Module 5
5-5
5-9
5-37
5-39
5-49
5-79
Lab 11 Averager
5-87
5-99
5-103
5-109
5-2
Wonderware Training
5-3
Module Objectives
z
Be able to comprehend how templates can be derived and understand the effect of
locking the attributes of those templates.
5-4
Wonderware Training
5-5
5-6
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 Template
Templates are either derived from Base Objects, existing templates or created within the
ObjectToolkit and imported.
Base templates cannot have their attributes configured. However, a template can be derived from
one of the base templates. That derived template can then be configured and customized for
attributes unique to the object it is modeling. Once that derived template is configured, instances
of it can be created. Each instance will have all the attributes of the derived template.
Upon derivation the new template is created within the default toolset. The new template is created
and placed into rename mode. The new template will inherit all attributes and associations of the
original template that were locked. If the default toolset does not exist then the system will create it
when the derived template is created. Creating a derived template is available from the Template
Toolbox and the Derivation view as well as by using keyboard shortcut keys.
When creating an instance of an object that object instance will need to be configured
independently. When deriving a template an instance of the template is created that takes on all of
the attributes of the template from which it was created. This propagation of objects of a like kind
can have a tremendous impact on the ability to create multiple instances of template derived
objects containing fully replicated attributes.
Wonderware Training
Template Containment
Template 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:
5-7
5-8
Wonderware Training
Transfer Pump
TANKXXY
Inlet Valve
XX = Student # {01,02,03}
Y = Tank # {0,1}
Valve01 _CLS
Valve01 _OLS
Valve01 _CmdOpen
TANK
Tank Level
LIT01 _PV
Outlet Valve
Valve02 _C LS
Valve02 _OLS
Valve02 _C mdOpen
5-9
5-10
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.
STOP!
Youve 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
or
Right-click on the Template Toolbox Group heading and select New Toolset.
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.
5-11
5-12
Wonderware Training
4. Rename the object to XYValve (where XY are your initials) and move it to your Toolset.
Note: Theres no need to type the $ character at the beginning of the name. It will be added
automatically by the IDE.
5-13
5-14
6. On the General tab, check the box for Enable inputs and Enable outputs to enable the
Valve to Inputs and Outputs.
Wonderware Training
Closed
Opened
Transition state:
Traveling
Fault state:
Fault
5-15
5-16
CLS
Input 1
OLS
Input to PV Map
0 0
Traveling
0 1
Opened
1 0
Closed
1 1
Fault
Wonderware Training
leave as 1
Commandable States
Output1
Opened check box
CmdOpen
checked
5-17
5-18
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
Stopped
Running
Fault state:
Fault
5-19
5-20
leave as 1
Combinations
Input1
AuxContact
Stopped
Running
Wonderware Training
Commandable States
Output1
Running check box
CmdStart
checked
5-21
5-22
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.
5-23
5-24
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
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
5-25
5-26
Wonderware Training
InControl.Tagname.TXXY_IV_CLS
Input 1 OLS
Input Source Reference
InControl.Tagname.TXXY_IV_OLS
5-27
5-28
InControl.Tagname.TXXY_IV_CmdOpen
Where XX = student # {01, 02, 03}
Y = Tank # {0, 1}
Wonderware Training
checked
Now you can see as represented by the icon for XYInletValve that the reference has been
resolved.
InControl.Tagname.TXXY_OV_CLS
Input 1 OLS
InControl.Tagname.TXXY_OV_OLS
Where XX = student # {01, 02, 03}
Y = Tank # {0, 1}
5-29
5-30
Wonderware Training
InControl.Tagname.TXXY_OV_CmdOpen
Where XX = student # {01, 02, 03}
Y = Tank # {0, 1}
checked
5-31
5-32
InControl.Tagname.TXXY_TP_AuxContact
Where XX = student # {01, 02, 03}
Y = Tank # {0, 1}
34. Select the Outputs tab. Configure the Output Destination Reference as follows
Output Source References
CmdStart
InControl.Tagname.TXXY_TP_CmdStart
Where XX = student # {01, 02, 03}
Y = Tank # {0, 1}
Wonderware Training
Now all the references have been resolved as indicated by the icons represented for each of
the objects.
5-33
5-34
39. Right-click on the XYTankSystem_001 and select View in Object Viewer to view the object
attributes in Object Viewer.
40. Right-click in the Attribute Monitoring section and select Add Watch Window.
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
Cmd
PV
Cmd
PV
Cmd
PV
PV
43. Select File/Save Watch List from the File menu and click Save.
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.
5-35
5-36
Wonderware Training
Enable you to understand how locking attributes can propagate to previously derived
instances.
Locking an attribute in a Template indicates that its value is to be logically shared with all derived
objects (Templates or instances). In other words, when the value changes in the template, that
change is propagated to all the derived children of the object. When an attribute is locked in the
Template, the value can be changed in that Template but not in any of the derived children.
Based on this concept, an attribute can have one of three logical lock types:
z
Unlocked: Both Templates and instances can have these. Attribute is read-write. The
object has its own copy of the attribute value and is not shared by derived objects.
Locked: Only Templates can have these. Attribute value is read-write. Derived objects
dont 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
5-37
5-38
Unlocking an Attribute
To 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 objects editor. Some editors may
have lock icons associated with certain edit fields, but this possibility is within the scope of the
developer of the objects 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
Objectives
Upon completion of this lab the student should be able to:
z
Monitor the changes that are propagated to the object instances that were derived from
the template object.
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.
5-39
5-40
Enable inputs
Enable output
State names
Wonderware Training
Number of Inputs
Input Name
Input to PV Map
5-41
5-42
Number of outputs
Output Name
Closed
Opened
Wonderware Training
5-43
5-44
Enable inputs
Enable output
State names
Wonderware Training
Number of Inputs
Input Name
Input to PV Map
Number of outputs
Output Name
Stopped
Running
5-45
5-46
Type
Enable PV override
Wonderware Training
13. Open the editor for any of the instances and check that you can't modify the locked attributes.
5-47
5-48
All instance references have now been reconciled with the changes we made in our template
from which those objects were derived.
Wonderware Training
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.
5-49
5-50
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.
Wonderware Training
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 Objects
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.
5-51
5-52
Script Examples
The 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
Objects Functionality/QuickScript .NET Scripting Language/Sample Scripts.
Load an XML Document from Disk and Do Look-ups on It
dim doc as System.Xml.XmlDocument;
dim node as System.Xml.XmlNode;
doc = new System.Xml.XmlDocument;
doc.Load("c:\catalog.xml");
' find the title of the book whose isbn is 044023722X
node = doc.SelectSingleNode("/catalog/book[@isbn='044023722X']/title");
LogMessage(node.InnerText);
' find all titles written by Grisham
for each node in doc.SelectNodes("/catalog/book[author/lastName='Grisham']/
title")
LogMessage(node.InnerText);
next;
5-53
5-54
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.
Wonderware Training
This script can be locked in the template without locking down which attribute on what object is
actually used in an instance derived from this template.
The actual mapping to an attribute is done via the Alias Reference table exposed by the script
editor. The table exposes the following fields:
Alias
Reference
PVofInletValve
Valve101.PV
5-55
5-56
Wonderware Training
Execution Mode
OnExecute() mode scripts can be configured to execute in one of two execution modes,
synchronous or asynchronous. All other script types are always synchronous and cannot be
configured otherwise.
Synchronous Execution
The synchronous mode is the default choice and represents serial script execution by the
ApplicationEngine in the course of calling the Execute method of all ApplicationObjects that are
on-scan in the ApplicationEngine. For satisfactory determinism, this mode requires that all scripts
execute deterministically and quickly enough to prevent an ApplicationEngine over-scan condition.
Asynchronous Execution
The asynchronous mode is used for the class of scripts that perform operations that dont meet the
above speed and determinism criteria. These scripts will be executed on a worker pool of
separate, lower priority threads than the Application Engines 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.
5-57
5-58
Shutdown attribute simply a Boolean flag that requests the asynchronous script to shut
down on its own. A well-written script will check this command before and after timeconsuming operations.
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:
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.
Wonderware Training
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. Lets 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=Auto
PID.SetPoint=50
PID.Mode=Cascade
Endif;
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:
z
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 attributes value in the course of the scripts 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.
5-59
5-60
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 as quality is set to uncertain.
Wonderware Training
5-61
5-62
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
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 users perspective is it easier if all the
listed cases are treated equally; i.e., the quality is ignored in all cases.
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.
5-63
5-64
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 Zero
The division by zero error is raised only for integer operations. In the case of float values the
scripting is able to deal with + and - and also NaN (Not a Number).
Wonderware Training
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).
Calling public instance methods (with and without parameters) of .Net types.
Calling public static methods (with and without parameters) of .Net types.
Language Definition
QSII Case Sensitivity
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However, the
case is preserved throughout editor sessions.
QSII Comments
Both single line and multi-line comments are supported. Single line comments start at a in a
source code line that has no matching ending in the line. Multi-line comments start with a { and
end with a } and can span multiple lines as the name suggests.
Examples:
5-65
5-66
Description
Complement
Negation
NOT
Logical NOT
Description
Multiplication
Division
Subtraction
Assignment
MOD
Modulo
SHL
Left Shift
SHR
Right Shift
&
Bitwise AND
Exclusive OR
Inclusive OR
**
Power
<
Less than
>
Greater than
<=
>=
==
<>
Not Equal to
AND
Logical AND
OR
Logical OR
Operator
1 (highest)
(, )
Wonderware Training
Operator
- (negation), NOT, ~
**
* , /, MOD
+, -
SHL, SHR
==, <>
&
10
11
12
13
AND
14 (lowest)
OR
QSII Variables
Variables must be declared before any other code. Local variables or attributes can be used
interchangeably within the same script. However, local variables go out of scope at the end of the
script function they are used in. However, variables declared in the general section of the script
exist and keep their value throughout the lifetime of the object that the script is associated with.
Thus this kind of variable turns into a member variable of the script class. Other scripts attached
to the same object cannot access this variable.
Variables can be used on both the left and right hand side of statements and expressions.
where
variable_name ::= <letter> { <letter> | <digit> | <special_character> }
letter ::= A-Z | a-z
digit ::= 0-9
special_character ::= _
upper_bound ::= 1-2,147,483,647
data_type ::= Boolean | Discrete | Integer | Float | Real | Double | String |
Message | Time | Object
The variable name is limited to 255 Unicode characters. Note that, in contrast to attribute names,
variable names must not contain dots. Variable names and the data type identifiers are not case
sensitive. If there is a naming conflict between a declared variable and another named entity in the
script (attribute name, alias, name of an object leveraged by the script), the variable name takes
precedence over the other named entities.
For example, lets assume that your script accesses the hosting objects PV attribute in the script
text and you declare DIM PV AS Integer;. Within the declaring script, expressions using PV in a
5-67
5-68
Default
Value
Corresponding
C++ data type
Boolean, Discrete
False
VARIANT_BOOL
Integer
long (4 bytes)
Signed
2147483648 to 2147483647
Float, Real
NaN
float (4 bytes)
Double
NaN
Double (8 bytes)
String, Message
(empty
string)
BSTR
Time
Based on .NETs
System.DateTime
(8 bytes)
ElapsedTime
Based on .NETs
System.TimeSpan
structure (8 bytes)
Object
Nothing
IDispatch pointer
Comment
Wonderware Training
QuickScript
.NET Data
Type
Comments
MxBoolean
Boolean or
Discrete
True=1, False=0
MxInteger
Integer
MxFloat
Float or Real
MxDouble
Double
MxString
String or
Message
MxInternationalizedString
String or
Message
MxTime
Time
MxElapsedTime
ElapsedTime
Same definition
MxReferenceType
String
MxStatusType
Integer
MxDataTypeEnum
Integer
MxSecurityClassificationEnum
Integer
MxDataQualityType
Integer
5-69
5-70
QuickScript
.NET Data
Type
Comments
MxQualifiedEnum
Integer or
String
MxQualifiedStruct
N/A
Wonderware Training
Floats
Float 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>]
|
String Literals
String 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
\'
\"
\\
Backslash
\uxxxx
5-71
5-72
Description
\Uxxxxxxxx
Data Type
Mapping
Boolean, Discrete
Integer
Float, Real
Double
String, Message
Time
Object
Wonderware Training
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.
(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.)
5-73
5-74
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.
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. Microsofts 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
FOR EACH will allow for looping through arrays. (Omitted for this slice)
While Loop
A WHILE loop is used to perform a function (or set of functions) within a script several times during
a single execution of a script while a condition is true. The general format of the WHILE loop is as
follows:
WHILE <boolean_expression>
[statements]
[EXIT WHILE;]
[statements]
ENDWHILE;
Where:
z
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.
Where StringRight is a binary script function as described in the Scripting DFS. After the executing
the script snippet PumpState holds the value On.
5-75
5-76
ActiveX Server:
Other names for ActiveX Server are COM Server, ActiveX component, ActiveX EXE, ActiveX DLL.
Creating objects outside of the context of scripts does not work. In many cases an object can only
be created in a programmatic manner based on another already created object.
VBS example:
Dim xlApp
Dim xlBook
Dim xlSheet
' Assign object references to the variables. Use
' Add methods to create new workbook and worksheet
' objects. Note that xlBook and xlSheet can only be
' created after the objects xlApp and xlBook got
' created.
Set xlApp = WScript.CreateObject("Excel.Application")
Set xlBook = xlApp.Workbooks.Add
Set xlSheet = xlBook.Worksheets.Add
Once created, the methods exposed by a COM object can be accessed as if they would be script
functions.
There are at least two different approaches:
Wonderware Training
5-77
5-78
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
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.
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.
5-79
5-80
Wonderware Training
5-81
5-82
Wonderware Training
5-83
5-84
Aliases
Declarations
Scripts
Basics
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
5-85
5-86
Wonderware Training
Lab 11 Averager
Lab 11 Averager
Introduction
The 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 objects 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.
Objectives
Upon completion of this lab the student should be able to:
z
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.
5-87
5-88
3. Double-click on the $XYAverager template object to open its editor and select the UDA tab.
Click on the Plus icon
Data Type:
Double
Category:
Calculated
This is an array:
Unchecked
Wonderware Training
Lab 11 Averager
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-89
5-90
Calculate
Execution Type:
Execute
Trigger Type:
Periodic
Trigger Period:
00:00:00.0000000
Wonderware Training
Lab 11 Averager
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.
'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 queueLength
queueSum = queueSum + valueQueue[i];
Next;
Me.Avg = queueSum / queueLength;
5-91
5-92
Wonderware Training
Lab 11 Averager
8. Lock the following sections
z
Aliases
Declarations
Scripts
Basics
5-93
5-94
Execute
Expression:
Me.QueueSize
Trigger Type:
DataChange
Wonderware Training
Lab 11 Averager
10. Lock the following sections
z
Aliases
Declarations
Scripts
Basics
5-95
5-96
Note: When the Averager instance is renamed, a dialog box with a warning is displayed.
Click Yes.
Wonderware Training
Lab 11 Averager
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.
16. Right-click in the Attribute Monitoring section and select Add Watch Window.
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.
5-97
5-98
Wonderware Training
Extensions
The Extensions page is comprised of five main functional areas. These are described below.
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.
5-99
5-100
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.
Wonderware Training
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.
5-101
5-102
Value to be Sent
1,0,0,1,1
none
1,0,0,1,1
1,1,0,0
1,1,0,0
none
Note: In the case of Boolean data types used in Supervisory sets (sets between
ApplicationObjects and ArchestrA) or a mixture of Supervisory and User sets during a single scan
cycle, the behavior is the same as the other data types.
Important! When the same attribute is extended with an Input extension and an Output extension,
writes to the Output extension's Destination occur every scan regardless of whether the extended
attribute has changed. This behavior occurs even when the Output Every Scan check box is
cleared, increasing the potential for additional network traffic. The behavior described in this note
does not apply to an InputOutput extension.
Wonderware Training
Lab 12 Extensions
Lab 12 Extensions
Introduction
Extensions 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.
Objectives
Upon completion of this lab the student should be able to:
z
View those changes in the Object Viewer and change their state.
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.
5-103
5-104
Boolean
Category
Object writeable
Wonderware Training
Lab 12 Extensions
2. Select the Extensions tab.
5-105
5-106
checked
InControl.Tagname.TXXY_ALARM01
checked and locked
Category
Process
Priority
500
me.Tagname
6. Right-click in the Attribute Monitoring section and select Add Watch Window.
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
Lab 12 Extensions
8. Add the following attributes to the Watch Window:
z
TankAlarm
TankAlarm.InAlarm
TankAlarm.Acked
TankAlarm.TimeAlarmOn
TankAlarm.TimeAlarmOff
DLPlant.InAlarm (Note that this attribute is from the Plant area, not the
XYTankSystem object.)
9. Select File/Save Watch List from the File menu and click Save.
5-107
5-108
Wonderware Training
Be familiar with Additional Automation Objects that represent some element of your
application.
Introduction
FieldReference Object
This 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:
z
WriteOnly Output
Switch Object
This Object is the object for accessing data from a simple discrete (0/1) device. This object can act
as both a discrete input and a discrete output.
The Switch Object can be configured into three basic access modes:
z
WriteOnly Output
The PV value can be historized, logged as an event, and alarmed when abnormal.
UserDefined Object
The UserDefined object is an empty object that you can use to create customized objects. You can
use the UserDefined object in the following ways:
z
As a "container" for other objects. An object relationship in which one object is comprised
of other objects is called containment. Containment allows you to group various objects
together to make complex objects. For detailed information on object containment, see the
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.
5-109
5-110
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
6-3
Lab 13 Alarming
6-9
6-23
Section 3 Historization
6-33
Lab 14 Historization
6-37
6-2
Obtain an overview and understanding of how the Industrial Application Server integrates
with InTouch and InSQL.
Wonderware Training
Section 1 Alarming
Section 1 Alarming
Section Objectives
z
What is an Alarm/Event
The alarm and event capabilities in the system provide for users to automate the detection,
notification, historization and viewing of either application (process) alarms and events or system/
software alarms events. Alarms and events are things that occur in the runtime system. Events
and alarms are different and the system distinguishes between the two. An event is simply an
occurrence of a condition at a certain point in time. The system can detect events, store them
historically and report them to various clients. Alarms, on the other hand, represent the
occurrence of a condition that is considered abnormal (generally bad) in nature and requiring
immediate attention from a user. Alarms are a special type of event that indicate something
abnormal has happened. The system handles the real-time reporting of alarms in a special
manner and provides special clients for their viewing.
Examples of alarms include:
z
A process 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.
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.
Configuration actions within the Galaxy Repository; for example import or check-out.
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.
6-3
6-4
Alarms:
ArchestrA field
N/a
Time
Tagname
Name
Comment
Area
Alarm group
State
Priority = 1-999
Priority
Value (mxValue)
Value
Limit (mxValue)
Limit
Value MxReference
N/a
Limit MxReference
N/a
Units MxReference
N/a
Category
Class
Category
SubClass
Wonderware Training
Section 1 Alarming
AutomationObjects acknowledge attribute for the alarm. Security is used as part of this set (it is a
UserSetAttribute). An optional comment can be entered when the acknowledge is requested.
An acknowledge of an alarm is reported as an alarm state change back to the distributed alarming.
The optional operator comment is included in the event message sent back.
Distributed Alarming has no support for passing a rejected acknowledge failure feedback.
Therefore, if an acknowledge is requested from a client but does not succeed, the only feedback
on the InTouch client will be no change in acknowledge status on the client.
Alarm Enable/Disable
The InTouch Alarm Client can enable/disable alarming on any AutomationObject. The platform
receives the enable request and forwards it to the target AutomationObjects AlarmMode attribute.
Security is used as part of this set (it is a UserSetAttribute).
System Events:
ArchestrA field
Type = SYS
Timestamp
Time
Tagname
Name
Tag description
Comment
Area
Alarm group
N/a
N/a
Priority = 1
N/A
Provider = Galaxy
N/A
Type = OPR
Timestamp
Time
Tag.primitive.attribute
Name
Tag description
Comment
Area
Alarm group
6-5
6-6
Operator 2 name
N/a
Old value
Limit
New value
value
N/a
N/a
Priority = 999
N/A
Provider = Galaxy
N/A
Type = LGC
Timestamp
Time
Tag.primitive.attribute
Name? Or name+comment?
Tag description
Comment
Area
Alarm group
Old value
Limit
New value
Value
N/a
N/a
Priority = 999
N/A
Provider = Galaxy
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.
Wonderware Training
Section 1 Alarming
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.
6-7
6-8
Wonderware Training
Lab 13 Alarming
Lab 13 Alarming
Introduction
A 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 InTouchs 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.
Objectives
Upon completion of this lab the student should be able to:
z
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.
6-9
6-10
2. Check the InTouch alarm provider box and verify the Alarm areas list box is blank.
Wonderware Training
Lab 13 Alarming
Configure the AnalogDevice Object
4. Double-click on the XYLIT object.
6-11
6-12
Wonderware Training
Lab 13 Alarming
9. Right click on XYLIT and select View in Object Viewer.
PV
Hi.Limit
Hi.InAlarm
Hi.TimeAlarmOff
Hi.TimeAlarmOn
6-13
6-14
Wonderware Training
Lab 13 Alarming
13. Configure as follows then click the Create button:
Server Name local
User Name sa
Logging Mode Consolidated
Password
[Check with your instructor for the correct password.]
The Success dialog box will display indicating the tables were created.
Click OK to continue.
6-15
6-16
Wonderware Training
Lab 13 Alarming
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 platforms node name, Galaxy is a fixed keyword and <Area> is
the area of interest.
6-17
6-18
18. Click Start to start the database logger then minimize it, but DO NOT close it.
Wonderware Training
Lab 13 Alarming
View Alarm History and Event History
19. 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.
6-19
6-20
Wonderware Training
Lab 13 Alarming
Here you can investigate the details of the alarming history with time and date stamp, values,
etc.
6-21
6-22
Wonderware Training
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.
6-23
6-24
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
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).
6-25
6-26
Error Messages
When using the Change Network Account utility, you may encounter the following error messages.
Error Message
Action Required
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.
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.
Wonderware Training
Action Required
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.
You used one or more invalid characters in the User Name box. Click
OK, type a valid user name and click OK.
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.
6-27
6-28
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.
6-29
6-30
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.
6-31
6-32
Wonderware Training
Section 3 Historization
Section 3 Historization
Section Objectives
z
Historization Background
The 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)
6-33
6-34
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.
Wonderware Training
Section 3 Historization
Reconfiguration of InSQL at Object Undeploy Time
When 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.
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.
6-35
6-36
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.
Wonderware Training
Lab 14 Historization
Lab 14 Historization
Introduction
An 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 objects
attributes to be historized by IndustrialSQL Server (InSQL). We will use the ActiveFactory
Trend object in InTouch to trend these attributes.
Objectives
Upon completion of this lab the student should be able to:
z
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.
6-37
6-38
Wonderware Training
Lab 14 Historization
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.
6-39
6-40
Data Type
Category
LIT
Float
User Writeable
OutletValve
Integer
User Writeable
TransferPump
Integer
User Writeable
Wonderware Training
Lab 14 Historization
7. Select the Extensions tab.
6-41
6-42
Wonderware Training
Lab 14 Historization
9. Configure the remaining UDA extensions as follows:
Name
Input Extension
Source
History extension
LIT
checked
me.XYLIT.PV
OutletValve
checked
me.XYOutletValve.PV
TransferPump
checked
me.XYTransferPump.PV
6-43
6-44
Wonderware Training
Lab 14 Historization
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.
6-45
6-46
Wonderware Training
Lab 14 Historization
Configure the Platform
17. 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
20. Configure the Deploy dialog box as follows and click OK.
Check the box for Cascade Deploy
Check the box for Force Off Scan
Check the box for OnScan
6-47
6-48
Wonderware Training
Lab 14 Historization
Configure ActiveFactory Trend
22. Select Start/Programs/Wonderware/ActiveFactory/Trend to launch the ActiveFactory
Trend.
6-49
6-50
APU00
wwUser
Password
wwUser
Click OK.
25. Expand the Public Groups/Analog Tags and locate your object name in the TagName area
below.
28. In the Auto refresh mode dialog box select 1 second from the drop down box and click OK.
Wonderware Training
Lab 14 Historization
6-51
6-52
Wonderware Training
Module 7
7-3
7-13
7-2
Wonderware Training
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.
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.
7-3
7-4
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
Authentication Mode
7-5
7-6
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
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.
z
A user can have multiple accounts within the security system. For instance, a user may
have an account that provides permissions for working with instances but not templates.
The same person may have another supervisory account for working with templates and
managing users in the ArchestrA environment. To switch between levels of authority, the
person must login as the new user. To do this, click Change User on the Galaxy menu.
7-7
7-8
If you use OS Group Based Authentication Mode, you should first familiarize yourself indepth with
the functions of the Windows operating system, particularly its user permissions, groups and
security features. ArchestrA OS Group Based security leverages those Windows features.
Take note of the following behaviors that are unique to OS Group Based Authentication Mode:
z
A newly-added user working on a computer that has no access to the Galaxy node cannot
write to an attribute on a remote node if that user has never logged on to the remote node.
This is true even if the user has been given sufficient runtime operational permissions to
do writes. To enable remote writing capabilities, log on to the remote node at least once.
Wonderware Training
If you attempt to log in to ArchestrA on a workstation running Windows 2000, login will fail
until you properly set the TCB privilege in Local Security Policies. Do this as follows: On a
Windows 2000 Server computer - on the Start menu, point to Programs and then
Administrative Tools, and then click Local Security Policies (On a Windows 2000
Professional computer - on the Start menu, point to Settings and then click Control
Panel. In the Control Panel, double-click Administrative Tools. In the Administrative
Tools utility, double-click Local Security Settings.). In the left pane of the Local Security
Settings dialog box, expand the Local Policies folder and click the User Rights
Assignment folder. In the right pane, double-click Act as a part of operating system. In
the Local Security Policy Setting dialog box, add the user (the user logged in to the
computer) by selecting the Local Policy Setting check box, and then click OK. Log off
and log in to the computer again to implement the new TCB privilege. You must be an
administrator to set TCB privilege.
The list of domains and user groups appears differently in the group browser depending
on whether you have configured your domain as a Mixed or Native domain. Your unique
appearance should map to the list of domains and user groups you see when you use the
Windows tool for managing your domain. A domain group that is configured as
"Distribution" rather than "Security" cannot be used for security purposes.
The user's full name is not available to any client (for instance, an InTouch window) if the
domain controller is disconnected from the network when the user logs in to ArchestrA for
the first time. If the user previously logged in to ArchestrA when the domain controller was
connected, the user's full name will still be available to the client from data stored in cache
even if the domain controller is disconnected when the user subsequently logs in to
ArchestrA.
User Authentication
Client 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.
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.
7-9
7-10
Machines and users defined within a Workgroup. Note the users/groups have been
defined on each machine and imported into the Galaxy Repository (GR) and defined as
Local Host.
Logon Dialog
If 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:
z
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.
Logon Object
A Logon COM object is provided for use by any OS client utilities that need to log on to Application
Server. This COM object either provides a Log-on Dialog or is driven silently by an automation
interface. OS authentication and log on dialogs may be leveraged.
Wonderware Training
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.
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:
z
When an Engineer overrides the Attribute Security Classification within a Template editor.
7-11
7-12
Wonderware Training
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.
7-13
7-14
Wonderware Training
Datatype
Security
Att1_FreeAccess
Boolean
Free Access
Att2_Operate
Boolean
Operate
Att3_SecuredWrite
Boolean
Secured Write
Att4_VerifiedWrite
Boolean
Verified Write
Att5_Tune
Boolean
Tune
Att6_Configure
Boolean
Configure
Att7_ReadOnly
Boolean
Read Only
7-15
7-16
Wonderware Training
7-17
7-18
Wonderware Training
7-19
7-20
13. Select the XYSecurityTest_001 instance object from the list in the right pane.
Wonderware Training
7-21
7-22
Wonderware Training
7-23
7-24
Wonderware Training
7-25
7-26
Youll 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.
Wonderware Training
26. Open the Object Viewer, add a watch window and rename the Tab to Security.
27. Add the following attributes to the Watch Window:
z
Att1_FreeAccess
Att2_Operate
Att3_SecuredWrite
Att4_VerifiedWrite
Att5_Tune
Att6_Configure
Att7_ReadOnly
ScanState
ScanStateCmd
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.
Notice the task bar at the bottom of the Object Viewer now indicates the Administrator is
logged in.
7-27
7-28
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
7-29
7-30
35. In the left pane under Console Root expand Microsoft SQL Servers.
Wonderware Training
Here you can investigate the details of the event history and the details associated with each
event.
7-31
7-32
Wonderware Training
7-33
7-34
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
You will be reminded that the Operator has not been configured to change security.
7-35
7-36
Wonderware Training
Module 8
Galaxy Maintenance
Section 1 Exporting and Importing a Galaxy
8-3
8-13
8-29
8-2
Wonderware Training
This 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.
Galaxy Dump
Each of these has unique features and characteristics which are discussed in this section.
8-3
8-4
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.
8-5
8-6
Wonderware Training
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.
8-7
8-8
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.
8-9
8-10
Note: Carriage returns in scripts associated with dumped objects are replaced with "\n" in the .csv
file. If you edit the dump file, do not delete the "\n" characters. If you edit scripts in the dump file,
use "\n" for a carriage return. This character set is interpreted as a carriage return when the dump
file is used in a Galaxy Load function. When editing a script in a dump file, use "\\n" if you want to
include the character "\" followed by the character "n" in a script. This character set is not
converted to a carriage return in a Galaxy Load function.
Wonderware Training
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.
8-11
8-12
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
Objectives
Upon completion of this lab the student should be able to:
z
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.
8-13
8-14
Or,
From the File menu select Galaxy/Export/Galaxy Dump.
Wonderware Training
You will see the Galaxy Dump dialog box indicating the dump as complete when it finishes.
8-15
8-16
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.
8-17
8-18
5. Select File/Save As and save the file as TankTest2.csv. Be sure that it is a csv file.
Wonderware Training
8-19
8-20
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.
8-21
8-22
Wonderware Training
10. Create an instance of the XYPH template and assign it to your TankSystem_001.
8-23
8-24
Wonderware Training
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.
8-25
8-26
18. At the Galaxy Load Conflict Resolution dialog box select Skip and click OK.
Wonderware Training
8-27
8-28
Wonderware Training
Runs with minimal ArchestrA and operating system requirements, equivalent to "Safe
mode"
Allows viewing of the layout of the Galaxy Repository, Platforms, and Engines
8-29
8-30
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
Console Tree
The console tree has a Windows Explorer-type hierarchical structure layout, with the ArchestrA
System Management Console appearing as the root node and the SMC snap-ins appearing
below this node. Like Windows Explorer, the console tree can be expanded or collapsed by
clicking on the "+" or the "-" symbols that appear next to the snap-in.
The console tree shows the items that are available in the console. The snap-ins that appear
below the ArchestrA SMC node include the Platform Manager, the Log Viewer, the DAServer
Manager, and the Galaxy Database Manager.
The contents of the details pane changes as you select items in the console tree.
Details Pane
The details pane is comprised of two main elements:
z
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 galaxys name. Use this information
when backing up and restoring galaxies.
The contents of the details pane changes as you select items in the console tree.
8-31
8-32
No authentication
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 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.
The following commands are available from the Platform Manager Action menu when you select
a platform or engine in either the console tree or the details pane.
Wonderware Training
Command
Description
Configure
Log Flags
Connect
Messages
Refresh
Help
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
Filter
Find
Go To
8-33
8-34
Description
Bookmarks
Mark
Choose Columns
Customize
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
Log Viewer
The Logger is an ArchestrA utility that records information regarding the activity occurring on the
computer. For example, it records start-up data, error conditions, and DAServer information.
Wonderware Training
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.
8-35
8-36
The journey of a Log Message originates with the Application where Log Flags are generated.
These are passed to the Logger where they are then stored in the Log Message Storage. They
are then available for viewing by the LogFlag Viewer. The LogFlag Editor provides the capability
to edit the LogFlags. This is illustrated in the following diagram.
6
LogFlag Editor
LogFlag Viewer
5
3
4
Wonderware Training
2
1
To go to a bookmarked message
1. On the View menu, click Go To.
2. In the Go To dialog box, enter the name of the messages 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.
8-37
8-38
DAServer Manager
The DAServer Manager allows local or remote configuration of the DA Server and its device
groups and items, and can monitor and perform diagnostics on DAServer communication with
PLCs and other devices.
Like the LogViewer and Platform Manager, the DAServer Manager is a Microsoft Management
Console (MMC) snap-in. Many high-level functions and user-interface elements of the DAServer
Manager are universal to all DAServers; to understand the DAServer Manager, it is critical to read
the documentation for both the MMC and the DAServer Manager.
To read the documentation about the MMC and DAServer Manager, click the Help topics on the
SMC Help menu. Both the MMC Help and the DAServer Manager Help are displayed.
Wonderware Training
Module 9
9-3
Section 2 DI Objects
9-7
9-9
9-15
9-25
9-2
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
Section 1 DAServers
Section Objective
z
Become familiar with DAServer and its use with the Industrial Application Server.
Introduction
Wonderwares 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:
z
Support for hot configuration, device additions and device- and server-specific parameter
modifications
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.
9-3
9-4
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
You must create the Device Protocol Layer (server specific) modules with the DAServer, and all
three sets of modules are required for a fully functioning DAServer.
Plug-ins
Plug-ins provide protocol translation functionality for device integration clients. Typical Plug-ins
communicate in DDE, SuiteLink or OPC protocol, and serve as interfaces between their clients
and the DAS Engine. You can disable a protocol when customizing the installation for your
DAServer.
DAS Engine
The DAS Engine is a middleware component that exposes two sets of unique interfaces, one for
communicating with Plug-ins and one for communicating with Device Protocol Layer components.
It encapsulates common tasks for the DAServer, like handling the item database, distributing data
to clients, propagating clients' requests to the protocol, and providing diagnostics.
DAServer Characteristics
Configuration
The DAServer Manager is capable of displaying specific configuration pages for all servers. This
utility allows browsing and editing of servers on different nodes.
Recall that DAServers are hot-configurable. In other words, they are configurable while the server
is running or even acquiring data. Certain restrictions imposed by the underlying network/protocol/
hardware might apply.
For instance, if you uncheck System Items on the global parameters configuration dialog of the
DAServer Manager and select Apply, and then re-check System Items and Apply, System Items
data is valid only to newly connected clients.
The configuration data format for DAServers is XML. Any XML-enabled program (for example, IE
and XML Notepad) can read this format.
Runtime
The DAS Engine is loaded by the DAServer as an in-process COM object.
It is not statically linked. In other words, a new DAS Engine (feature
enhancement or bug fix) would not require re-linking to the other components nor re-QA of those
other components. It is deployed to the system and attaches to all existing server components.
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.
9-5
9-6
Hot Configuration
One of the big advantages provided by the DAServer is the ability to make your DAServer
configurable while the server is running - hot configuration.
The extent to which a specific DAServer is hot configurable varies from server to server. You can
choose from a variety of hot configuration responses, from not being hot configurable at all to
being configurable of each individual parameter while the server is running.
The DAServer handles most of the hot configuration work. In general, a user will run the DAServer
Manager and configure each hierarchy. Any changes she makes that add/delete/update a
hierarchy are sent immediately to the running DAServer.
Server-specific code may elect to react to the change. Some parameters cannot be changed while
the DAServer is running due to protocol-specific issues, and these can be ignored by the serverspecific code.
Here is a complete list of notifications to the server about changes in the configuration:
z
Wonderware Training
Section 2 DI Objects
Section 2 DI Objects
Section Objective
z
Become more familiar with DI Objects and their use with the Industrial Application Server.
Introduction
Device 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:
z
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.
9-7
9-8
The differences between the Application and DI Objects are listed below:
z
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 Devices and DI Network objects have extra tabs within their editors to configure
ScanGroups, BlockReads, and BlockWrites.
Wonderware Training
This section discusses integration to third party applications, specifically through the
FactorySuite Gateway
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.
9-9
9-10
Refer to the FactorySuite support website, especially the Compatibility Matrix, for more information
on specific connectivity tools.
Wonderware Training
To provide NT support which will allow connections to classic products that have not been
migrated to later Operating Systems.
To replace the OPCLink product used when connecting InTouch to OPC Servers.
To provide a mechanism for the transport of IAS data between two different Galaxies.
7) Does FS Gateway provide Galaxy to Galaxy communications with ArchestrA and the 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.
9-11
9-12
Acts as a Data Concentrator for a client wanting access to many different sources.
10) What capability is there to browse tag and attribute values for products using the FS Gateway?
FS Gateway can "browse" InTouch and OPC DA Servers Data Connections. This is
accomplished inside the SMC which is the centralized place for configuration and diagnostics.
All other data connection items are manually entered (or alternatively can be imported from a
CSV file) before the data can be browsed. This "browse" is the ability to navigate the actual
native information (either on InTouch or 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.
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.
SuiteLink Clients
Server Products
z
DDE Servers
Wonderware Training
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.
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).
Windows XP
Windows NT 4.0
Windows 2000
Windows 2003
For additional information or details on how to access and configure Factory Suite Gateway please
refer to the Wonderware FactorySuite Gateway Users Guide.
9-13
9-14
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
Use the DAServer Manager to create and ArchestrA Object on the Instructor machine.
In the Student machine, create and configure a DDESuiteLinkClient object in the IDE to
connect to the Instructor machine.
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.
9-15
9-16
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
9-17
9-18
Wonderware Training
Reconnect Period:
30000 MSec
Read Only:
Checked
7. Select ArchestrA.FSGateway.1.
9-19
9-20
Or,
Click the Activate Server icon on the icon bar.
Wonderware Training
Student Configuration
9. In the Deployment View, create an instance of the $DDESuiteLinkClient object by dragging
it from the Template Toolbox to the Application Views pane.
9-21
9-22
Server name:
FSGateway
Communication protocol:
SuiteLink
Wonderware Training
17. Deploy XYInstructor. Verify that Initial Scan state is set to On Scan.
9-23
9-24
21. Verify that you're reading data from the instructor's galaxy.
Wonderware Training
Understand the concept on Intermittent Networks and how to configure for them
Introduction
Intermittent 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.
z
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.
9-25
9-26
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.
Wonderware Training
9-27
'LDOXS
.ESV
OLQH
76&OLHQWV
(WKHUQHW
+LVWRULDQ'DWD
DQG$ODUPV
(QJLQHHULQJ6WDWLRQ
:HE6HUYHU
&RQILJXUDWLRQ'DWDEDVH
,QGXVWULDO$SSOLFDWLRQ6HUYHU
6XSHUYLVRU\1HWZRUN
'$6HUYHU
&RQWURO1HWZRUN
56
+(:/(77
3$&.$5'
5RXWHU
5785DGLR0RGHP
5785DGLR0RGHP
5785DGLR0RGHP
56
1HWZRUN
+8%0$8
1,&
87,/ ,=$7,21
7$%
*'
-$
0
%1&
0 E V
5(
.%
1
/HYHOWUDQVPLWWHU
+8%0$8
*' * '
7
9
:
; < =
8
7$%
*'
-$
(17(5
5 81
35 1
, 7
+(/ 3
%1&
0 E V
$/ 3+$
6+,)7
1,&
87,/ ,=$7,21
, )
/ &
2
*'
*'
5(
.%
/HYHOWUDQVPLWWHU
, )
/ &
0
1
*'
*' * '
*'
7
2
9
:
; < =
8
(17(5
5 81
35 1
, 7
+(/ 3
$/ 3+$
6+,)7
9-28
Wonderware Training
Module 10
Visualization
Section 1 Visualization
10-3
10-13
10-33
10-39
10-67
10-2
Module 10 Visualization
Module Objective
z
Obtain an overview and understanding of how the Industrial Application Server integrates
with InTouch and InSQL
Wonderware Training
Section 1 Visualization
Section 1 Visualization
Section Objective
This section will familiarize you with an understanding of how Industrial Application Server
integrates with InTouch and InSQL from a visualization perspective
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.
10-3
10-4
Module 10 Visualization
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 Integration
InTouchs 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 Name
A 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
Section 1 Visualization
Tag Source
To 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 Browser
With 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:
z
Only runtime visible attributes in a single Galaxys namespace are viewable, this will
include the capability to switch between an Objects TagName and its HierarchicalName .
The selection will be based on:
z
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 InTouchs 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.
10-5
10-6
Module 10 Visualization
z
Boolean
Integer
Float
String
Attribute Properties
The 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
Purpose
None
Coerced
Wonderware Training
Section 1 Visualization
Attribute Extension
DataType
Purpose
.#VString
for floats/doubles
attributes only:
.#VString1
.#VString2
.#VString3
.#VString4
String
(read-write)
10-7
10-8
Module 10 Visualization
Attribute Extension
DataType
Purpose
.#EnumOrdinal
Integer
(read-write)
.#ReadSts
String
(read-only)
Wonderware Training
Section 1 Visualization
Attribute Extension
DataType
Purpose
.#WriteSts
String
(read-only)
InTouch
datatype
Notes
Float
Float 32 bit
Pass thru.
Double
Float 32 bit
Boolean
Discrete
False = 0, True = 1
Integer
String MBCS
( multi-byte
character set
encoded )
Time
String
Unicode
(MBCS)
ElapsedTime
Supported.
MxDataType
String MBCS
MxSecurityClassification
String - MBCS
10-9
10-10
Module 10 Visualization
Attribute/property
datatype
InTouch
datatype
Notes
MxQuality
String - MBCS
MxReference
String MBCS
MxCategorizedStatus
String - MBCS
MxQualifiedStruct
Not supported
MxQualifiedEnum
String MBCS
Array of Strings
String MBCS
(read-only)
All arrays
Integer, Float,
String, or
Discrete.
MxInternationalizedText
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:
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.14
float/ double
3.14
Uncertain
3.14
On Msg
3.14
3.14 ?
float/ double
3.14
Initializing
3.14
On Msg
3.14
Initializing
float/ double
3.14
Bad
3.14
On Msg
3.14
Bad
float/ double
NaN
Good
0.00
Off Msg
NaN
float/ double
NaN
Uncertain
0.00
Off Msg
NaN ?
float/ double
NaN
Initializing
0.00
Off Msg
NaN
float/ double
NaN
Bad
0.00
Off Msg
NaN
float/ double
1.7E308
Good
0.00
Off Msg
1.7E308
float/ double
1.7E308
Uncertain
0.00
Off Msg
1.7E308 ?
float/ double
1.7E308
Initializing
0.00
Off Msg
Initializing
float/ double
1.7E308
Bad
0.00
Off Msg
Bad
Cust Enum
Open
Good
0.00
Off Msg
Open
Open
Cust Enum
Open
Uncertain
0.00
Off Msg
Open
Open ?
Cust Enum
Open
Initializing
0.00
Off Msg
Open
Initializing
Cust Enum
Open
Bad
0.00
Off Msg
Open
Bad
Boolean
True
Good
1.00
On Msg
True
Boolean
True
Uncertain
1.00
On Msg
True ?
Boolean
True
Initializing
1.00
On Msg
Initializing
Wonderware Training
Section 1 Visualization
App Server
Data Type
App Server
Value
App
Server
Quality
InTouch
Analog
Animation
InTouch
Discrete
Animation
InTouch
String
Animation
InTouch
String
(#VString)
Boolean
True
Bad
1.00
On Msg
Bad
String
In the bank
Good
0.00
Off Msg
In the bank
In the bank
String
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
Initializing
String
In the bank
Bad
0.00
Off Msg
In the bank
Bad
Integer
45
Good
45.00
On Msg
45
45
Integer
45
Uncertain
45.00
On Msg
45
45 ?
Integer
45
Initializing
45.00
On Msg
45
Initializing
Integer
45
Bad
45.00
On Msg
45
Bad
Time
5/10/2002
11:06:44 AM
Good
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
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.22
ElapsedTime
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
Initializing
ElapsedTime
5 03:42:22.22
Bad
445342.22
On Msg
445342.22
Bad
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).
IO Status
WindowViewer 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
10-11
10-12
Module 10 Visualization
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 Data
The 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.
Galaxy Security
Message 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
Objectives
Upon completion of this lab the student should be able to:
z
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
10-13
10-14
Module 10 Visualization
Tasks
Configure InTouch Properties
1. 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
10-15
10-16
Module 10 Visualization
Wonderware Training
8. Delete any existing expression and double-click in the white space area of Expression:
10-17
10-18
Module 10 Visualization
10. Select New to create a new Tag Source.
Wonderware Training
Access Name:
Galaxy
Galaxy
GR node name:
Galaxy name:
Generic Configuration
10-19
10-20
Module 10 Visualization
An Actual Configuration
12. Click Close to close the Define Tag Sources dialog box.
Wonderware Training
10-21
10-22
Module 10 Visualization
16. Click OK on the Properties configuration dialog box.
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
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.#VString2
as
XYLIT.PV.#VString2
obj1.PV.#VString3
as
XYLIT.PV.#VString3
obj1.PV.#VString4
as
XYLIT.PV.#VString4
obj1.PV.#WriteSts
as
XYLIT.PV.#WriteSts
obj1.PV.#Locked
as
XYLIT.PV.#Locked
10-23
10-24
Module 10 Visualization
Click OK.
Wonderware Training
Click OK.
19. Click on Runtime to verify the values.
10-25
10-26
Module 10 Visualization
Wonderware Training
10-27
10-28
Module 10 Visualization
21. Click on the background of the Security window to activate the window.
Press F2 to select all items on the window.
Wonderware Training
25. Verify that ArchestrA security is selected from the main menu.
Special / Security / Select Security Type / ArchestrA.
10-29
10-30
Module 10 Visualization
26. Click Runtime to test your configuration.
You should see the correct Object Name and Security Group.
You should be able to change Att1_FreeAccess, but not Att2_Operate based on the security
you configured.
Wonderware Training
10-31
10-32
Module 10 Visualization
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
Set up Galaxy connectivity in InTouch for viewing and acknowledging Alarms and Events.
10-33
10-34
Module 10 Visualization
Tasks
Configure the Alarm ActiveX Controls in InTouch
1. 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
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.
10-35
10-36
Module 10 Visualization
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
8. Click the General tab and for the Display Mode select Alarm History.
10-37
10-38
Module 10 Visualization
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
Set up properties in InTouch and configure them to link 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.
10-39
10-40
Module 10 Visualization
Tasks
Configure InletValve Properties
1. In WindowMaker, create a new window.
3. Draw a Valve
Wonderware Training
10-41
10-42
Module 10 Visualization
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.
Closed
color
(red)
Open
color
(green)
Wonderware Training
Traveling
color
(yellow)
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;
10-43
10-44
Module 10 Visualization
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-45
10-46
Module 10 Visualization
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
10-47
10-48
Module 10 Visualization
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
Or
Right-click and select Duplicate.
10-49
10-50
Module 10 Visualization
18. With the duplicate valve and buttons still selected, right-click and select Substitute Tags.
Wonderware Training
10-51
10-52
Module 10 Visualization
Wonderware Training
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;
10-53
10-54
Module 10 Visualization
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;
10-55
10-56
Module 10 Visualization
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
10-57
10-58
Module 10 Visualization
Generate Smart Symbol
34. 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
10-59
10-60
Module 10 Visualization
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
10-61
10-62
Module 10 Visualization
43. Enter the name of your GR Node Name and the Galaxy Name and click OK.
Wonderware Training
10-63
10-64
Module 10 Visualization
Add and Configure an Additional Smart Symbol
47. Click on the SmartSymbol Wizard to add another SmartSymbol.
Wonderware Training
50. Select XYTankSystem_000 or any other tank system that you might have in your Galaxy and
click OK.
10-65
10-66
Module 10 Visualization
Notice the references in the Instance References column have changed.
Wonderware Training
Objectives
Upon completion of this lab the student should be able to:
z
Configure the InTouchProxy object to select tagnames from the InTouch Tagname
Dictionary.
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.
10-67
10-68
Module 10 Visualization
Tasks
Configure the IT1 Object
1. 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 Students computers) and share the app folder as
ReactorDemo.
Wonderware Training
10-69
10-70
Module 10 Visualization
7. On the General tab, for InTouch runtime node enter the node name where the InTouch
Application resides.
Wonderware Training
The application is now inserted into the Item browse path field.
10-71
10-72
Module 10 Visualization
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
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
$Second
ReactLevel
ReactTemp
ProdLevel
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.
10-73
10-74
Module 10 Visualization
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.
Wonderware Training
The I/O tab now has IT1.ReactLevel configured as the PV input source.
10-75
10-76
Module 10 Visualization
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 Galaxies
Section 1 Redundancy and Redundant DI Objects
Lab 22 Redundancy
Section 2 Converting to a Multi User Galaxy
Lab 23 Convert to Network Environment
11-3
11-19
11-33
11-37
11-2
Using exporting and importing to take objects that were created on one node and migrate
them to a single node, and:
Wonderware Training
This section will covers the concept of redundancy, how it can be configured and key
points to more effectively implement this feature.
Redundant Configuration
Redundancy is important in processes that rely on continuous availability of information. There are
two basic types or topologies of redundant configuration:
z
Redundant DI Objects
11-3
11-4
Wonderware Training
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.
11-5
11-6
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:
z
IT Alarm provider-Areas
Common scripting.
Role Determination
The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of
Application engines determines which of these in the pair will take the Active Role. The first engine
deployed takes the Active role while the other one takes the Standby role. The engines maintain
Wonderware Training
11-7
11-8
Visualization Nodes
Supervisory Network
AutomationObject Server
AutomationObject Server
Primary
Backup
AE_1
(Standby)
Platform 2
Platform 1
Control Network
In a Shared redundant configuration, two or more Redundant Engines reside on each of two
platforms. Each platform hosts a Primary and a Backup engine. See the illustration below. This
scenario operates similarly to the Dedicated configuration, but allows the application load to be
shared on two computers until a failure occurs. When a failure occurs, one platform hosts the load
of both application engines. The benefits of using this approach is that the time of failover is
shortened and that only part of an application process is affected during a failure.
Note: It is important to understand both the CPU and memory load requirements of each engine.
Each computer must be capable of supporting these needs when a failure occurs; otherwise,
throughput for the application can be compromised
Wonderware Training
Visualization Nodes
Supervisory Network
AutomationObject Server
AutomationObject Server
Primary
AE2
AE1 Bck
Platform 1
Backup
Backup
AE1
Bck AE2
Primary
Platform 2
Control Network
11-9
11-10
Active: The state of an AppEngine when it has communication with its partner object, its
partner is in Standby-Not Ready, Standby-Syncing 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.
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
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-Syncd 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.
Unknown: The state of a redundant partner when a communication loss occurs between
AppEngines or when the partner AppEngine is not running.
Alarm Generation
When failover conditions occur, the ArchestrA system reports alarms to the Logger. These alarms
contain the following information:
z
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.
11-11
11-12
Previous
State
Current
State
Alarm Raised
When
Alarm
Reported
By
Standby - Not
Ready 1
Active
Standby - Not
Ready
Standby - Not
Ready
ACtive
Engine
Standby - Not
Available
Active
Entering Active
Active
Engine
Standby Becomes
Active
Active
Engine
Alarm
Failover
Occurred
Legend:
1
The Active AppEngine monitors the status of the Standby through the RMC to determine
when to raise this alarm. Also, if the Active AppEngine is in Active-Standby not Available state,
this alarm is not generated.
When a failover occurs, the Standby AppEngine that becomes active will not report alarms
outstanding from the old Active AppEngine. The state of those old alarms, though, is reflected on
the new Active AppEngine as follows:
z
Out of alarm
Unacknowledged
Unacknowledged-Return to normal
Acknowledged-Return to normal
Acknowledged
The message input by the operator when the alarm was acknowledged
Note: All alarm state information is collected and sent to the Standby AppEngine at the end of a
scan cycle and before being sent to alarm clients. Any alarms that occur between scan cycles,
therefore, may not be reported to the Standby object if the Active object fails. The sequence of
reporting alarms ensures that alarm clients do not report alarms in states that are different from
those reported by the Standby AppEngine if the Active one fails.
History Generation
All active objects (AppEngine and hosted objects) report history data as they normally do in the
run-time environment.
Historical data is reported to the historian only from the Active AppEngine.
Loss of connectivity with the historian does not cause a failover. The Active AppEngine then goes
into store-forward mode and caches data every 30 seconds. Store-forward data (when the
historian is unavailable) is synchronized with the Standby AppEngine.
Wonderware Training
Forced Failover
Failover can be forced to occur. Do this through the ForceFailoverCmd attribute of the AppEngine.
For instance, you can link multiple conditions in a script or use the Object Viewer utility to trigger a
forced failover.
Deployment
Primary and Backup AppEngines can be deployed together or individually. When they are
deployed together (no matter which object is actually selected for deployment), the Primary always
becomes the Active and the Backup becomes the Standby. When they are deployed individually,
the first one deployed becomes the Active.
Hosted ApplicationObjects are always deployed to the Active AppEngine. When deploying the first
of a redundant pair of AppEngines, you can cascade deploy all objects it hosts. This operation can
be paired with deploying both the Primary and Backup AppEngines at the same time.
Note: If you deploy the Backup AppEngine first and then deploy hosted objects to that
AppEngine, ensure that network communications to both target computers is good before
deploying the Primary AppEngine. Otherwise, errors may occur.
In the run-time environment, either the Primary or Backup AppEngine can become the Active or
Standby depending upon failure conditions on either computer.
Before deploying the Primary and Backup AppEngines, all configuration requirements must be
met. Each AppEngine must be assigned to a separate WinPlatform. A valid redundancy message
channel (RMC) must be configured for each WinPlatform. To deploy the Primary and Backup
together, select Include Redundant Partner in the Deploy dialog box. This option is not available
when doing the following operations:
z
11-13
11-14
Cascade Deploy
Allowed
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
Yes
Condition
Backup AppEngine's host WinPlatform configured for
failover and deployed.
No
Yes
No
No
No
Yes
Yes
Yes
Yes
Yes
Undeploying redundancy pairs of AppEngines is similar to any regular object undeployment. The
Active and Backup AppEngines can be undeployed separately. Also, they can be undeployed as a
pair by selecting one of the objects in an Application View, selecting the Undeploy command, and
selecting Include Redundant Partner in the Undeploy dialog box.
Note: Undeployment of any AutomationObjects, including redundant AppEngine pairs, does not
uninstall code modules for that object from the hosting computer. Code modules are uninstalled
only when the WinPlatform is undeployed.
Wonderware Training
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 Objects
Application Engines can host Redundant Device Integration Objects (DI Objects). The
RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike redundant
AppEngines, individual DIObject data sources do not have redundancy-related states. For all
intents and purposes, they function as standalone objects.
Only one DIObject data source provides field device data through the RedundantDIObject at a
time. Both data sources must have commonly configured DAGroups which are reflected in and
channeled through the RedundantDIObject, which monitors the two DIObject data sources and
determines which one is Active at any given time. Both data sources must also have the same
item address space.
The Redundant DI Object is a DINetwork Object used to enable continuity of I/O information from
field devices. The Redundant DI Object provides the ability to configure a single object with
connections to two different data sources. If the primary data source fails, the Redundant DI
Object automatically switches to the backup data source for its information. There is a one-to-two
relationship between an instance of the Redundant DI Object and the running instances of the
source DI objects; that is, for each Redundant DI Object, a pair of source DI Objects is deployed.
11-15
11-16
6XSHUYLVRU\1HWZRUN
',B
$(
3ODWIRUP
$SSOLFDWLRQ6HUYHU
',B
'$6HUYHUB
'$6HUYHUB
$%7&3
'+
&RQWURO1HWZRUN
3/&
Configuration RedundantDIObjects
Configure 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:
z
Setting the Primary DI Source and Backup DI Source on the General tab of the objects
editor.
Setting up the common scan groups, and block read and block write groups on the
respective tabs of the objects editor.
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.
Deployment
Deployment for data acquisition redundancy is the same as individually deploying unrelated
objects. No special conditions apply to each DIObject data source and the RedundantDIObject.
11-17
11-18
Wonderware Training
Lab 22 Redundancy
Lab 22 Redundancy
Introduction
This 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.
Objectives
z
Test redundancy
11-19
11-20
Hardware installation
1. 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.
Wonderware Training
Lab 22 Redundancy
6. Right-click Local Area Connection 1 and select Rename from the context menu. Rename
the connection ArchestrA. (For identification purposes)
11-21
11-22
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
Lab 22 Redundancy
10. Click the OK button to close the dialog box.
11. Right-click ArchestrA and select Properties. The ArchestrA Properties dialog box will popup.
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.
11-23
11-24
Wonderware Training
Lab 22 Redundancy
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.
11-25
11-26
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
Lab 22 Redundancy
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:
11-27
11-28
XYPlatform2:
XYAppEngine:
Wonderware Training
Lab 22 Redundancy
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
<default_value>
<default_value>
23. Save and close the editor. At the Check In dialog, enter RMC configuration in the Comment
field. Click OK.
192.168.0.2
<default_value>
<default_value>
11-29
11-30
25. Save and close the editor. At the Check In dialog, enter RMC configuration in the Comment
field. Click OK.
Wonderware Training
Lab 22 Redundancy
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.
11-31
11-32
Test Redundancy
31. View XYAppEngine in the Object Viewer and add the following attributes to the Watch
Window:
z
XYAppEngine.Host
XYAppEngine.Redundancy.FailoverOcurred
XYAppEngine.Redundancy.ForceFailoverCmd
XYAppEngine.Redundancy.Identity
XYAppEngine.Redundancy.PartnerPlatform
XYAppEngine.Redundancy.PartnerStatus
XYAppEngine.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
11-33
11-34
Application
Server
Galaxy
Repository
InTouch
Station
Contains
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Contains
Bootstrap
Galaxy Repository (GR)
Contains
Bootstrap
InTouch 9.0
Present on
each machine
Standalone Configuration
PLC
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Wonderware Training
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
PLC
Galaxy 1 Node4
G1N4
Galaxy 1 Node3
G1N3
Galaxy 1 Node2
G1N2
Galaxy 1 Node1
G1N1
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Bootstrap
IDE
InTouch 9.0
Galaxy Repository (GR)
Industrial Application
Server and InTouch
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.
11-35
11-36
Wonderware Training
Objectives
z
Use exporting and importing to take objects that were created on one node and migrate
them to a single node
Understand how to deploy and undeploy objects on a galaxy located on a different node
Requirements
Galaxy 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.
11-37
11-38
Wonderware Training
11-39
11-40
Wonderware Training
11-41
11-42
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
9. On the Galaxy1 node that will contain the Galaxy Repository, import the Tank Template and
the InControl object.
11-43
11-44
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.
11-45
11-46
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
Licensing
The 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:
z
and 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.
Wonderware Training
A-3
A-4
Wonderware Training
A-5
A-6
Wonderware Training
Appendix B
B-2
Overview
This 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.
Wonderwares Website is located at: www.wonderware.com.
Wonderware Training
Registration
To 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.
B-3
B-4
Levels of Access
When 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
More Support links are contained within the Support page. The links are available according to
your access level status.
B-5
B-6
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 Email addresses for contacting Tech Support.
Wonderware Training
Team Wonderware
Support information is also located on: team.wonderware.com.
B-7
B-8
Wonderware Training
Appendix C
C-2
Wonderware Training
C-3
C-4
Wonderware Training
C-5
C-6
Wonderware Training
C-7
C-8
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
z
Active object: The object that is currently executing desired functions. For AppEngines, it
is the object that is hosting and executing ApplicationObjects. For data acquisition, it is the
object that is providing field device data through the RedundantDIObject.
Standby object: The passive object; that is, it is waiting for a failure in the Active objects
condition or for a force-failover. For AppEngines, it is the object that monitors the status of
the Active AppEngine. For data acquisition, it is the object that is not providing field device
data through the RedundantDIObject.
Redundant DI Object
The RedundantDIObject monitors and controls the redundant DIObject data sources. Unlike
redundant AppEngines, individual DIObject data sources do not have redundancy-related states.
For all intents and purposes, they function as standalone objects.
Redundant Message Channel
The Redundant Message Channel (RMC) is a dedicated Ethernet connection which is required
between the platforms hosting redundant engines. The RMC is vital to keep both engines
synchronized with alarms, history, and checkpoint items from the engine that is in the Active Role.
Each engine also uses this Message Channel to provide its health and status information to the
other.
Reference
A string that refers to an object or to data within one of its attributes.
Relational Reference
A reference to an objects attributes that uses a keyword in place of an object's tagname. These
keywords allow a reference to be made by an object's relationship to the target attribute. Examples
of these keywords are "Me", "MyPlatform", and "MyContainer".
Remote Reference
The ability to redirect ArchestrA object references or references to remote InTouch tags. The new
script function used to redirect remote references at runtime is IOSetRemoteReferences.
Runtime
The InTouch (WindowViewer) function that provides the viewing of data from the configuration
of the application in InTouch development (WindowMaker).
Scan Group
A DAGroup that requires only the update interval be defined and the data will be retrieved at the
requested rate.
Scan State
The Scan State of an object in run-time. This can be either off-scan or on-scan.
Security
Industrial 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
C-9
C-10
Wonderware Training
W O N D E R W A R E
T R A I N I N G
Instructor Notes
Revision C
June 2005
Part Number 05-2056
Industrial
Application Server
2.0 Course
Course Developer
Telephone
Dana Lundy
Dana.Lundy@wonderware.com
949-639-8639
Wonderware Training
Note: Important! The only difference in Rev B and Rev C is Appendix A. The Licensing
information was revised.
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)
z
Hardware Requirements
z
1 gigabyte (GB) of RAM or higher (512 MB minimum supported; may limit performance
and some features)
4
z
Note:
Support for Windows Server 2003
Industrial 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.
WinZip
Active Factory
Windows NT or 2000
Setup Notes
z
DHCP is recommended
Each student machine is a full App Server node (FactorySuite A Development seat IDE
with Galaxy Repository )
The App Server node and the Historian node software must be installed with the same
Admin account
If 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
Wonderware Training
5
z
High Availability
Performance
Usability
Connectivity
Scalability
High Availability
Migration
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:
z
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.
6
Connectivity
Industrial 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.
Performance
Support 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.
Usability
Full 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.
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.
Licensing
Galaxy 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.
Company
Current Position
Class times
Contacting Wonderware
Instructor Note
There 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 2
There 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 3
Lab 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
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 4
Lab 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 5
Lab 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 6
Lab 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 7
Lab 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 8
Lab 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 9
Lab 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 10
Lab 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 11
Lab 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